Return-Path: Delivered-To: apmail-struts-dev-archive@www.apache.org Received: (qmail 33764 invoked from network); 21 Jan 2005 14:05:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 21 Jan 2005 14:05:43 -0000 Received: (qmail 76386 invoked by uid 500); 21 Jan 2005 14:05:39 -0000 Delivered-To: apmail-struts-dev-archive@struts.apache.org Received: (qmail 76333 invoked by uid 500); 21 Jan 2005 14:05:39 -0000 Mailing-List: contact dev-help@struts.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list dev@struts.apache.org Received: (qmail 76320 invoked by uid 99); 21 Jan 2005 14:05:39 -0000 X-ASF-Spam-Status: No, hits=0.6 required=10.0 tests=HOT_NASTY X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from mailm.jobcorps.org (HELO mailm.jobcorps.org) (65.246.232.104) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 21 Jan 2005 06:05:38 -0800 X-SEF-4F11541D-50CC-429F-93CD-B4D97F5D8055: 1 Received: from Unknown [10.1.200.31] by mailm.jobcorps.org - SurfControl E-mail Filter (5.0); Fri, 21 Jan 2005 09:05:36 -0500 Content-class: urn:content-classes:message Subject: RE: [shale] Re: Struts Shale MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Jan 2005 08:05:31 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <9616BFC95C867443854DA22AA36F746BD11256@JCDC-S-EXV-001.ad.jcnet.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [shale] Re: Struts Shale Thread-Index: AcT/wkSzHeynDDP7RAe+zjS1MkTaWg== From: "David Suarez" To: "Struts Developers List" X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N I've been watching this conversation from the sidelines. I see in the emai= l description below the purpose of the new "Dialog" object:=0D=0A=0D=0A1.=0D= =0A>>=A0To me, the lifetime of the state information is the key=0D=0A>>=A0d= istinguishing feature to this gadget -- so if we don't like=0D=0A>>=A0"dial= og" then maybe some name around that idea would be more=0D=0A>>=A0appropria= te.=0D=0A=0D=0AAre there any other things that make this object unique=3F = Are there current examples of how it would be set up or used=3F I was thin= king about how this idea would be implemented if #1 was the only requiremen= t and came up with the following. I hope it adds value to the discussion. = =20=0D=0A=0D=0AI took a look at the DialogController Shale source and it se= ems that the methods are defined via "code" but the goal is essentially to = replicate session at a smaller level. If this is the only case (and I may = be way off base here) why not introduce a mock "session" object so that the= actions/etc are none the wiser. The end of a dialog would be defined by s= ome "final" action that would clean up the session so the Cancel/Complete w= ouldn't matter. Here's some pseudo-code to show what I was thinking:=0D=0A=0D= =0A=09// I have no clue on Shale config so this is basically a struts examp= le that would need to be modified for the equivalents in Shale=0D=0A=09=0D=0A=09 =0D=0A=09=0D=0A=0D= =0AAt the server you check if a dialogName exists, if so then it's a dialog= =2E If that dialog is not currently in existence, then create a session sp= ace for it:=0D=0A=0D=0A =09if(session.getActiveDialogs().get(dialogName)=3D= =3Dnull){ //no session with that name exists=0D=0A =09=09webSession =3D s= ession; // Just to illustrate that this is the "REAL" session=0D=0A =09=09= dialogSession =3D new dialogSession(session); // session is passed so the u= ser can use the same session life-cycle methods on a mini scale and it has = a reference to the "real" session object as needed to look up objects. If = it is not found in dialog session it can then check "real" session=0D=0A = =09=09webSession.set(DIALOGSESSION+"_"+dialogName, dialogSession); //Give= the dialog session a spot in the real session=09=09=0D=0A=09}=0D=0A=09//Th= e call to the action/dialog in this case would pass the dialogSession inste= ad of the real session in this case. So a call to session.invalidate() wou= ld just remove the dialog from the real session. =20=0D=0A=0D=0AMaybe there= are other goals for dialog that I am not aware of that this would not work= for. I think the above would essentially make a struts app a series of di= alogs for the most part except probably the login/logout and other universa= l functions. Of course the naming above would be confusing as hell so you'= d probably want to use better names in the "execute" type method so the use= r doesn't think they're working with a session. Maybe a name like "Scope",= so you're passed a scope as part of the execute method to make it clear th= at any of the work you do is limited to whatever the configuration scope is= (handled as part of config).=0D=0A=0D=0APlease advise how this may or may = not suit your needs. I hope I'm not 100% off-base here.=0D=0A=0D=0ARegards= =2E..djsuarez=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Ted Husted [= mailto:husted@apache.org]=20=0D=0ASent: Thursday, January 20, 2005 5:04 AM=0D= =0ATo: Struts Developers List=0D=0ASubject: Re: [shale] Re: Struts Shale=0D= =0A=0D=0AIt would be a good idea to name both the set and the member at the= same time.=20=0D=0A=0D=0ASome suggestions=0D=0A=0D=0A* Activity and Task=0D= =0A* Circuit and Gate=0D=0A* Track and Step=20=0D=0A* Process and Node=0D=0A=0D= =0Awhich leads to conjugations like=20=0D=0A=0D=0A* ActivityState=0D=0A* Ci= rcuitState=0D=0A* TrackState=0D=0A* ProcessState=0D=0A=0D=0AIf this were Fr= iday, I might add=20=0D=0A=0D=0A* Ripple and Domino :)=0D=0A=0D=0A-Ted.=0D=0A=0D= =0AOn Thu, 20 Jan 2005 05:07:03 +0000, Duncan Mills wrote:=0D=0A>=A0In the = past I've been around this merry-go-round on another=0D=0A>=A0Controller im= plementation, the end result of that painful exercise=0D=0A>=A0in semantics= was the following:=0D=0A>=A01) An activity - a single node on the flow - d= isplay a page, send=0D=0A>=A0an email, execute this code etc.=0D=0A>=A02) A= Process - a group of activities, =A0logically of course this=0D=0A>=A0proc= ess itself can be nested as an activity in a flow.=0D=0A>=0D=0A>=A0So this = is why I tend to use process, it's also neutral enough to=0D=0A>=A0(I think= ) co-exist with the scope's we're used to. =A0Another factor=0D=0A>=A0here = is that using an overloaded term (like dialog) is acceptable=0D=0A>=A0to a = native English speaker but can be confusing if English is not=0D=0A>=A0your= primary language, this would also rule out a term like Wizard.=0D=0A>=0D=0A= >=A0Duncan=0D=0A>=0D=0A>=0D=0A>=A0Craig McClanahan wrote:=0D=0A>=0D=0A>>=A0= The only problem I have with "wizard" is that it implies a serial=0D=0A>>=A0= forwards-backwards flow. =A0I can see cases for dialogs :-) with=0D=0A>>=A0= branches in them. =A0(It's the same reason I took standard "next"=0D=0A>>=A0= and "previous" methods back out of the API ... the concept=0D=0A>>=A0doesn'= t always apply.=0D=0A>>=0D=0A>>=A0To me, the lifetime of the state informat= ion is the key=0D=0A>>=A0distinguishing feature to this gadget -- so if we = don't like=0D=0A>>=A0"dialog" then maybe some name around that idea would b= e more=0D=0A>>=A0appropriate.=0D=0A>>=0D=0A>>=A0Craig=0D=0A>>=0D=0A>>=0D=0A= >>=A0On Tue, 18 Jan 2005 15:16:16 -0500, Sean Schofield=0D=0A>>=A0=A0wrote:=0D=0A>>=0D=0A>>=0D=0A>>>>=A0I almost suggested t= he same thing: "conversation". =A0Its=0D=0A>>>>=A0length, though, could be = unfriendly. =A0ConversationController.=0D=0A>>>>=A0What about "dialogue" wi= th the "ue" at the end=3F=0D=0A>>>>=0D=0A>>>>=0D=0A>>>=A0What about "wizard= =3F" =A0This is what we call our own custom=0D=0A>>>=A0solution that we're = using now. =A0Wizard generally implies a=0D=0A>>>=A0guided series of steps = where you can go forwards and backwards=0D=0A>>>=A0(at least to me it does.= )=0D=0A>>>=0D=0A>>>=A0sean=0D=0A>>>=0D=0A>>>=A0----------------------------= ------------------------------------=0D=0A>>>=A0----- To unsubscribe, e-mai= l: dev-unsubscribe@struts.apache.org=0D=0A>>>=A0For additional commands, e-= mail: dev-help@struts.apache.org=0D=0A>>>=0D=0A>>=0D=0A>>=A0---------------= ---------------------------------------------------=0D=0A>>=A0--- To unsubs= cribe, e-mail: dev-unsubscribe@struts.apache.org For=0D=0A>>=A0additional c= ommands, e-mail: dev-help@struts.apache.org=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org