From: Richard J. <ric...@op...> - 2000-11-14 23:04:01
|
I'm just getting back into web stuff with Python and am giving webware the once over. I'm finding there's a fair amount of structural documentation missing. I'm not afraid to UTSL, but real structural doc would be nice - however brief (my apologies if I've just plain missed it.) Way back in the days of Bobo, I was a very happy camper. I could write some really nice, simple objects that were published on the web with a minimum of fuss - as long as I remembered the Bobo hoops to jump through that is :) The Object publishing aspect of Bobo / ZPublisher really was its killer feature as far as I'm concerned (I was so convinced, I wrote a similar mechanism for Perl.) I see webware as a Good Thing - nice and simple and OO. I would really like to see object publishing make its way into webware somehow. I think it's possible by extending HTTPServlet and using forwardRequestFast. Oject publishing, Bobo style, involves splitting the PATH_INFO and walking down through an object tree using the PATH_INFO fragments to identify attributes to use, mapping entries to access and methods to call. The method calls are passed arguments from the request according to their signature. The stopping condition in Bobo was returning something other than a publishable item I think (my Perl version stopped on the condition of text being returned, and it worked fine). At the most basic, this means that: class Wiki: def __getitem__(self, name): return self.wiki_items[name] def new(self, name): return HTML def newSubmit(self, name, new_text): create new item return redirect to new item class WikiItem: def index_html(self): return HTML def edit(self): return HTML def editSubmit(self, new_text): save new_text return HTML And we'd be publishing an instance of Wiki called wiki_instance, so a CGI access of '.../wiki/WikiInPython/edit' would access the wiki_instance object, then wiki_instance['WikiInPython'] and finally wiki_item_instance.edit(). Similarly, '.../wiki/WikiInPython/editSubmit?new_text="blah blah"' would call wiki_item_instance.editSubmit("blah blah") - and possibly throw an exception if new_text wasn't supplied (I forget what the behaviour was). Anyway, it made developing CGI so much easier not having to worry about decoding the PATH_INFO yourself and obtaining your arguments from the request. Of course, there are circumstances where forms are more complex than that, but they're the minority. What do you think? Richard |
From: Geoff T. <gta...@na...> - 2000-11-14 23:54:10
|
Richard Jones wrote: <snip> > Oject publishing, Bobo style, involves splitting the PATH_INFO and walking > down through an object tree using the PATH_INFO fragments to identify > attributes to use, mapping entries to access and methods to call. The method > calls are passed arguments from the request according to their signature. > The stopping condition in Bobo was returning something other than a > publishable item I think (my Perl version stopped on the condition of text > being returned, and it worked fine). At the most basic, this means that: > > class Wiki: > def __getitem__(self, name): > return self.wiki_items[name] > def new(self, name): > return HTML > def newSubmit(self, name, new_text): > create new item > return redirect to new item > > class WikiItem: > def index_html(self): > return HTML > def edit(self): > return HTML > def editSubmit(self, new_text): > save new_text > return HTML > > And we'd be publishing an instance of Wiki called wiki_instance, so a CGI > access of '.../wiki/WikiInPython/edit' would access the wiki_instance > object, then wiki_instance['WikiInPython'] and finally > wiki_item_instance.edit(). Similarly, > '.../wiki/WikiInPython/editSubmit?new_text="blah blah"' would call > wiki_item_instance.editSubmit("blah blah") - and possibly throw an exception > if new_text wasn't supplied (I forget what the behaviour was). Sounds intriguing. Some questions that pop into my mind: - What is the lifetime of the Wiki class instance in the above example? In Zope, you've got persistent objects stored in the ZODB -- objects live forever or until they are explicitly deleted. But in WebKit, there's no ZODB, so when does the Wiki class object get instantiated? Is there one global instance that gets created the first time it's needed, then sticks around until WebKit is restarted? You'd need loading and saving code to make sure that if WebKit is restarted, you've still got your objects. - If we assume the Wiki object is a single global instance, then you have to write the objects to be thread-safe, since WebKit is a threaded app server. Not a problem, just something to be aware of. I guess Zope probably has the same issue. - What if you don't want to publish all methods of your class through the web -- how do you mark certain methods as public and certain ones as private? Sounds like an interesting project. I'd especially be interested in seeing a "before and after" showing how you'd implement some simple application with plain WebKit, and then the object publishing version, presumably much simpler and easier to understand, otherwise why bother :-) -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Chuck E. <ec...@mi...> - 2000-11-15 00:07:44
|
At 06:56 PM 11/14/00 -0500, Geoff Talvola wrote: >Sounds intriguing. Some questions that pop into my mind: > >- What is the lifetime of the Wiki class instance in the above example? In >Zope, you've got persistent objects stored in the ZODB -- objects live forever >or until they are explicitly deleted. But in WebKit, there's no ZODB, so when >does the Wiki class object get instantiated? Is there one global instance >that >gets created the first time it's needed, then sticks around until WebKit is >restarted? You'd need loading and saving code to make sure that if WebKit is >restarted, you've still got your objects. If you could manage to make Wiki a subclass of servlet, then you're pretty much set for loading code and instantiation, but not for persistence of attributes that have changed. Frankly, I'm wondering if such persistence is better saved for "domain" objects that aren't necessarily wrapped into the interface. But maybe I'm just missing a different angle. >- If we assume the Wiki object is a single global instance, then you have to >write the objects to be thread-safe, since WebKit is a threaded app >server. Not >a problem, just something to be aware of. I guess Zope probably has the same >issue. You should be able to use the AppServer class, which is parent to ThreadedAppServer. That was an intentional move on my part for just such a case. e.g., if you want a single tasking app server for your pet project, you've got one. >- What if you don't want to publish all methods of your class through the >web -- >how do you mark certain methods as public and certain ones as private? The action feature of Page provides this protection by only allowing actions returned by the actions() method and then filtering those names through a methodNameForAction() method that can mangle them or fix them if that's appropriate (and often necessary since you can't distinguish a buttons name from it's visible title which can often have spaces). -Chuck |
From: Richard J. <ric...@op...> - 2000-11-15 00:51:01
|
From: "Geoff Talvola" <gta...@na...> > - What is the lifetime of the Wiki class instance in the above example? In > Zope, you've got persistent objects stored in the ZODB -- objects live forever > or until they are explicitly deleted. But in WebKit, there's no ZODB, so when > does the Wiki class object get instantiated? Is there one global instance that > gets created the first time it's needed, then sticks around until WebKit is > restarted? You'd need loading and saving code to make sure that if WebKit is > restarted, you've still got your objects. Forget about ZODB - it wasn't available in the Bobo days. From memory, there was a top-level instance that was passed to the the publisher. wiki_instance = Wiki() bobo.publish(wiki_instance) ... and publish took care of the rest. > - If we assume the Wiki object is a single global instance, then you have to > write the objects to be thread-safe, since WebKit is a threaded app server. Not > a problem, just something to be aware of. I guess Zope probably has the same > issue. Yep. > - What if you don't want to publish all methods of your class through the web -- > how do you mark certain methods as public and certain ones as private? Bobo used a hack - only methods with docstrings could be published. I'd much rather see something a little more formal than that. A method that returns publishable methods is one idea - the default being to use a list of method names. > Sounds like an interesting project. I'd especially be interested in seeing a > "before and after" showing how you'd implement some simple application with > plain WebKit, and then the object publishing version, presumably much simpler > and easier to understand, otherwise why bother :-) Hrm - ok, I'll give it a go, assuming that we can get object publishing working :) Richard |
From: Ender <kth...@ea...> - 2000-11-15 07:42:58
|
if you crave object publishing, and dislike zope there always quixote http://www.mems-exchange.org/exchange/software/python/quixote/ kapil Richard Jones wrote: > > I'm just getting back into web stuff with Python and am giving webware the > once over. I'm finding there's a fair amount of structural documentation > missing. I'm not afraid to UTSL, but real structural doc would be nice - > however brief (my apologies if I've just plain missed it.) > > Way back in the days of Bobo, I was a very happy camper. I could write some > really nice, simple objects that were published on the web with a minimum of > fuss - as long as I remembered the Bobo hoops to jump through that is :) The > Object publishing aspect of Bobo / ZPublisher really was its killer feature > as far as I'm concerned (I was so convinced, I wrote a similar mechanism for > Perl.) > > I see webware as a Good Thing - nice and simple and OO. I would really like > to see object publishing make its way into webware somehow. I think it's > possible by extending HTTPServlet and using forwardRequestFast. > > Oject publishing, Bobo style, involves splitting the PATH_INFO and walking > down through an object tree using the PATH_INFO fragments to identify > attributes to use, mapping entries to access and methods to call. The method > calls are passed arguments from the request according to their signature. > The stopping condition in Bobo was returning something other than a > publishable item I think (my Perl version stopped on the condition of text > being returned, and it worked fine). At the most basic, this means that: > > class Wiki: > def __getitem__(self, name): > return self.wiki_items[name] > def new(self, name): > return HTML > def newSubmit(self, name, new_text): > create new item > return redirect to new item > > class WikiItem: > def index_html(self): > return HTML > def edit(self): > return HTML > def editSubmit(self, new_text): > save new_text > return HTML > > And we'd be publishing an instance of Wiki called wiki_instance, so a CGI > access of '.../wiki/WikiInPython/edit' would access the wiki_instance > object, then wiki_instance['WikiInPython'] and finally > wiki_item_instance.edit(). Similarly, > '.../wiki/WikiInPython/editSubmit?new_text="blah blah"' would call > wiki_item_instance.editSubmit("blah blah") - and possibly throw an exception > if new_text wasn't supplied (I forget what the behaviour was). > > Anyway, it made developing CGI so much easier not having to worry about > decoding the PATH_INFO yourself and obtaining your arguments from the > request. Of course, there are circumstances where forms are more complex > than that, but they're the minority. > > What do you think? > > Richard > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > http://lists.sourceforge.net/mailman/listinfo/webware-discuss |