on 12/15/99 3:57 PM, Kevin A. Burton <[EMAIL PROTECTED]> wrote:
> So looking at the differences between the Jakarta JSDK 2.2 source and
> JSDK 2.0, makes it a hard decision the impl of WebMacro, Cocoon, JSP
> (general Servlet Embeding).
>
> The problem is that with JSDK 2.2 you can call:
>
> RequestDispatcher.include()
>
> and you will get a requested servlet's output in your own servlet.
>
> This would technically work but Screen.build() has to return a
> ConcreteElement. Which basically means I need to actually get the
> output of this servlet.
Actually, Screen.build() doesn't have to return anything. You can return
stuff directly through data.getOut(). That is how I envision this stuff
working. Note that if you use data.getOut() you are also responsible for
setting HTTP headers appropriately.
> So the way I am thinking of doing it is through emulating the servlet
> engine.
No. Bad. You are opening up a HUGE can of worms here. You can't ever emulate
the servlet engine...you will end up re-writing the servlet engine and that
wouldn't be a good idea...at least not until Tomcat is done. Although,
imagine being able to create your own instance of a servlet engine directly
within a servlet. ;-) Ahahahaahahah.
> Creating my own servlet context from the current servlet context,
> calling init() assuming it hasn't been inited (but there might not be an
> easy way to figure this out).
right...the issues like that would mean that you would also have to track
all of that stuff that a servlet engine normally tracks. duplication of
effort.
> Then I would have to provide my own HttpServletRequest that provide a
> different getServletPath() and a different ServletOutputStream that I
> can get as a String so I can return it as a ConcreteElement for return
> in build().
>
> Thoughts?
>
> It is slightly a hack but would work well across JSDK 2.2 and JSDK 2.0
I had originally gone down this route until someone pointed out the fact
that I would have to implement the servlet engine. I think that is bad...see
below for my alternative options...
My 2 minute thoughts are this:
#1. I haven't put much thought into it from the JSP perspective. From my
talk last night, you see my reasons why I don't like JSP. I really kinda do
not want to do anything to encourage anyone to use JSP. The way I see
it...if someone is open minded enough to use Turbine, then they should be
open minded enough to use a better solution like Webmacro or Freemarker or
Cocoon. So my focus of this design will be in this direction:
#2. What I would like to do from the webmacro/freemarker/cocoon perspective
is essentially replace the Servlet portions of those tools with a Screen
portion. That way, essentially all the Screen is doing is forwarding
requests onto the processing engines for the page parsing. If you think
about it, W/F/C are essentially servlets with a text parser on the back end.
If we can call that parser on the back end directly (by passing the servlet
portion) and pass it the information it needs, then that should be all we
need to do. Just replace the servlet portion of things. Now, where I expect
that we will run into problems is that I have doubts about WebMacro having
been designed to have this done. I believe that Cocoon and FreeMarker are
designed this way.
p.s. the talk went well in my opinion. about 90+ people showed up. Kevin was
even there (good to finally meet you!)...and asked me what I thought of
Cocoon...of course i have no idea about cocoon except for basic things...so
i wasn't able to really answer that well. other than that, not much to
report...i bored everyone with to much detail about Turbine and i think that
i opened a few people's minds up to contributing to open source instead of
working in a private sand box. very few people in the room actually
contributed to open source yet the majority of the room wrote servlets and
did web development. imagine how many different silly implementations of
ParameterParser there are out there! we need to work together guys...we are
just wasting way to much effort re-inventing the wheel each time.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
