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 <[email protected]> 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 - [email protected] > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss >
--------------------------------------------------- PLUG-discuss mailing list - [email protected] To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
