jon * wrote:
>
> 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.
Yeah. This is the only *decent* way around it. Still not clean IMO.
However it will work. The best way to do it would just be able to use
the facilities of Jakarta from *within* the servlet engine. Then you
can just get the output stream without doing anything stupid. We should
think about this for Turbine 1.1/Jakarta 1.1. Man. It really is going
to *rule* having the Servlet engine here! :)
> > 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.
Agreed. However for a lot of Servlet's you really don't need anything
that crazy. Most just have logic, read from a database, etc. Then spit
out html. But you are right. It would have to be a Jakarta Servlet :0
<snip>
> 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:
You and I are on the same page here. I hate JSP too. But some people
(read my co-workers) think it is perfect. However, it will fall off.
Turbine and Cocoon really are a good combo.
> #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.
Exactly. This is how I was planning integrating Cocoon into JetSpeed.
Not using it as a servlet but a service that I reuse. This is one of
the amazing things about OS is that in an open env you can do things
like this.
> 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.
I was amazed at how *conventional* the audience was. It still amazes me
how many people don't get this yet. Hopefully once they actually feel
the power that this type of development brings, they will never go back.
I think the real problem is that things like SourceExchange haven't
caught on yet. I am basically "Open Source Boy" at work right now
because I can deliver code at a much higher rate than anyone else.
Things like Apache/Turbine/Jakarta will hopefully wake everyone up.
--
Kevin A Burton
Senior Software Engineer
Kendara Inc
http://www.kendara.com
Mobile: 408-910-6145
Linux - You *will* be assimilated.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
