D'oh. :) Quite true. Could we also eliminate the "MaxPath" model part, and just merge that into ProcessMenuModel?
W/regard to the previous/next: in theory, the train could run entirely off of those, by iterating both forward and backward. But that's not necessary. Anyway, I'd be OK (I think) with seeing those in the base model, since they are quite generically useful, but I haven't thought it through in detail or tried applying it to the existing component set. -- Adam On 8/13/07, Simon Lessard <[EMAIL PROTECTED]> wrote: > The real issue imho is more with the methods linked with previous/next step > management. I guess those could be easily placed in the subclass though as > the train itself won't use them. > > public abstract boolean isNextStepAvailable(); /* Could be optional or > maybe in a subclass, this would check if there's a step before the current > one */ > public abstract boolean isPreviousStepAvailable(); /* As above */ > public abstract Object getNextStep(); /* As above */ > public abstract Object getPreviousStep(); /* As above */ > Regards, > > ~ Simon > > > On 8/13/07, Simon Lessard <[EMAIL PROTECTED]> wrote: > > Hmmm, isn't that what I suggested? Current class is ProcessMenuModel, the > new one does not include the "Menu" part. > > > > > > > > On 8/13/07, Adam Winer <[EMAIL PROTECTED]> wrote: > > > So... what if we left the current class alone, in terms of its API and > > > name, and just exposed a new base class? > > > > > > -- Adam > > > > > > > > > On 8/13/07, Adam Winer <[EMAIL PROTECTED] > wrote: > > > > I've got some concern for backwards compatibility - this'll break > > > > some code on our end. I'm hoping Jeanne will have some comments > > > > too. > > > > > > > > -- Adam > > > > > > > > > > > > On 8/13/07, Martin Marinschek < [EMAIL PROTECTED] > wrote: > > > > > No voice means you can go ahead ;) > > > > > > > > > > regards, > > > > > > > > > > Martin > > > > > > > > > > On 8/13/07, Danny Robinson < [EMAIL PROTECTED]> wrote: > > > > > > Sorry Simon, I have little/no experience with this part of > Trinidad so can't > > > > > > comment. I trust your judgement, so you have my vote if you need > it ;-) > > > > > > > > > > > > > > > > > > On 8/13/07, Simon Lessard <[EMAIL PROTECTED] > wrote: > > > > > > > So I assume it would be +0 for everyone? > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/10/07, Simon Lessard < [EMAIL PROTECTED]> wrote: > > > > > > > > Hello everybody, > > > > > > > > > > > > > > > > Currently Trinidad includes a ProcessMenuModel class that > contains > > > > > > undesirable methods. The complete method list (not including > inherited ones) > > > > > > is: > > > > > > > > > > > > > > > > > > > > > > > > public boolean isImmediate() > > > > > > > > public boolean isReadOnly() > > > > > > > > public boolean isVisited() > > > > > > > > public void clearMaxPath() > > > > > > > > public void setMaxPathKey(Object maxPathKey) > > > > > > > > public Object getMaxPathKey()The methods involving maxPathKey > are the > > > > > > ones annoying me the most. However, as it's part of the public API > we have > > > > > > to keep backward compatibility as much as possible. Note also that > > > > > > isReadOnly should not named that way as readOnly support was > removed from > > > > > > process classes in favor of disabled since a readOnly link did not > make much > > > > > > sense. > > > > > > > > > > > > > > > > Anyway, I would rather have the following class structure and > method > > > > > > signatures: > > > > > > > > > > > > > > > > public abstract class ProcessModel > > > > > > > > > > > > > > > > > > > > > > > > public abstract boolean isDisabled(); > > > > > > > > public abstract boolean isImmediate(); > > > > > > > > public abstract boolean isVisited(); > > > > > > > > public abstract boolean isNextStepAvailable(); /* Could be > optional or > > > > > > maybe in a subclass, this would check if there's a step before the > current > > > > > > one */ > > > > > > > > public abstract boolean isPreviousStepAvailable(); /* As above > */ > > > > > > > > public abstract Object getNextStep(); /* As above */ > > > > > > > > public abstract Object getPreviousStep(); /* As above */public > class > > > > > > MaxPathKeyProcessModel extends ProcessModel /* Or a better name */ > > > > > > > > > > > > > > > > > > > > > > > > Implements all methods using the old ProcessMenuModel > [EMAIL PROTECTED] > > > > > > > > public class ProcessMenuModel extends MaxPathKeyProcessModel > > > > > > > > > > > > > > > > > > > > > > > > Empty class except for isReadOnly() that should return > > > > > > super.isDisabled() > > > > > > > > The structure above would clean up the Model class that really > shouldn't > > > > > > contain very implementation specific code like the max path key > algorithm > > > > > > and would allow us to add new ProcessModel classes with more > > > > > > functionalities. For example I had one using a mode for step > access right > > > > > > like: MAX_PLUS_NEXT, MAX, ANY, NEXT_ONLY, etc. > > > > > > > > > > > > > > > > The previous/next step methods could be useful for page > templates since > > > > > > it would be possible to include the train in the header as well as > a > > > > > > previous and next step buttons in the page footer in a generic way > using the > > > > > > very same process model. Note that we might have to also include > methods > > > > > > like isPreviousVisited(), isPreviousDisabled() and such to fully > support > > > > > > that. > > > > > > > > > > > > > > > > Opinions, suggestions? > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > ~ Simon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Chordiant Software Inc. > > > > > > www.chordiant.com > > > > > > > > > > > > > > > -- > > > > > > > > > > http://www.irian.at > > > > > > > > > > Your JSF powerhouse - > > > > > JSF Consulting, Development and > > > > > Courses in English and German > > > > > > > > > > Professional Support for Apache MyFaces > > > > > > > > > > > > > > > > > >
