My initial inclination was OpenOffice with MyODBC. I like Alex's points
about browsers and Bryan O'Neal's remark about MS Access. If you just think
it would be neat to have a desktop component of the Control Panel, maybe
simply exposing certain views or tables to OpenOffice.org via MyODBC would
accomplish your goal.
In the interest of full disclosure I should say I have not been impressed
with the speed of OpenOffice MyODBC connections I've worked with, but things
may be getting better.
Tom
--
"To forgive is the highest, most beautiful form of love. In return, you will
receive untold peace and happiness." - Dr. Robert Muller
On Mon, Nov 8, 2010 at 12:59 PM, Alex Dean <
alex@crackpot.org> wrote:
>
> On Nov 8, 2010, at 10:57 AM, keith smith wrote:
>
> >
> > Thank you for your feedback. It is a web based PHP app. It has a
> control panel for editing the data. I was thinking it might be nice to have
> a desktop application that has the same features as the browser based
> application.
>
> If you don't have some definite requirement that can't be fulfilled by a
> browser I strongly recommend just adding the new features to your existing
> PHP application. Same language, same codebase, more opportunity to re-use
> code you already have. That "can't be fulfilled in a browser" list is
> shrinking all the time as browsers get more capable. Stuff like 'needs to
> be functional without an internet connection' or 'heavy graphics processing'
> are about all i can think of at the moment.
>
> Whatever neato-factor you get from having an installed application instead
> of a web app pales in comparison to the maintenance hassle your creating by
> splintering your codebase into multiple applications, especially if the 2
> apps are in different languages and can't share library code.
>
> If you do go ahead with a desktop application, put as little business logic
> as possible in it. It should be nothing more than a client for your web
> application. Expose your data as some web service, and use your web
> application as an intermediary between your desktop application and your
> database. Data validation, SQL abstraction, etc, should all happen in the
> web application rather than re-implementing these things in your desktop
> app. The desktop app should only need to do HTTP GET/POST/PUT/DELETE, etc,
> and shouldn't need to do any SQL work at all.
>
> Using the database as the integration point between multiple applications
> (in this case your existing PHP application and this new hypothetical
> desktop application) is a huge pain. For instance: if your desktop app is
> directly modifying your database, you'll have to distribute an updated
> desktop application every time the database undergoes some schema change.
> As an alternative: if you have your web application is sitting in-between
> (and if your web service APIs are decent) then the desktop application
> doesn't need to know anything about those schema changes. You can deploy
> the schema change and an updated web service at the same time, and the same
> desktop client should continue to work just fine.
>
> alex
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)