No one is suggesting that Shale is off-topic. Using these types of remarks in a subject line is an established courtesy on higher-traffic lists.
The Shale codebase lives here, and Struts Dev is the preferred list for posts regarding Struts Shale. 'nuff said. -Ted. On Tue, 18 Jan 2005 06:48:37 -0800, Dakota Jack wrote: >�I have to smile at the suggestion that "[shale]" will be a >�substitute for "OT" so that Struts developers will not be burdened >�by these JSF discussions. �That is exactly the sentiment of Rod >�Johnson in "J2EE Development without EJB". �I also agree. �What >�could be more ironic than a proposed future of a project being >�clearly OT? �LOL �Talk about 1984! > >�Jack > > >�On Tue, 18 Jan 2005 09:25:16 +0100, Stefan Langer >�<[EMAIL PROTECTED]>�wrote: >>�Hello Craig, >> >>�I see your point and I think you are right but there is one >>�disadvantage leaving the coding of the prev and next button up to >>�the developer. Most of the times the developers do not clean up >>�the session when using a dialogflow or a pageflow. This leaves a >>�lot of garbage in the session bloating it up. So if the framwork >>�could provide a mechanism for making this easier I think the >>�whole application will benefit from it. This framework could be >>�seperate from the actual dialogcontroller so only those people >>�can use it that need it or want to benefit from it. My thinking >>�is this is infrastructure so it should be covered by the >>�framework and not on a per application level. >>�Another side effect of this could be the possibility to provide a >>�mean to navigate backwards using the standard browser back button. >> >>�Craig McClanahan wrote: >>>�On Fri, 14 Jan 2005 09:27:51 +0100, Stefan Langer >>>�<[EMAIL PROTECTED]>�wrote: >>> >>>>�Hello, >>>> >>>>�not sure if I'm addressing the right person, got your mail >>>>�off the myfaces mailing list. If addressing is wrong ignore >>>>�this mail. >>>> >>> >>>�I'm the right person. >>> >>> >>>>�To the point I read your proposal about struts shale and jsf >>>>�and find your implementation very interesting and am looking >>>>�forward to a hopefully soon release. >>>> >>>>�I have a few suggestions which and am wondering where I can >>>>�introduce them to shale. I don't want to edit the wiki >>>>�directly and I didn't find a comment section is there a >>>>�discussion list? >>> >>> >>>�Since Shale is part of the Struts project, the best discussion >>>�list is the Struts developer list (to subscribe, send an empty >>>�message to [EMAIL PROTECTED]). �Then, to help >>>�people sort conversations, it would be common to put "[shale]" >>>�in the message subject, so that people who are not interested >>>�could easily filter it out. >>> >>> >>>>�Anyhow here it goes: >>>> >>>>�I especially like the idea of a dialogscope. The thing which >>>>�I would find interesting is to define the flow of a dialog in >>>>�some config file (preferrably xml) and being able to provide >>>>�a back functionality in addition to the enter, exit and >>>>�cancel in the dialogcontroller. >>> >>> >>>�Interesting ... I had next() and previous() methods in my >>>�original design for this API. >>> >>> >>>>�This >>>>�would make creating wizard like dialogs very easy and provide >>>>�a way to navigate through the dialog in both directions. >>> >>> >>>�The reasons I don't have next() and previous() at the moment >>>�are as follows: >>> >>>�* Wizards tend to have a sequential flow (forwards and >>>�backwards) but that isn't the only kind of dialog that needs to >>>�be supported. The methods would go unused in some cases. >>> >>>�* Manually implementing next and previous functionality (as I >>>�did in the "use cases" example app) is so easy to do that it's >>>�hard to see much benefit from having the methods directly >>>�implemented. >>> >>>�* A generic "next" or "previous" method would have to be aware >>>�of all the possible logical outcomes, and this list would have >>>�to be updated every time a new step was added. �In the current >>>�approach an event handler only has to know the outcome ot get >>>�to the adjacent view, and isn't affected when new steps are >>>�added (unless it is adjacent). >>> >>>�Does that make sense? >>> >>> >>>>�Taking the >>>>�synchronization token pattern in account it might even be >>>>�possible to provide the same data when the user presses the >>>>�browser back button. >>> >>> >>>�I think this is going to require some assistance from the state >>>�saving machinery that JSF provides, but it would be >>>�interesting. �It might also be that the user still expects the >>>�state information to be the most current state, just like they >>>�would get from a regular "previous" button. >>> >>> >>>>�The advantage of a flow control is that the session can be >>>>�cleaned fairly easy when skipping from one dialog to the >>>>�other and information is not unnessecarly stored. >>> >>> >>>�My current thinking is that we want the ability to have more >>>�than one active dialog, so you can "push" from one dialog to >>>�another, then "pop" back out. �That's why I made it the >>>�dialog's responsibility to clean itself up. >>> >>>�I don't like the fact that the dialog has to know the attribute >>>�name it is stored under (in session scope), but haven't figured >>>�out a way around it yet. >>> >>> >>>>�Regards >>>> >>>>�Stefan Langer >>>> >>> >>>�Craig >>> >> >>�------------------------------------------------------------------ >>�--- To unsubscribe, e-mail: [EMAIL PROTECTED] >>�For additional commands, e-mail: [EMAIL PROTECTED] >> > >�-- >�------------------------------ > >�"You can lead a horse to water but you cannot make it float on its >�back." > >�~Dakota Jack~ > >�"You can't wake a person who is pretending to be asleep." > >�~Native Proverb~ > >�"Each man is good in His sight. It is not necessary for eagles to >�be crows." > >�~Hunkesni (Sitting Bull), Hunkpapa Sioux~ > >�----------------------------------------------- > >�"This message may contain confidential and/or privileged >�information. If you are not the addressee or authorized to receive >�this for the addressee, you must not use, copy, disclose, or take >�any action based on this message or any information herein. If you >�have received this message in error, please advise the sender >�immediately by reply e-mail and delete this message. Thank you for >�your cooperation." > >�-------------------------------------------------------------------- >�- To unsubscribe, e-mail: [EMAIL PROTECTED] For >�additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
