> Implementing DialogController doesn't add much value yet, but it will > over time as Shale adds more behavior for you. For example, an > earlier thread today inspired the thinking of a solution to the > "having to know your own attribute key" problem: > > * Add the following to DialogController: > > public String getAttributeKey(); > public void setAttributeKey(String attributeKey); > > * Customize the JSF VariableResolver (the thing that does managed bean > creation) such that, if the bean just create was a DialogController, call > setAttributeKey() to tell the instance what it's name is. > > This will become less important if we can identify a way for the > framework to do the delete instead of having the instance do it, but > that will still require implementing the interface (so the framework > can do instanceof checks). > > Craig > >
The term dialog or “dialog duration” reminds me of a product once called Forte. It’s now called UDS and dying a slow death. Tool, the forte language would allow you to rollback the state of non distributed objects within a transaction. This was a pretty need concept. I wonder if you could use the token for double posts as a delimiter in the managed beans logical name? Then on the back/previous action, you could rollback the state of the bean prior to the step. Gary > On Fri, 21 Jan 2005 13:50:30 -0500, Sean Schofield > <[EMAIL PROTECTED]> wrote: > > Craig, > > > > I've been rereading your Shale proposal and studying the use cases. > > To me the usecases example shows an interesting way of dealing with > > some of the challenges of a "dialog" situation. Your general approach > > makes sense. > > > > What I don't understand is the benefit of the DialogController > > interface in particular. What real benefits do I obtain from > > extending this interface? The benefits of the ViewController > > interface are more obvious. The framework will call the various > > methods at the appropriate point in the Shale lifecycle. (I'm > > interested in learning more about how you might use those methods but > > for that I will take a look at mailreader.) > > > > I don't really see that the methods on the DialogController interface > > are guaranteed to be called at any point. You are of course calling > > them from the appropriate ViewController beans, but that's not a > > guarantee. > > > > Perhaps this is an area where you had some long term plans in mind? > > Again, I'm not criticizing the approach you are taking in the usecaess > > example, but for now it just strikes me as an example of how you might > > choose to go about it. > > > > I'm probably missing something so any light you can shed on this would > > be helpful. > > > > Implementing DialogController doesn't add much value yet, but it will > over time as Shale adds more behavior for you. For example, an > earlier thread today inspired the thinking of a solution to the > "having to know your own attribute key" problem: > > * Add the following to DialogController: > > public String getAttributeKey(); > public void setAttributeKey(String attributeKey); > > * Customize the JSF VariableResolver (the thing that does managed bean > creation) such that, if the bean just create was a DialogController, call > setAttributeKey() to tell the instance what it's name is. > > This will become less important if we can identify a way for the > framework to do the delete instead of having the instance do it, but > that will still require implementing the interface (so the framework > can do instanceof checks). > > Think of the current interface as a placeholder for functionality as > we figure out what functionality a dialog (or whatever the ending name > is) is supposed to provide. If that functionality ends up being > nothing, it can of course go away ... but I'm betting there will be > quite a few interesting things we can do with one of these, once we > have one. > > > Thanks, > > > > sean > > Craig > > > > > > --------------------------------------------------------------------- > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
