You should send you comments to the struts-dev list (use [shale] in the subject heading.) That's really the most appropriate place to discuss the merits of Shale-related matters.
I know the Shale team reads this list but its better to have a back and forth and provide feedback on the appropriate list. Generally we only bring up Shale on this list when a user is requesting a solution that is available in Shale. Most people don't know about Shale so we point them in the right direction. sean On 5/26/05, Werner Punz <[EMAIL PROTECTED]> wrote: > 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 > >
