Comments below - Pavitra
> -----Original Message----- > From: Simon Lessard [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 27, 2006 3:12 PM > To: [email protected] > Subject: Re: [Proposal] ProcessModel changes > > It happen in the process train renderer. The > commandNavigationItem does not need to know who is rendering > him. The best example is really how to determine if a > station/step/stop was already visited or not. Since the model > does not provide such information, the renderer has to infer them. - Whatever we decide to do about the autobind or rowData interface is ok with me. - But I believe that the train component should not be bound to a MenuModel for various reasons. One a train is not a menu. Two, there are cases (internally @ Oracle) where people want to define train metadata using structures, other than MenuModel & that has information that can help determine, say, the visited state of a stop. So the rowData interface or the autoBindManager, could use this info available through the data model. > > On 9/27/06, Arjuna Wijeyekoon <[EMAIL PROTECTED]> wrote: > > > > > > > > > Adding a new model to your system will requires additional > > > > > configuration. > > > > > > > > > > > > IMO, small price to pay to avoid having to force all models to > > implement > > > > TrainStation (or some other API). > > > > > > > > > It was not forcing though. > > > > > > understood. it is not forcing if the page author is going > to bind each > > individual attribute by hand. > > But it is forcing if the page author wants to auto bind. > > > > > > > > > > > > 1. does not involve new tags. > > > > > > > > > > > > > > > Row data interfaces does that > > > > > > > > > > 2. can be retrofitted into existing tags without having to > > > > > change > > each > > > > and > > > > > > every tag implementation. > > > > > > > > > > > > > > > Idem > > > > > > > > > > > > > If I want to support outputText as well as > commandNavigationItem, > > don't > > > I > > > > need to modify both those components? > > > > > > > > > Your solution requires to add an autoBind attribute to all those > > > components. > > > > > > however, the change will happen up in UIXComponentBase so child > > component classes will be untouched. > > > > Interfaces on row data have nothing to do with the child > > > component being used for purpose of states (visited, > unvisited, etc. > > > in case of proces train). > > > > > > I don;t think I understand. Something needs to test and cast the > > rowdata to a TrainStation. > > where does that happen? Doesn't it happen inside the > > CommandNavigationItem or corresponding renderer? > > > > --arjuna > > > > However it would indeed requires some changes for > > > UIComponent attribute autobinding. > > > > > > > > > On 9/27/06, Simon Lessard <[EMAIL PROTECTED]> wrote: > > > > > > Hello Arjuna, > > > > > > > > > On 9/27/06, Arjuna Wijeyekoon <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi Simon, > > > > thanks for your reply. > > > > > > > > Could be splitted in more than one interface > > > > > > > > > > > > > Well then you could have an explosion of interfaces. My > point was > > > > not > > to > > > > have separate interfaces for each concept. > > > > I just wanted it to be flexible so that different people could > > > > provide > > > the > > > > implementations for the different concepts. > > > > So person A (non JSF guy) provides the native model. > > > > Person B (JSF guy) provides the AutoBindManager that > knows how to > > > > pull properties from the model for various components. > > > > > > > > > True > > > > > > > Adding a new model to your system will requires additional > > > > > configuration. > > > > > > > > > > > > IMO, small price to pay to avoid having to force all models to > > implement > > > > TrainStation (or some other API). > > > > > > > > > It was not forcing though. > > > > > > > 1. does not involve new tags. > > > > > > > > > > > > > > > Row data interfaces does that > > > > > > > > > > 2. can be retrofitted into existing tags without having to > > > > > change > > each > > > > and > > > > > > every tag implementation. > > > > > > > > > > > > > > > Idem > > > > > > > > > > > > > If I want to support outputText as well as > commandNavigationItem, > > don't > > > I > > > > need to modify both those components? > > > > > > > > > Your solution requires to add an autoBind attribute to all those > > > components. Interfaces on row data have nothing to do > with the child > > > component being used for purpose of states (visited, > unvisited, etc. > > > in case of proces train). However it would indeed requires some > > > changes for UIComponent attribute autobinding. > > > > > > Also, I don't know if the manager should be based on the > > > > > component. I think it would be better to link it with > the data > > > > > model class, else using the same component with two different > > > > > model could lead to > > a > > > > > ClassCastException and/or incoherent attribute > values. At worst, > > > > > an > > > AND > > > > > link > > > > > checking both the component and the data model could be used. > > > > > > > > > > > > That is what I meant. The manager would be referenced by both > > component > > > > class and data model class. > > > > public static AutoBindManager getManager(Class componentClass, > > > > Class > > > > dataModelClass) > > > > > > > > > It works, however, since some state attributes cannot be > found on > > > the chlid component there's still two choices. Either add all the > > > needed > > attributes > > > to > > > the component, or support both ideas. That is row data > interface for > > state > > > if you want to overload the default behavior and autobinding for > > component > > > attributes. The latter is getting quite complex though. > > > > > > > > > Regards, > > > > > > ~ Simon > > > > > > --arjuna > > > > > > > > > > > > On 9/27/06, Simon Lessard <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Added some comments inline > > > > > > > > > > On 9/27/06, Arjuna Wijeyekoon <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Hi, > > > > > > So I feel a little unhappy with putting things like > > "label/readOnly" > > > > > > (which > > > > > > are UI properties), > > > > > > "visited/selected/disabled/outcome" (which is all navigation > > > related), > > > > > > and "immediate" (related to validation) all on a > single interface. > > > > > > > > > > > > > > > Could be splitted in more than one interface > > > > > > > > > > I also feel like this solution solves a very specific > problem - > > > > > > the new <tr:trainStop> only helps with > commandNavigationItem). > > > Adding > > > > > new > > > > > > tags also bloats the number of tags in the framework. > > > > > > > > > > > > Also this forces MenuModel implementors to return > objects of a > > > > specific > > > > > > type > > > > > > - so if they have a more comfortable native model, they are > > > > > > forced to return adaptor objects. > > > > > > > > > > > > > > > The interface would be optional, if present it takes effect, > > > > > else > > the > > > > > default behavior is used. > > > > > > > > > > I'd like to propose a more general solution to the > problem of - > > > > > > > > > > > > > Some components (especially stamped components) > need a lot > > > > > > > of > > > > > > boiler-plate > > > > > > > code. > > > > > > > > > > > > > And I like to propose a solution that: > > > > > > 1. does not involve new tags. > > > > > > > > > > > > > > > Row data interfaces does that > > > > > > > > > > 2. can be retrofitted into existing tags without having to > > > > > change > > each > > > > and > > > > > > every tag implementation. > > > > > > > > > > > > > > > Idem > > > > > > > > > > 3. works with any model, so that the model author can > work with > > > > > any > > > > model > > > > > > he/she is most comfortable with. > > > > > > > > > > > > > > > Semi idem > > > > > > > > > > 4. Easy to maintain - if someone wants to change the model > > > > > later, > > > he/she > > > > > > should be able to make the change in one place and > not have to > > > > > > touch a lot of files. > > > > > > 5. can be used with all components, eg: > commandNavigationItem > > > > > > and > > > the > > > > > > menuModel. nodeStamps in tree/treeTable. > > > > > > 6. Does not force UI properties and validation > logic to all be > > > > > > on > > > the > > > > > same > > > > > > interface. > > > > > > > > > > > > > > > Using more than one interface solve that. > > > > > > > > > > So my thinking goes like this: > > > > > > > > > > > > Have an "autoBind" attribute on UIXComponentBase, so that a > > > > > > page > > > > author > > > > > > can > > > > > > write: > > > > > > <tr:train value="#{trainModel}" var="row"> > <tr:commandMenuItem > > > > > > autoBind="#{row}"/> </tr:train> > > > > > > > > > > > > > > > > > > Have an interface called AutoBindManager: > > > > > > public Object getProperty(FacesContext,UIComponent comp, > > > > > > String attributeName, Object model) > > > > > > > > > > > > AutoBindManagers are registered in trinidad-config, > and they > > > > > > are registered by two keys: > > > > > > the component class (eg: CoreCommandMenuItem, or > UIXCommand) > > > > > > and the model class (eg: Simon's Station.class) > > > > > > > > > > > > When asked for a property, UIXComponentBase (or > FacesBeanImpl) > > will > > > > > first > > > > > > look to see if there is a property (or > value-binding) set on > > > > > > the component directly. If not, it will see if there is an > > > > > > autoBinding > > > set > > > > > on > > > > > > the component. If so it will look up the list of > > > > > > AutoBindManager > > > > sbased > > > > > > on > > > > > > the component and type of the autoBind object, and ask each > > manager > > > > for > > > > > > the > > > > > > property value, and stop when the first non-null property > > > > > > value is > > > > > found. > > > > > > > > > > > > This way you can have (if you wish) different > AutoBindManagers > > > > > > for different concepts (like UI properties and validation > > > > > > logic). > > > > > > > > > > > > Does this make sense? > > > > > > What do you all think? > > > > > > > > > > > > > > > I like the idea. However, I don't know if it's a > better solution > > > > > on > > > the > > > > > usability side. Adding a new model to your system > will requires > > > > additional > > > > > configuration. Also, I don't know if the manager > should be based > > > > > on > > > the > > > > > component. I think it would be better to link it with > the data > > > > > model class, else using the same component with two different > > > > > model could lead to > > a > > > > > ClassCastException and/or incoherent attribute > values. At worst, > > > > > an > > > AND > > > > > link > > > > > checking both the component and the data model could be used. > > > > > > > > > > > > > > > Regards, > > > > > > > > > > ~ Simon > > > > > > > > > > > > > > > --arjuna > > > > > > > > > > > > On 9/27/06, Simon Lessard <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > I see it like that as well. Basically, during > rendering, the > > child > > > > > > > component > > > > > > > properies would be altered as follow: > > > > > > > > > > > > > > 1. Check if the property was set explicitely by the > > > > > > > component > > > (I'll > > > > > have > > > > > > > to > > > > > > > check if there's an easy way to do that... I thought about > > > checking > > > > > for > > > > > > a > > > > > > > value binding but that's not exactly right, maybe the > > FacesBean). > > > If > > > > > an > > > > > > > explicit property was set, use it. > > > > > > > > > > > > > > 2. Check the current row data at current row key. If it > > implements > > > > > > > interface > > > > > > > TrainStation (or any other name), save the > default attribute > > > values > > > > on > > > > > > the > > > > > > > stamp for the attribute the interface is > providing. Cast the > > > > > > > row > > > > data > > > > > > and > > > > > > > extract the new attribute values and states. > > > > > > > > > > > > > > 3. Nothing was mentionned by the user, so apply default > > > > > > > behavior > > > > > > (visited > > > > > > > before focus, and so on). > > > > > > > > > > > > > > > > > > > > > We could keep commandNavigationItem to implement that. > > > > > > > > > > > > > > ~ Simon > > > > > > > > > > > > > > On 9/27/06, Adam Winer <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > On 9/26/06, Pavitra Subramaniam < > > [EMAIL PROTECTED]> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > <tr:train value="#{trainModel}" var="row"> > > > > > > > > > <tr:stop text="#{row.label}" > > > > > > > > > action="#{row.outcome}" > > > > > > > > > immediate="#{row.immediate}" > > > > > > > > > readOnly="#{row.readOnly}" > > > > > > > > > visited="#{row.visited}" > > > > > > > > > selected="#{row.selected}" > > > > > > > > > disabled="#{row.disabled}"/> </tr:train> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So how is this better than the existing > > > > > > > > <af:commandMenuItem>? Seems like the same > amount of code. > > > > > > > > > > > > > > > > I was imagining an intermediate step, where > *if* the model > > > > > > > > points at instances of a specific model type, > and you use > > > > > > > > a simple template-ish tag, then you don't have > to set any > > > > > > > > EL, so just: > > > > > > > > > > > > > > > > <tr:train value="#{trainModel}" var="row"> > > > > > > > > <tr:trainStop/> > > > > > > > > </tr:train> > > > > > > > > > > > > > > > > -- Adam > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
