From: Tavis R. <ta...@re...> - 2002-05-02 23:22:56
|
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 startin= g > 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 =3D transaction.request(). In > Cheetah.Servlet.awake, self.request =3D transaction.request. I'm not s= ure > 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: > =09Are subclasses of Servlet required to define attribues like > self._request as Page does? > =09If so, this interface should be formalized. SkeletonPage > doesn't follow those conventions. > =09Should Page be broken up? > Cheetah: > =09Should attributes like self._request be defined to allow > SkeletonPage to work with code designed for Page? > =09Should SkeletonPage handle form actions like Page? Ahh, you've stumbled across a long-standing bug in webkit that I reported= =20 sometime last summer. WebKit.Servlet assumes that self._request is defin= ed,=20 but neither Servlet nor HTTPServlet define it. The Page class does. It definitely needs resolving! WebKit's Page and Cheetah's SkeletonPage = are=20 both convenience classes and, IMHO, third-party tools like FunFormKit sho= uld=20 not rely on them. The formatting methods in those two classes have no pla= ce=20 in the standard servlet API. Neither do the 'actions' framework or vario= us=20 convience wrappers in Page. I believe the methods in Servlet and HTTPSer= vlet=20 are sufficient, provided they all work properly. Any other opinions? Unfortunately there is no simple / clean way to resolve this in WebKit at= =20 present. It's possible for Servlet to be reentrant for thread-safe use,=20 therefore we can't just add an _request attribute in Servlet.awake() or=20 HTTPServlet.awake(). The long term solution is to shift the responsibili= ty=20 for knowing the serverSidePath from Request to Servlet. This is what I h= ave=20 done in WebwareExpRefactoring, but it would be very complicated to port t= his=20 change to the official WebKit codebase because major portions of=20 Application.py are involved. =20 Later this month I'll have WebwareExpRefactoring ready for compatibility=20 testing, as we discussed last month. In the meantime, we can add a _reque= st=20 attribute to Cheetah.Servlet with a big warning that it will disappear wh= en=20 this issue is resolved in WebKit. As I've argued before, Request and HTTPRequest should NOT know about the=20 serverSide mapping of a request (serverSidePath, serverSideContextPath,=20 etc.). That should be the sole responsibility of the Servlet and Applica= tion=20 classes. Maybe this knowledge should even be factored out of the Applica= tion=20 class as part of the UrlDecoding extensions that are being discussed. Al= ong=20 the same lines, HTTPRequest should not about sessions. That should be th= e=20 sole responsibility of the Application and Transaction classes. Your=20 thoughts? Am I just a lone heretic?? ;) Tavis |
From: Terrel S. <tsh...@uc...> - 2002-05-04 23:37:44
|
On Thu, 2002-05-02 at 16:38, Tavis Rudd wrote: > On May 2, 2002 11:16 am, Jeff Johnson wrote: > > 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). > > > > 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. The "_" at the front of _request should be clue enough that it is part of a *private* API. Any code independent of the implementation of Page that uses it has already been given ample warning that it could go away some day. If Cheetah is adding a "request" attribute, then 1) it is announcing a public interface 2) it is violating a webware style guide for method and attribute names. (should be "request(self): return self._request_or_something") (However, the *intent* of this style guide seems to have been defeated by the sprinkling of Page._request throughout the code.) If FormKit relies on Page._request, then FormKit is also broken. There probably should be a public interface for getting the request for any servlet. It probably should not be stored as an attribute in the servlet, because doing so prevents sharing the servlet among threads. |
From: Tavis R. <ta...@re...> - 2002-05-05 00:09:29
|
On May 4, 2002 04:37 pm, Terrel Shumway wrote: > On Thu, 2002-05-02 at 16:38, Tavis Rudd wrote: > > On May 2, 2002 11:16 am, Jeff Johnson wrote: > > > In Page.awake, self._request =3D transaction.request(). In > > > Cheetah.Servlet.awake, self.request =3D transaction.request. I'm n= ot > > > sure if it should but WebKit.Servlet assumes that self._request is > > > defined. Since Cheetah defines self.request instead of self._reques= t, > > > serverSidePath doesn't work from within Cheetah (using inheritance)= =2E > > > > Ahh, you've stumbled across a long-standing bug in webkit that I repo= rted > > sometime last summer. WebKit.Servlet assumes that self._request is > > defined, but neither Servlet nor HTTPServlet define it. The Page cla= ss > > does. > > The "_" at the front of _request should be clue enough that it is part > of a *private* API. Any code independent of the implementation of Page > that uses it has already been given ample warning that it could go away > some day. You've missed the point. Cheetah doesn't want access to _request,=20 WebKit.Servlet.Servlet.serverSidePath() does, but it can't find it becaus= e it=20 is only defined in the Page class. > If Cheetah is adding a "request" attribute, then Cheetah isn't. It's adding a request() method by mapping to trans.reques= t(). Tavis |
From: Terrel S. <tsh...@uc...> - 2002-05-05 01:35:08
|
On Sat, 2002-05-04 at 17:25, Tavis Rudd wrote: > > You've missed the point. Cheetah doesn't want access to _request, > WebKit.Servlet.Servlet.serverSidePath() does, but it can't find it because it > is only defined in the Page class. > > > If Cheetah is adding a "request" attribute, then > > Cheetah isn't. It's adding a request() method by mapping to trans.request(). > Oops. Sorry about that. Your solution is a better one. (still not threadsafe, but no one seems to care anyway.) |
From: Geoffrey T. <gta...@at...> - 2002-05-09 13:10:14
|
On Saturday May 04, 2002 08:25 pm, Tavis Rudd wrote: > On May 4, 2002 04:37 pm, Terrel Shumway wrote: > > On Thu, 2002-05-02 at 16:38, Tavis Rudd wrote: > > > On May 2, 2002 11:16 am, Jeff Johnson wrote: > > > > 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). > > > > > > 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. > > > > The "_" at the front of _request should be clue enough that it is part > > of a *private* API. Any code independent of the implementation of Page > > that uses it has already been given ample warning that it could go away > > some day. > > You've missed the point. Cheetah doesn't want access to _request, > WebKit.Servlet.Servlet.serverSidePath() does, but it can't find it because > it is only defined in the Page class. Which seems like a design flaw -- Servlet should not be dependent at all on stuff defined only in derived classes. If there's a clean and easy way to fix it, we should do it. - Geoff |