Crazy idea: ZClasses
It's Friday, so I reserve the right to post crazy ideas. :-) Ape could revitalize ZClasses. The biggest problem with ZClasses has always been the inability to use version control and other utilities to maintain ZClass code. Ape could fix that by giving developers the option of storing ZClass code on the filesystem. It doesn't allow it now, but it could without huge effort. I thought of this a couple of weeks ago. I pushed it out of my mind because Zope 3 will eliminate the need for ZClasses, but the idea kept coming back. So if anyone wants to take this on, I'll provide direction, but I don't plan to do it all myself. Shane
On Fri, Apr 11, 2003 at 02:27:06PM -0400, Shane Hathaway wrote: | It's Friday, so I reserve the right to post crazy ideas. :-) | | Ape could revitalize ZClasses. The biggest problem with ZClasses has | always been the inability to use version control and other utilities to | maintain ZClass code. Ape could fix that by giving developers the | option of storing ZClass code on the filesystem. It doesn't allow it | now, but it could without huge effort. | | I thought of this a couple of weeks ago. I pushed it out of my mind | because Zope 3 will eliminate the need for ZClasses, but the idea kept | coming back. So if anyone wants to take this on, I'll provide | direction, but I don't plan to do it all myself. There is an ongoing discussion over the last months about doing TTW Archetypes, which would be very similar to ZClasses, but way more powerful and customizable. Maybe its an option to consider. fainted-at-looking-at-how-zclasses-are-stored-and-loaded'ly yours, -- Sidnei da Silva (dreamcatcher) <sidnei@x3ng.com.br> X3ng Web Technology <http://www.x3ng.com.br> GNU/Linux user 257852 Debian GNU/Linux 3.0 (Sid) 2.4.18 ppc Beware of the Turing Tar-pit in which everything is possible but nothing of interest is easy.
Hi, I'm about to implement a view dispatcher and realized a problem that I keep bumping into. Using *:method (or *:action) in HTML form to direct the submission to a special method works fine in most cases but leaves the URL in the browser window short of the method used. This makes handling of forms a little bit inconsistent, so I usually try to avoid it. But I would like to add a similar approach *:dispatcher where instead of redirecting the call to a methods the value (*) would be converted to a key:value par in the REQUEST object. The value of a submit button can't be used because it's the text of the button, and even though it's used in allot of the ZMI it's easy to break code when the result method depends on a specific value of the submit button. So: <form method="dispatcher_url"> <input type="submit" name="do_this:dispatcher" value=" Do This "> </form> would add REQUEST['dispatcher']='do_this' This would then be easy for the dispatcher method at 'dispatcher_url' to handle in a if-else structure (etc): if REQUEST['dispatcher']=='do_this': return self.do_this() elif REQUEST['dispatcher']=='do_that': return self.do_that() else: return self.just_show_it() It would be quite a small change in the HTTPRequest. Any thoughts? Johan Carlsson -- Easy Publisher Developers Team Johan Carlsson johanc@easypublisher.com Mail: Birkagatan 9 SE-113 36 Stockholm Sweden Phone +46-(0)8-31 24 94 Fax +46-(0)8-673 04 44 Mobil +46-(0)70-558 25 24 http://www.easypublisher.com
Hi Johan, a possibly very stupid question:
So: <form method="dispatcher_url"> <input type="submit" name="do_this:dispatcher" value=" Do This "> </form>
would add REQUEST['dispatcher']='do_this'
and <form action="dispatcher_url"> <input type="submit" name="this_one" value=" Do This "> </form> currently adds REQUEST['this_one']=' Do This ' thus instead of:
This would then be easy for the dispatcher method at 'dispatcher_url' to handle in a if-else structure (etc):
if REQUEST['dispatcher']=='do_this': return self.do_this() elif REQUEST['dispatcher']=='do_that': return self.do_that() else: return self.just_show_it()
one could say: if REQUEST.get('this_one',None): return self.do_this() elif REQUEST.get('that_one',None): return self.do_that() else: return self.just_show_it() Maybe I have overlooked something, but it looks like the functionality can be obtained with the current implementation without adding one more magic ':', doesn't it? just asking, Clemens
At 21:40 2003-04-14 +0200, Clemens Robbenhaar said:
Hi Johan, a possibly very stupid question:
Hi Clemens, I don't believe there is such a thing ;-)
So: <form method="dispatcher_url"> <input type="submit" name="do_this:dispatcher" value=" Do This "> </form>
would add REQUEST['dispatcher']='do_this'
and
<form action="dispatcher_url"> <input type="submit" name="this_one" value=" Do This "> </form>
currently adds REQUEST['this_one']=' Do This '
thus instead of:
This would then be easy for the dispatcher method at 'dispatcher_url' to handle in a if-else structure (etc):
if REQUEST['dispatcher']=='do_this': return self.do_this() elif REQUEST['dispatcher']=='do_that': return self.do_that() else: return self.just_show_it()
one could say:
if REQUEST.get('this_one',None): return self.do_this() elif REQUEST.get('that_one',None): return self.do_that() else: return self.just_show_it()
Maybe I have overlooked something, but it looks like the functionality can be obtained with the current implementation without adding one more magic ':', doesn't it?
Fair point. You wouldn't get the possibility to extract the name of the operation to be performed, try if it exist and execute it: method_id = REQUEST.get('dispatcher') method = getattr(self, method_id, None) Which I probably going to need for my dispatcher class. One other thing I noticed, but which I'm not sure is useful, is the possibility of submitting several method_ids: <input type="hidden" name="dispatcher" value="always_do"> <input type="submit" name="do_this:dispatcher" value=" Do This (and more) "> This might very well be something that only I want (so I'll probably end up "hot-patching" it anyway) It would be nice to have some kind of plug-in capabilities in the ZPublisher form field handling. It would make it possible to handle custom fields like something like Formulator Field in an more integrated fashion. Regards, Johan Carlsson -- Easy Publisher Developers Team Johan Carlsson johanc@easypublisher.com Mail: Birkagatan 9 SE-113 36 Stockholm Sweden Phone +46-(0)8-31 24 94 Fax +46-(0)8-673 04 44 Mobil +46-(0)70-558 25 24 http://www.easypublisher.com
Johan Carlsson [EasyPublisher] wrote:
<form method="dispatcher_url"> <input type="submit" name="do_this:dispatcher" value=" Do This "> </form>
would add REQUEST['dispatcher']='do_this'
Icky Hacky: <input type="submit" name="dispatcher.do_this:record" value=" Do This "> <input type="submit" name="dispatcher.do_that:record" value=" Do This "> ...then: target = dispatcher.keys()[0] Cheers, Evan @ 4-am
At 17:16 2003-04-14 -0500, Evan Simpson said:
Johan Carlsson [EasyPublisher] wrote:
<form method="dispatcher_url"> <input type="submit" name="do_this:dispatcher" value=" Do This "> </form> would add REQUEST['dispatcher']='do_this'
Icky Hacky:
<input type="submit" name="dispatcher.do_this:record" value=" Do This "> <input type="submit" name="dispatcher.do_that:record" value=" Do This ">
...then:
target = dispatcher.keys()[0]
I could run in to trouble if someone accidently adds a <input name="dispatcher.unknown_stuff:record"> because keys()[0] wouldn't necessary be the method. Of course my suggestion has a similar problem, but the result of dispatcher would be a list if there is more than one dispatcher field other than. I tested how the method/action works and it executes the last field (having an :method or :action). Best Regards, Johan Carlsson -- Easy Publisher Developers Team Johan Carlsson johanc@easypublisher.com Mail: Birkagatan 9 SE-113 36 Stockholm Sweden Phone +46-(0)8-31 24 94 Fax +46-(0)8-673 04 44 Mobil +46-(0)70-558 25 24 http://www.easypublisher.com
participants (5)
-
Clemens Robbenhaar -
Evan Simpson -
Johan Carlsson [EasyPublisher] -
Shane Hathaway -
Sidnei da Silva