On 11/3/06, Thomas Walland <[EMAIL PROTECTED]> wrote:
Hi,
As I already wrote, I am a newby to apache shale. So I have a few
general questions.
I have great experience with apache struts, but never made some work
with JSF or other technologies which are used in shale.
So I need something like a short introduction in the style of "shale
für struts users".
That's a good idea. In fact, I gave a presentation at a Java event in
London this last spring, and one of my talks was introducing JSF (and Shale)
from the perspective of a developer familiar with Struts. You can find the
slides on my home page at Apache (http://people.apache.org/~craigmcc/) ...
look for the paper entitled "Struts and JavaServer Faces".
I heard a lot about the prerenderer. Is this something like the
controller-classes in struts-tiles? A class or action which is called
just before the associated jsp or html file is rendered?
Yes, that's exactly what it is for. Interestingly, Struts 2 has the same
concept with the Preparable interface -- which says to me that the idea is
useful, even though you could accomplish the same thing with a customized
request processor (Struts 1.1/1.2) or customizing the request processing
chain (1.3) or interceptors (2.0). The prerender method is called on a GET
request as well as a POST, making it fairly easy to create bookmarkable URLs
too.
In addition to prerender, the view controller functionality of Shale (
http://shale.apache.org/shale-view/) has three other lifecycle methods that
are interesting:
* init() -- called when the backing bean is first created and added to
request scope.
This is useful to gather resources that you will need, whether this is a
GET or a POST.
* preprocess() -- called *only* if this request is a POST of the form
submitted by
this view. Use it to do things like acquiring database locks, or
re-selecting data
objects that will be modified by this form (if you didn't save them in
session scope).
* prerender() -- as discussed above. I like to think of it as an
opportunity to "pull"
data needed by this view out of the model, versus a typical pattern in
Struts of
"pushing" data from one action to the next.
* destroy() -- called *after* rendering is completed, for which there is no
analogous
method in Struts 1, and IIUC not in Struts 2 either.
Until now I had only a look to the clay-usecases example which is
distributed on the shale-webpage. In this example, there is a
managed-bean defined (QueryParam) which puts some Request-Parameters
into the defined class.
Can we say in general, that this is a rebuild of the functionality of
the Struts-Action's?
Sort of, but its really driven by the differences between the JSF request
processing lifecycle and the Struts processing lifecycle. In particular,
you don't need anything analogous to "form beans" in JSF, because the
components take care of those responsibilities already. And, JSF lets you
bind individual submit buttons to different actions already, so you don't
need something like DispatchAction to handle this case.
Another question: Most question and mails on this list refer to jsp
functionality and problems with some jsp-errors. As I heard about
struts especially about clay, this was the most interesting point for
me. But it seems that not that much people are using clay at the
moment?
Are there some great disadvantages about this technology? I want to
realize a huge project with shale and also with clay. Is it a too
early stage to use clay? Is there some further developement work,
which should be done?
There is ongoing development work going on, but it seems to me that the
basic problems have been shaken out already, and that this is pretty solid.
A good way to find out for yourself, though, would be to do a small
prototype project first, which would help you get used to all of the things
that are different about JSF and Shale, before you do the architecture for
the large scale project.
I hope my questions are clearly written. I am not so an experienced
english-writer.
You are doing great!
Thanks :-)
Thomas
Craig
---
Thomas Walland
http://www.walland.net
[EMAIL PROTECTED]
