On Wed, 2002-10-09 at 14:13, Matthew J. Feifarek wrote: > >But how is putting the code in handleActions different from putting it > >in writeContent or awake? > > > > > Well, it's not really, as you said, one can do the same thing either > place. It just seems to me that having BOTH is awkward. As long as we're > using actions, might as well use them.
Yes, having just one way is better. Wouldn't actions be more useful during setup, though, as opposed to rendering? I.e., writeHTML (or the equivalent) should happen no matter what. > Now, my opinion is a little harsher: I think "writeXXX" methods should > be used only for writing... for output. I use awake a lot for > application logic, but because awake is so important to the WebKit > internals, it's a little dangerous to use, and can get severly > complicated when using 3 or 4 kits at once. In general, I'd like to see > only superclasses mess with awake, and have leaf servlets not touch > awake at all. With the current architecture, that's not realistic. With my new version of page, I've been using setup() for the servlet, and putting more site-wide stuff in awake() -- so that my SitePage defines awake(), but none of the other pages mess with it. So we're probably thinking along the same lines. I wouldn't necessarily want to enforce the logic/display separation -- when I'm tweaking I often mix the two liberally, and then clean it up later once I know what I'm trying to do. But I think more could be done to encourage the separation. > >My solution was to stop using awake/sleep, and to put a > >setup/writeHTML/teardown sequence in respond. Then respond (in your new > >Page) catches all the exceptions. No hacking about, and has the same > >effect. > > > > > We thought about that, but decided that it's too different from stock > webkit; our code would effectively be broken off from Page.py at that > point. The mixin to Transaction seemed to be the least fundamental > difference to the stock behavior. But I agree that your idea is better > in principle. Well, Page isn't really that long, so I didn't feel it was a problem to reimplement it. > Right now, it's possible to write tight OO servlets, but the general > structure of Page.py and the lifecycle of a servlet doesn't encourage > it... it encourages just putting all of your logic in writeContent(), > and at that point, you're not much better off than in the old .asp days. > > A new structure that encouraged one to get all of their setup done up > front, and then proceed to output would be nice. I suppose that's what > awake() is for... Yes, awake() is there, but it's only a very loose guide for the structure. I'm also interested in getting something together where Cheetah (or for that matter, any template) can be plugged in easily. I think this would go along, because it involves separating action and code (written in Python) from display (written in Cheetah or somesuch). > >thinking in terms of a replacement for Page that doesn't try to be > >backward compatible (or, rather, an alternative to Page). > > > > > I'm very interested in what you come up with. We'll think on it, too. Check out NewPage in WebKit/Experimental in CVS. It changes respond like I mentioned above. I'm interested in refactoring it more, though, so I'm looking for suggestions. Ian ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
