On 5/27/05, Werner Punz wrote:
Craig McClanahan wrote:
On 5/27/05, Werner Punz wrote:
Sean Schofield wrote:
FYI there is some really cool stuff going on with dialogs in Struts
Shale right now. Its all built on top of JSF and there are some
"nightly" examples you can download from Craig's website.
Of course you can accomplish this without Shale (see Martin's
suggestions) but Shale provides a nice "standard" way of solving the
Well I checked shale yesterday, it looks really nice, but I have one
gripe with it, Callahan introduces yet another xml syntax for the page
flow, which really is totally redundant because the pageflow already is
covered in the faces-config description.
The better approach would be to use some kind of dialog marker tag,
which marks the dialog boundaries, and let JSF keep the page flow.
JSF has way too many artefacts scattered around the filesystem already
(a huge design mistake, it inherited from Struts), we dont neet yet
another artefact, and even one, which ist totally redundant.
Not really redundant, in at least a couple of areas:
* JSF 1.x doesn't have any notion of mapping to an action state;
it only knows about view states.
Correct me if I am wrong, but is an action state not just another
redirect in a page centric view... so I do not see any point except
mapping things to the UML paradigm.
No, as currently implemented an action state is a method call
(configured using a method binding expression) to some public method
on a bean -- typically a managed bean so you get the create-on-demand
and dependency injection features -- that returns a String outcome.
That outcome can then be used to select a transition to some other
state. Note that you can chain action states together if you want, as
well, to support fine grained reusable behaviors.
The container has no notion that any of this is going on -- it's not
implemented with RequestDispatcher.forward() or with redirects. JSF
only knows how to navigate to views.
A Shale ViewController provides the equivalent of a setup action for
you (prerender), but that *requires* you to put the corresponding
logic in the same bean as the processing logic. Some folks prefer a
design pattern that allows you to reuse setup actions across different
views (i.e. call the same action method for the several places where
you need to look up all the orders for a particular customer). Dialog
lets you do that.
* JSF 1.x maps outcomes to new (view) states globally per application,
which means you cannot reuse the same view in more than one dialog.
point taken in this regard... this is a huge hole in the specs, which I
Remember that it was a 1.0 spec, whose primary goal was getting the
component APIs right. This is the sort of functionality that can be
added later, so consider dialogs some real life research into what
kinds of facilities like this should later be standardized.
* Besides the "global" restriction, JSF 1.x doesn't have any support for
a "dialog scope" (longer than a request, shorter than a session) -- you
have to do all that kind of state management by yourself.
that is resolvable with less artefacts by the introduction
of a scope or dialog tag, which does the handling in a for the end user
What kind of tag? I guess you're talking about a JSP custom tag of some sort?
In the long run, I think support for something like dialog scope
really belongs at the servlet API level so that all the web tier
technologies could benefit from it -- but that's for the future, and
this is now.
None of these "limitations" of JSF 1.x should really be that
surprising; the focus was on creating a view tier component API.
Shale, on the other hand, is about creating a controller tier API that
is synergistic with JSF's basic controller capabilities, rather than
treating it as simply a custom tag library (like the Struts HTML
If the ideas in Shale's dialog management end up in JSF 2.0 (which
doesn't seem unlikely to *me*, but that will be up to the JSF 2.0
expert group), then great. In the mean time, the ability to script a
dialog, with both action and view states, and to build a tool to
assist a user in graphically assembling such a dialog, then reusing it
as a black box, is pretty helpful.
Yes... but the main problem is, that it again is way to complicated
to use by introducing another set of artefacts in an already artefact
Sorry ... I still don't understand how your contention that the
standard JSF configuration mechanism provides "everything you need"
for dialog management is supported.
And, by the way, those artifacts are part of what makes building tools
to support developers much easier. Go grab a copy of Creator and play
with the page navigation support (adding a navigation rule is done by
dragging a mouse from one page to another) -- you can edit the XML if
you really want to, but it's much nicer not to have to. The
configuration of dialogs is very much amenable to the same kind of
Shale started as a project which should make things easier for the user
(the main problem to my knowlege most people had with both Struts and
JSF was the artefact management, which JSF is better than struts but
still far from being easy to handle)
To keep the number of artefacts low, I think the correct approach would
be to try not to introduce yet another xml type and to try to cover as
much as possible with tags and not with another layer of frameworks,
which you force upon the user to use. (there are way to many framework
hooks in JSF already, which sometimes are hard to grasp. The main two
examples which come to my mind are the component model framework and the
Datamodel, which both could have been way easier )
Minimizing configuration artifacts is not the primary measure of ease
of use for developers. Indeed, the fact that Struts *required* a
config file (over and above web.xml) was one of the most important
factors in its success.