On 3/11/07, iain duncan <[EMAIL PROTECTED]> wrote:
>
>
> > So far we've done some initial tests with Py2exe (Windows) and Py2app
> > (Mac) and put it on the back burner. I've tried to stay away from
> > that part because I'm more of a Linux guy.
> >
> > If I did it again I'd still go the web route because the differences
> > between a web framework and a GUI application are so big I don't see
> > how can avoid writing essentially two applications.
>
> I think for me it would depend on the nature of the needed web app side.
> In most of my ( limited ) work so far, the only complicated stuff as far
> as validation and persistancy goes has been on the admin side. Even with
> an ajax shopping cart, the public web side is not that much compared to
> the admin. So, I think if the admin side was way more complex than the
> web side, I would lean towards a gears and/or pylons web side
> ( depending on the needs in question ) and seriously entertain the
> notion of a wx app that updates the db for the admin. If both sides were
> already going to be web-complex, then I think you'd be right, it would
> be needless duplication of work.
If the standalone is an admin interface, you're already talking about
different functionality between it and the website. In which case
it's really two separate applications sharing the same model. But
your question brings up the point that different kinds of sites have
very different requirements, so a GUI interface may make more sense
for some than others.
In my case the website (cameochemicals.noaa.gov) and standalone (not
yet implemented) are identical. The database is read-only and a copy
will be bundled with the standalone. We needed the web app for the
website anyway, so it really is a choice between zero work for HTML vs
lots of work for a GUI. Also, we're hoping the standalone will be
obsolete in a few years when wireless Internet access becomes more
ubiquidous, so we're not eager to put resources into a GUI with a
short lifespan. In the meantime we're distributing an existing
FileMaker standalone with updated data, which is less searchable but
it gets the job done.
There is no admin interface because the data is imported offline. If
there were an admin interface we might be more favorable to a GUI. My
other public site (incidentnews.gov -- which I'm currently converting
to Pylons as part of its upgrade) is fed from a larger private site
which handles any admin'ing it needs.
By the way, the other work unique to the standalone is to:
- choose a database backend. I went with Durus because it proved
fastest and most reliable with our dataset, can be included in the
py2exe executable, and can run equally well on the server and
standalone. MySQL has installation and licensing issues (GPL), and I
couldn't get its embedded mode to work (it's poorly documented).
SQLite hung regularly (due to threading issues in the C library).
- design the Windows and Mac installers and launchers.
- make sure the app doesn't write any local files (log or session)
during runtime -- making it more acceptable to local IT staff.
- decide how to update the data. Easiest is to make the user
reinstall from scratch (10 MB, but originally 40 MB). I considered
some semi-automatic checking for updates and modifying the db in place
via a web service, but rejected those as too complicated and
error-prone, especially since the laptops are in the hands of naive
users we can't support long-distance.
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
