Re: Pylons integrated desktop apps?
On 3/10/07, iain duncan [EMAIL PROTECTED] wrote: Hi folks, I am just wetting my feet with pylons. I am curious whether anyone on here has experience integrating desktop apps with pylons projects, and if so, would they care to share opinions on feasability, when it is worth, how it went, how they did so? Despite what many would have me believe, IMHO there are still many cases where a custom desktop app built in wxPython, wxWidgets and/or Dabo has real advantages for an administrator would be doing work on their remote databases ( that are in turn web acessible in some other form ). I already do this kind of stuff for unrelated work where a web browser is totally not an option, so I'm curious about tying them together. And I think that as long as a business is making a comparison between .net, j2ee, and a python based solution, the python solution is going to have to be able to offer up something other web only interaction to be taken seriously. And who the heck wants to use hibernate instead of SQLAlchemy? All input appreciated, Dennis Reinhardt does tricks like this, although not with Pylons. He recently gave a talk at BayPiggies about it. -jj -- http://jjinux.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Pylons integrated desktop apps?
On 3/11/07, iain duncan [EMAIL PROTECTED] wrote: I haven't done it but it's a live issue in our office. I have one site that's a web application (Quixote) and will also be a standalone web application for laptops without Internet access (e.g., for emergency responders on a truck or ship). We debated doing a wxPython interface for the standalone but didn't want to maintain two totally different APIs. wxPython has an HTML panel but I don't think it supports CSS or Javascript, plus how would you make a URL for an intra-application hyperlink? So we decided on a local version of the web application, which has its own set of problems: the browser is an automomous process unless you embed it in a platform-specific way (both Windows and Macintosh), the server is either invisible or has its own little GUI to stop it - which all works differently than a normal application. Some say local web applications will be a lot more common in the future but for now they just look weird to most users. I've seen Dabo twice at PyCon and am impressed by it, both for database CRUD and for general GUI applications. It's much more pythonic than raw wxPython, although I'm not sure how it compares to PythonCard. So, having done it with a local web app and now having seen Dabo, would that change your choice if you were to do it again? I would love to hear more details on how that went if you have time. ( good, bad, interesting, etc ) I am very attracted to the fine grained input control we get with a wxApp, as well as how much easier it would make security; it seems to me that catching admin input errors or sloppy practices can be made a lot more pleasant than the it usually is through a browser. And while I know we *can* do that with javascript, let's face it, it ain't pretty compared to even C++! Personally I really don't think wxPython looks so bad, must be my C audio background. ;) But everyone seems pretty jazzed by Dabo so maybe a Dabo/Pylons combo would be a sweet option. I would also think that a wxPython or wxWidgets app that talked to the db through a socket layer could be made dead easy to install, but as I have not done that, maybe I'm way off base? Anyone know if you can use SQLAlchemy as your backend for Dabo? If not, I would think the smart way to do it would be to make a simple little api or socket server that allowed one to use the same model code for both versions. But it's all brainstorming right now fer me. All of this reminds me very strongly of the book Dreaming in Code. They faced the same sorts of decisions, in Python nonetheless. WxPython may be the best cross-platform API we have, but it sure does seem to negatively impact a lot of projects. :-/ -jj -- http://jjinux.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Pylons integrated desktop apps?
On 3/11/07, iain duncan [EMAIL PROTECTED] wrote: A while back I built a TurboGears app that utilized XRC (see http://wiki.wxpython.org/index.cgi/UsingXmlResources) templates that wxPython can render as GUI elements. The main application (compiled as an .exe) was little more than a bootstrap loader that downloaded a zipfile of Python modules from the TG server and then rendered each page of the GUI via XRC. Aside from the initial downloading of the Python modules, it worked more or less like a web application: whenever a new page was needed, it fetched the XRC description from the server and rendered it. It worked great, giving all the advantages of a web app (centralized administration and ubiquitous access) and all the benefits of a GUI app (sophisticated UI controls and local system integration). Further, because all the database access was done via normal HTTP (I used pycurl), the GUI app was well-insulated from the underlying implementation and much of the server-side code was reusable for an actual web application as well (the GUI served as the administrative interface for controlling a public-facing website). hmm, that sounds pretty handy. Any opinions on here about the appropriateness of pythoncard vs dabo vs ra wxPython for this sort of thing? Especially as concerns being able to leave the model code intact for both web and desktop access? ( I personally don't mind the C++'ish ness of raw wxPython if it works better in other areas ) Based on PyCon talks, Pythoncard takes a lot of the pain out of wxPython. Dabo seems to be aimed squarely at replacing Filemaker. I know the Dabo guys spent a lot of time fighting wxPython. I must confess that I haven't used any of these. I'm just regurgitating talks I've gone to. -jj -- http://jjinux.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Pylons integrated desktop apps?
Based on PyCon talks, Pythoncard takes a lot of the pain out of wxPython. Dabo seems to be aimed squarely at replacing Filemaker. I know the Dabo guys spent a lot of time fighting wxPython. Hmm, having worked a long time as a user of filemaker, that doesn't seem a selling point to me. I really really dislike filemaker UIs. They seem very constrained to the way Filemaker thinks an app should work. Is this likely to be the case with Dabo too? That said, I would love to hear more details on how wxPython is painful and how pythoncard improves it. Based on my overview of wxPython, I just don't see where the pain is, unless it's that people really don't like C++. But it seems to me that a solid gui needs some rigid structure. But I could be way wrong ... Anyone? Iain ( And uh, sorry this has gotten rather OT! ) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Pylons integrated desktop apps?
Mike did the problems with SQLite occur during concurrent(multi thread/ process) read/write access to the db or was this a single instance app? I ask because i'm in the process of evaluating which embeded (r)dbms i should use in an app i'm working on and SQLite is my default fav since i used it in my C++ days without any issues. Thanks for any input on this, Regards, Mayowa. On Mar 12, 9:18 pm, Mike Orr [EMAIL PROTECTED] wrote: 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 pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Pylons integrated desktop apps?
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 pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Pylons integrated desktop apps?
I haven't done it but it's a live issue in our office. I have one site that's a web application (Quixote) and will also be a standalone web application for laptops without Internet access (e.g., for emergency responders on a truck or ship). We debated doing a wxPython interface for the standalone but didn't want to maintain two totally different APIs. wxPython has an HTML panel but I don't think it supports CSS or Javascript, plus how would you make a URL for an intra-application hyperlink? So we decided on a local version of the web application, which has its own set of problems: the browser is an automomous process unless you embed it in a platform-specific way (both Windows and Macintosh), the server is either invisible or has its own little GUI to stop it - which all works differently than a normal application. Some say local web applications will be a lot more common in the future but for now they just look weird to most users. I've seen Dabo twice at PyCon and am impressed by it, both for database CRUD and for general GUI applications. It's much more pythonic than raw wxPython, although I'm not sure how it compares to PythonCard. So, having done it with a local web app and now having seen Dabo, would that change your choice if you were to do it again? I would love to hear more details on how that went if you have time. ( good, bad, interesting, etc ) I am very attracted to the fine grained input control we get with a wxApp, as well as how much easier it would make security; it seems to me that catching admin input errors or sloppy practices can be made a lot more pleasant than the it usually is through a browser. And while I know we *can* do that with javascript, let's face it, it ain't pretty compared to even C++! Personally I really don't think wxPython looks so bad, must be my C audio background. ;) But everyone seems pretty jazzed by Dabo so maybe a Dabo/Pylons combo would be a sweet option. I would also think that a wxPython or wxWidgets app that talked to the db through a socket layer could be made dead easy to install, but as I have not done that, maybe I'm way off base? Anyone know if you can use SQLAlchemy as your backend for Dabo? If not, I would think the smart way to do it would be to make a simple little api or socket server that allowed one to use the same model code for both versions. But it's all brainstorming right now fer me. Thanks Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Pylons integrated desktop apps?
On 3/11/07, iain duncan [EMAIL PROTECTED] wrote: I haven't done it but it's a live issue in our office. I have one site that's a web application (Quixote) and will also be a standalone web application for laptops without Internet access (e.g., for emergency responders on a truck or ship). We debated doing a wxPython interface for the standalone but didn't want to maintain two totally different APIs. wxPython has an HTML panel but I don't think it supports CSS or Javascript, plus how would you make a URL for an intra-application hyperlink? So we decided on a local version of the web application, which has its own set of problems: the browser is an automomous process unless you embed it in a platform-specific way (both Windows and Macintosh), the server is either invisible or has its own little GUI to stop it - which all works differently than a normal application. Some say local web applications will be a lot more common in the future but for now they just look weird to most users. I've seen Dabo twice at PyCon and am impressed by it, both for database CRUD and for general GUI applications. It's much more pythonic than raw wxPython, although I'm not sure how it compares to PythonCard. So, having done it with a local web app and now having seen Dabo, would that change your choice if you were to do it again? I would love to hear more details on how that went if you have time. ( good, bad, interesting, etc ) 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. 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 would also think that a wxPython or wxWidgets app that talked to the db through a socket layer could be made dead easy to install, but as I have not done that, maybe I'm way off base? Anyone know if you can use SQLAlchemy as your backend for Dabo? If not, I would think the smart way to do it would be to make a simple little api or socket server that allowed one to use the same model code for both versions. But it's all brainstorming right now fer me. 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. Dabo uses its own db-unifying code according to my quick glance at the site. Of course you can just use Dabo's UI portion with SQLAlchemy. -- 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 pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Pylons integrated desktop apps?
On Sat, 2007-03-10 at 13:38 -0800, iain duncan wrote: Hi folks, I am just wetting my feet with pylons. I am curious whether anyone on here has experience integrating desktop apps with pylons projects, and if so, would they care to share opinions on feasability, when it is worth, how it went, how they did so? I discussed this on the TurboGears-dev list a while back (and Pylons should be no different in this regard): A while back I built a TurboGears app that utilized XRC (see http://wiki.wxpython.org/index.cgi/UsingXmlResources) templates that wxPython can render as GUI elements. The main application (compiled as an .exe) was little more than a bootstrap loader that downloaded a zipfile of Python modules from the TG server and then rendered each page of the GUI via XRC. Aside from the initial downloading of the Python modules, it worked more or less like a web application: whenever a new page was needed, it fetched the XRC description from the server and rendered it. It worked great, giving all the advantages of a web app (centralized administration and ubiquitous access) and all the benefits of a GUI app (sophisticated UI controls and local system integration). Further, because all the database access was done via normal HTTP (I used pycurl), the GUI app was well-insulated from the underlying implementation and much of the server-side code was reusable for an actual web application as well (the GUI served as the administrative interface for controlling a public-facing website). Were I to do it again (and I'm sure I will) I'd probably use http://techgame.net/projects/Framework/wiki/ rather than plain XRC, however. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Pylons integrated desktop apps?
Cliff Wells wrote: On Sat, 2007-03-10 at 13:38 -0800, iain duncan wrote: Hi folks, I am just wetting my feet with pylons. I am curious whether anyone on here has experience integrating desktop apps with pylons projects, and if so, would they care to share opinions on feasability, when it is worth, how it went, how they did so? I discussed this on the TurboGears-dev list a while back (and Pylons should be no different in this regard): A while back I built a TurboGears app that utilized XRC (see http://wiki.wxpython.org/index.cgi/UsingXmlResources) templates that wxPython can render as GUI elements. The main application (compiled as an .exe) was little more than a bootstrap loader that downloaded a zipfile of Python modules from the TG server and then rendered each page of the GUI via XRC. Aside from the initial downloading of the Python modules, it worked more or less like a web application: whenever a new page was needed, it fetched the XRC description from the server and rendered it. It worked great, giving all the advantages of a web app (centralized administration and ubiquitous access) and all the benefits of a GUI app (sophisticated UI controls and local system integration). Further, because all the database access was done via normal HTTP (I used pycurl), the GUI app was well-insulated from the underlying implementation and much of the server-side code was reusable for an actual web application as well (the GUI served as the administrative interface for controlling a public-facing website). Were I to do it again (and I'm sure I will) I'd probably use http://techgame.net/projects/Framework/wiki/ I checked out the framework and nothing has been done with it in a while and the list has been quite for over a year. Do you know if the project is active? Jose rather than plain XRC, however. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Pylons integrated desktop apps?
A while back I built a TurboGears app that utilized XRC (see http://wiki.wxpython.org/index.cgi/UsingXmlResources) templates that wxPython can render as GUI elements. The main application (compiled as an .exe) was little more than a bootstrap loader that downloaded a zipfile of Python modules from the TG server and then rendered each page of the GUI via XRC. Aside from the initial downloading of the Python modules, it worked more or less like a web application: whenever a new page was needed, it fetched the XRC description from the server and rendered it. It worked great, giving all the advantages of a web app (centralized administration and ubiquitous access) and all the benefits of a GUI app (sophisticated UI controls and local system integration). Further, because all the database access was done via normal HTTP (I used pycurl), the GUI app was well-insulated from the underlying implementation and much of the server-side code was reusable for an actual web application as well (the GUI served as the administrative interface for controlling a public-facing website). hmm, that sounds pretty handy. Any opinions on here about the appropriateness of pythoncard vs dabo vs ra wxPython for this sort of thing? Especially as concerns being able to leave the model code intact for both web and desktop access? ( I personally don't mind the C++'ish ness of raw wxPython if it works better in other areas ) Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Pylons integrated desktop apps?
Hi folks, I am just wetting my feet with pylons. I am curious whether anyone on here has experience integrating desktop apps with pylons projects, and if so, would they care to share opinions on feasability, when it is worth, how it went, how they did so? Despite what many would have me believe, IMHO there are still many cases where a custom desktop app built in wxPython, wxWidgets and/or Dabo has real advantages for an administrator would be doing work on their remote databases ( that are in turn web acessible in some other form ). I already do this kind of stuff for unrelated work where a web browser is totally not an option, so I'm curious about tying them together. And I think that as long as a business is making a comparison between .net, j2ee, and a python based solution, the python solution is going to have to be able to offer up something other web only interaction to be taken seriously. And who the heck wants to use hibernate instead of SQLAlchemy? All input appreciated, iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
