On May 2, 2002 11:16 am, Jeff Johnson wrote: > I had a bit of trouble getting FormKit to work with Cheetah because the > examples in FormKit rely heavily on Page and Cheetah doesn't follow the > conventions of Page. It's my understanding that Page is a convenience > class but more and more code seems to rely on it or it's conventions. > Even Servlet's serverSidePath now relies on Page._request. I'm starting > to think Page should be broken into more classes so SkeletonPage could > inherit more of it. The action handler code and awake/respond/sleep > code could be used by classes that don't want the formatting methods of > Page. > > In Page.awake, self._request = transaction.request(). In > Cheetah.Servlet.awake, self.request = transaction.request. I'm not sure > if it should but WebKit.Servlet assumes that self._request is defined. > Since Cheetah defines self.request instead of self._request, > serverSidePath doesn't work from within Cheetah (using inheritance). > > WebKit: > Are subclasses of Servlet required to define attribues like > self._request as Page does? > If so, this interface should be formalized. SkeletonPage > doesn't follow those conventions. > Should Page be broken up? > Cheetah: > Should attributes like self._request be defined to allow > SkeletonPage to work with code designed for Page? > Should SkeletonPage handle form actions like Page?
Ahh, you've stumbled across a long-standing bug in webkit that I reported sometime last summer. WebKit.Servlet assumes that self._request is defined, but neither Servlet nor HTTPServlet define it. The Page class does. It definitely needs resolving! WebKit's Page and Cheetah's SkeletonPage are both convenience classes and, IMHO, third-party tools like FunFormKit should not rely on them. The formatting methods in those two classes have no place in the standard servlet API. Neither do the 'actions' framework or various convience wrappers in Page. I believe the methods in Servlet and HTTPServlet are sufficient, provided they all work properly. Any other opinions? Unfortunately there is no simple / clean way to resolve this in WebKit at present. It's possible for Servlet to be reentrant for thread-safe use, therefore we can't just add an _request attribute in Servlet.awake() or HTTPServlet.awake(). The long term solution is to shift the responsibility for knowing the serverSidePath from Request to Servlet. This is what I have done in WebwareExpRefactoring, but it would be very complicated to port this change to the official WebKit codebase because major portions of Application.py are involved. Later this month I'll have WebwareExpRefactoring ready for compatibility testing, as we discussed last month. In the meantime, we can add a _request attribute to Cheetah.Servlet with a big warning that it will disappear when this issue is resolved in WebKit. As I've argued before, Request and HTTPRequest should NOT know about the serverSide mapping of a request (serverSidePath, serverSideContextPath, etc.). That should be the sole responsibility of the Servlet and Application classes. Maybe this knowledge should even be factored out of the Application class as part of the UrlDecoding extensions that are being discussed. Along the same lines, HTTPRequest should not about sessions. That should be the sole responsibility of the Application and Transaction classes. Your thoughts? Am I just a lone heretic?? ;) Tavis _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
