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=
> 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
> In Page.awake, self._request =3D transaction.request(). In
> Cheetah.Servlet.awake, self.request =3D transaction.request. I'm not s=
> 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).
> =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?
> =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=
sometime last summer. WebKit.Servlet assumes that self._request is defin=
but neither Servlet nor HTTPServlet define it. The Page class does.
It definitely needs resolving! WebKit's Page and Cheetah's SkeletonPage =
both convenience classes and, IMHO, third-party tools like FunFormKit sho=
not rely on them. The formatting methods in those two classes have no pla=
in the standard servlet API. Neither do the 'actions' framework or vario=
convience wrappers in Page. I believe the methods in Servlet and HTTPSer=
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,=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=
for knowing the serverSidePath from Request to Servlet. This is what I h=
done in WebwareExpRefactoring, but it would be very complicated to port t=
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=
attribute to Cheetah.Servlet with a big warning that it will disappear wh=
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=
classes. Maybe this knowledge should even be factored out of the Applica=
class as part of the UrlDecoding extensions that are being discussed. Al=
the same lines, HTTPRequest should not about sessions. That should be th=
sole responsibility of the Application and Transaction classes. Your=20
thoughts? Am I just a lone heretic?? ;)