Sean Schofield wrote:
Btw. Sean, is there a place with a good introduction
about Shale, mainly the components and what is being worked on?
I checked the shale site a while ago and could not find anything
except a few comments and a rather vague description.
Just the wiki
http://wiki.apache.org/struts/StrutsShale
The javadoc actually contains quite a bit of explanation. The
usescases are also built nightly and they are an excellent example of
how the new dialog stuff works.
Thanks... I just checked it, I know it is getting totally off topic, but
for the Dialog stuff, I did not like what I saw, again the approach is
to complicated.
The main problem was, that it introduced yet another xml dialect on top
of jsf.
I think there are better ways. The main focus point of this stuff is,
that it introduces a scope which is shorter than session and longer than
request (which was heavily needed since day one of the JSF specification).
The jsfified way to do that would be to add some kind of
<x:dialog scopeName="theScope"/> tag, which marks a dialog and as soon
as you hit
a page without the <x:dialog scopeName="theScope"/> you run into the end
point of the scope.
This can be achieved the easiest way, by some scope managing filter.
and a tag which basically checks if the current backend bean already is
on the stack and if not, would dump it there .
in between the data is stored in a dialog stack and then moved in the
context to a last dialog variable, where it can be requested, the usage
of a stack is mandatory so that you can put dialogs on top of dialogs,
Callahan is perfectly right there.
The result is sort of what shale does, but the main difference is, that
you entirely can rely on the JSF page flow xml syntax and the graphical
tools which already give you a very good page flow editing facilty,
while still being able to scope the data. The result is also easier to
understand for the user, because they dont have to fight yet with
another framework which they have to derive their classes from, yet
another xml syntax to describe their page flow. It would be all just
tags and thats it.
The Shale approach altough from a coding perspective elegant, is just
too messy and to Byzantine by adding another xml dialect on the heap of
another 5000 xml dialects we now already have to use (soon to be
replaced by 5000 annotations which will make the code more unreadable)
And add to that another bunch of classes which you seem to have to
interweave into your code.
Cheers
Werner
