Stuart Donaldson [mailto:[EMAIL PROTECTED]] 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: [EMAIL PROTECTED]
> >-----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
> >[EMAIL PROTECTED]
> >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
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/webware-devel
>
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
