[EMAIL PROTECTED] wrote:
>
> Hello,
>
> I've noticed JSP isn't this list's favorite topic so I'll be brief:
You are right that it isn't the most popular templating system for
Turbine, but there is no reason you can't use it. There is a basic
interface, so that JSP can be used similarly to Velocity or WebMacro.
All it needs is someone who wants to use it and is willing to make it
better.
>
> I've successfully installed & configured Turbine under Resin 1.2, to
> the point where I can build and run custom actions and screens using
> ECS. I've browsed the javadoc and list archives, but I can't quite
> figure out the specific steps I need to take in order build a working
> application that works as follows:
>
> - A request comes in; Turbine handles authentication, session
> management and business logic.
The Turbine servlet (along with default modules) contains code to help
with the first; of course the business logic objects and
action/screen/... modules to assemble them for the templates or process
them are the main parts you need to build to put together an
application.
>
> - Turbine actions/screens put various pieces of data in objects that a
> JSP can access via <jsp:useBean> or however.
My limited understanding of JSP has led me to just dump everything in
the request for processing by the JSP. I do not think a page designer
should be concerned about the scope of an object. If an object is being
stored in the session and it is appropriate for a screen that will
generate the response, The Java Screen should add the object to the
request, so the JSP is not concerned about where all the objects are.
That's just my opinion though. One example is that the JSP service adds
the RunData object to the request, so it is always available to the JSP.
>
> - Turbine's navigation & layout features go largely unused.
But they can be used. I have added all the classes necessary to use
them. The one piece I have not checked in is the tld (which could
easily be checked in, but is probably fairly useless without some
docs). But you can use JSP without them, correct.
>
> - The flow of control is passed to a JSP, which munges data from the
> action/screen together with HTML/XML. When a JSP needs to do things
> that access application data (e.g. build links), it directly
> accesses relevant Turbine singletons.
singletons?
>
> If somebody could provide a quick blow-by-blow on what I need to do
> (what properties to set, what the screens to subclass & what methods
> they should implement, how to specify and pass control to the jsp
> template, etc) I would be very indebted. Also, I'd be happy to write
> documentation once I better understand how the various parts of such a
> framework fit together.
>
> Unfortunately, Webmacro/Velocity isn't an option for this project, for
> purely bureaucratic reasons. Thanks in advance and my apologies for
> bringing up such an abominable topic ;-). I've been very impressed
> with Turbine thus far, and can't wait to get it integrated into our
> existing system.
The JSP service and associated modules follow very closely the model
given by all the rest of the template related services. Understand one
and you understand them all.
Good luck.
John McNally
(BTW, for anyone who is interested. I have been preparing for a move to
CollabNet, where I start tomorrow. No guarantees when that might
increase my contributions to Turbine, but just increasing my daily
exposure to Java related work over what I have had the last few months
ought to improve things considerably.)
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]