From: Geoffrey T. <gta...@na...> - 2003-01-13 16:10:34
|
Stuart Donaldson [mailto:st...@as...] wrote: > What should the behavior of the relative URL code be? forward() > includeURL() and callMethodOfServlet() all do something very > similar and > result in calling request.setURLPath(). > > Should root be the root of the context? That would be my vote -- the root of the context. > Should root be the root of the adapter? (ie: you can specify another > context here?) > > And how should it operate when using the psp-handler where > there is no > Context? It would be nice to be able to reference something in a > webware context. I would think that when using psp-handler, you should only be able to go to another psp-handler page, not into a context. Another approach is to add an optional context=None parameter to these three methods. By default they would stay within the same context, but you could forward into a different context by explicitly specifying a context. It would be an error to specify another context and NOT use an absolute path starting with a '/'. I'm frankly not sure if it's worth the effort to support this though. > Also, all three of the application methods mentioned above > both save the > old urlPath, and servlet, and then restore them again, > operating on the > request in multiple areas, and the transaction._servlet. > > This is very closely related to some problems I am working on > in dealing > with parsing the environment in the request for the > psp-handler which I > am also using, I would like to have a way to reference > servlets in the > webware contexts. However this requires mucking with more > information > inside of the request module. How should a context be referenced > without overriding URL references which may already exist? ie: if > "/servlet" refers to a servlet under the current context, > "/context/otherservlet" would conflict with a servlet in the current > context and the same name. We could introduce "/../context" as one > option? Or possibly allow a syntax like ":/context" where > the leading > ':' indictes a switch in context? > > Anyway, I am considering adding a pushURLPath() and > popURLPath() on the > request which would do most of the work mentioned in Luke's > patch, but > also centralize all of the special fixups and cleanups done in the > request. > > Comments anyone? > > -Stuart- > > > Luke Holden wrote: > > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >It looks like includeURL only works with paths reletive to > the current > >directory? > > > >For example... > >If I have the following directory layout: > >SiteContext/ > >SiteContext/navigation > >SiteContext/test > > > >self.includeURL("/navigation/nav") > >works from > >SiteContext, but not from SiteContext/test > >However... > >self.includeURL("../navigation/nav") > >DOES work from SiteContext/test... but is not what I'm looking for =) > > > >Shouldnt includeURL work from both the context root AND the > current directory? > >self.includeURL("navigation/nav") > >for current dir.. > >self.includeURL("/navigation/nav") > >for context root > > > > > >Here is my traceback: > > > >Traceback (most recent call last): > > File "./WebKit/Application.py", line 394, in dispatchRequest > > File "./WebKit/Application.py", line 529, in handleInvalidSession > > File "./WebKit/Application.py", line 564, in handleGoodURL > > File "./WebKit/Application.py", line 756, in respond > > File "./WebKit/Transaction.py", line 105, in respond > > File "./WebKit/HTTPServlet.py", line 38, in respond > > File "./WebKit/Page.py", line 35, in respondToGet > > File "./WebKit/Page.py", line 74, in _respond > > File > "/home/alterself/public_html/SiteContext/layout/BaseLayout.py", line > >21, in writeHTML > > File > "/home/alterself/public_html/lib/layout/SiteLayout.py", line 6, in > >writeHTMLBody > > self.includeURL("/navigation/nav") > > File "./WebKit/Page.py", line 340, in includeURL > > File "./WebKit/Application.py", line 669, in includeURL > > File "./WebKit/Application.py", line 996, in > createServletInTransaction > >AssertionError > > > > > >- -- > >Luke Holden > >eBI Solutions > >Main: (949) 387-5182 > >Email: lh...@eb... > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.2.1 (GNU/Linux) > > > >iD8DBQE+HekQ3q5xXfLZTQkRAn6QAJ97BwXsIPg2O9A7uNeY53h+r78HGgCfShdm > >M9qmMQcmJbDMe6tdEVujsso= > >=a4+E > >-----END PGP SIGNATURE----- > > > > > > > >------------------------------------------------------- > >This SF.NET email is sponsored by: > >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > >http://www.vasoftware.com > >_______________________________________________ > >Webware-devel mailing list > >Web...@li... > >https://lists.sourceforge.net/lists/listinfo/webware-devel > > > > > > > > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Webware-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-devel > |