Re: GNUJSP: Multiviews cont'd, design proposal

[Carsten Heyl <heyl@nads.de>]

>Carsten Heyl wrote:
>
>> We have different jspURIs we use to locate the page object
>> which all use the same jsp files but generate different
>> servlets ...
>> I think the mapping jsp file <-> jsp servlets shoule be one to one
>> to we would need to
>>
>>         - store jsp pages by jspURL
>>         - generate servlet names (again, sigh :-( by using
>>           the jspURL.


Matthias Henze made me think of the following approach:
	jspURI	/x/y/mypage
	jspURL  .../dir/x/y/mypage.en.jsp

	can be merged to
	
	/x/y + "/" + mypage.en.jsp

	that would avoid path names and make the URI used to
	locate the page object unique and reproducable.
	Would that break something?

BTW:
	How does the whole stuff fit into precompiled pages
	without jsp source available?
	Would PathTranslated be set for them?


>>
>> I didn't like the second but I didn't see a way to avoid that.
>> Servlet names will get longer and will contain info about
>> the local file systenm path which I would like to hide.
>>
>> Opinons?
>
>Carsten, I think your approach is sound.  I would be interested in seeing how
>Jakarta handles or plans to handle these mappings.  Does anyone have it
>running for comparison?
>
>One note: we should be careful not to assume that jspURL is of type "file:".

O.K., I see what you mean. The key used to locate the jsp page should
be kept separate from the jspURL just describing the place where
the object is stored.

>
>We still need better documentation for what happens in all the URI/URL related
>methods.  Most now use JspParserContext (which is now something of a
>misnomer).  I was thinking of moving that code to something like

Yep, it grew up.

>"PathTranslator.java".
>
>A somewhat radical approach: change to a pluggable architecture where we
>detect the servlet engine (by context info or initArgs) and dynamically load a
>PathTranslator for that engine (e.g. JServPathTranslator,
>JigsawPathTranslator, VQServerPathTranslator).  This would make the code
>infinitely more readable, but would not be as generic of a solution (it would
>require us, or the servlet engine author(s), to provide an implementation of
>PathTranslator for each engine.)  On the other hand it would make the code run
>faster too.
>
>Thoughts on that approach?

That may solve some issues but a few suggestions:

	1. Don't fix it to PathTranslator. I would like to be something 
	   like a ServletEngineContext which provides path translation
	   services but may also contain the infos about the engines
	   (brokenXY, needsXY) if that stuff is still needed somewhere
	   or other stuff which we may think of later which is 
	   different.

	2. Provide a default ServletEngineContext which uses an
	   implemenentation based on our current opinions how
	   the different pathes should be gathered.

BTW:
	I changed JspServlet in my working copy to use
	the different order in getServletPath/getRequestURI/getPathInfo
	but couldn't finish it due to time limits.
	It does not work out of the box because it's shows
	another problem in the Wrapper-Stuff.
	No time to do it, yet, feel free if you want to do that.
	Maybe the ServletEngineContext will help here, too.
>
>Wes
>
>
>

Ciao,
	Carsten
alph@gjt.org