Craig McClanahan wrote:
On 5/27/05, Werner Punz <[EMAIL PROTECTED]> 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
"dialog problem."
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.
* 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
also hate.
* 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
easier way.
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
tags).
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
bloated system.
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 )
