struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dakota Jack <dakota.j...@gmail.com>
Subject Re: [shale] Re: Struts Shale
Date Tue, 18 Jan 2005 14:48:37 GMT
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
<myfaces@bettsockentraeger.de> 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
> > <myfaces@bettsockentraeger.de> 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
> > dev-subscribe@struts.apache.org).  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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
> 


-- 
------------------------------

"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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message