> 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. > It would be worth some research to see how feasable it is to support a > GUI frontend with Pylons. Would you make the GUI emulate a web server > so you could use your Pylons controllers? Or what would you do? I think I would just have the admin wxapp talk to the model somehow and tell them to preview things in firefox. It's really the controller logic I'd be trying to duck out of. The SQLAlchemy model side I'd like to keep as close as possible. ( Ideally the exact same, maybe with a wrapper in there ). > That's what you'd do, make a UI-agnostic framework-agnostic model and > use it in both applications. It doesn't have to be sockets; > high-level function calls into the model is easier. Yeah, I think that would depend on where the model was going to live. In some cases it might be nice to shadow the model db locally and have one global update button. Come to think of it, that would have made my life easier a week ago when a client deleted a bunch of their page using an admin login that they were never supposed to use, according to the specs. And that's what got me thinking. I mean, I can see many many advantages to web only, but ajax is painstaking, javascript is not as cool as C++ or python, and I just can't adequately control what the client will do with a browser when they are out of my site. I can lock it down tight with a custom app with a lot less headache. Another big issue is customer expectations and perceived value. It seems to me that: a) Everyone expects web sites to be pretty, so a utilitarian web admin site is considered ugly. No one expects a native windows or gtk app to look any different than the toolkit standards. b) Like it or not, there is still likely a perception in the business community that web dev is easier than it actually is, so clients may also feel like they are getting more for their buck when they get an app that looks like all the other business apps they pay good money for. c) People have this expectation that web sites should be changeable on a moments notice, but no one expects their desktop apps to follow their every whim. So it could be a lot easier to control the spec/improvement/debug/deploy cycle. I'm interested to see how the human element of this equation plays out. All this said, I do MVC soft-realtime server app stuff for fun with audio apps, and am a relative newby to DHTML and python web frameworks, so I could see why others might validly think my interpretation of easier and more logical is totally backwards ... ;) Thanks for the input! Iain --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
