myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Kienenberger" <mkien...@gmail.com>
Subject Re: Programatically updating the model
Date Thu, 12 Apr 2007 14:08:18 GMT
Ah,  I didn't really think you were using client-side javascript.
Yes, if you're using javascript to move the stuff around, then it's a
different story.

Yes, overriding a renderer (or component if that works) would change
the behavior for the entire application.   What you'd probably want to
do is create a new tag for this use case.   In facelets, this is
trivial -- just add another tag-to-namespace-to-component-to-renderer
mapping.   I'm not sure how complicated it would be using jsp.   Maybe
you can simply add another tld entry.   Or you might have to create a
new JSP tag handler class as well (but you can simply subclass the
existing one, I'd think).

So the two choices I see that you'd have are to override the
validateValues method in the component or to pass both List A and List
B value sets to the component/renderer, and change the renderer not to
render one set of values which would allow the component to use both
sets for value validation.

Three if you count creating your own component from scratch -- not
sure if you'd gain enough by doing this.


On 4/11/07, monkeyden <monkeyden@gmail.com> wrote:
>
>
> Mike Kienenberger wrote:
> >
> > Are you physically moving with javascript the values 1,2,3 over to the
> > other html element form data?
> >
> I'm physically moving the values using JavaScript.
>
>
> Mike Kienenberger wrote:
> >
> > Or when you submit the form, are you submitting values 1,2,3 for List
> > A, submitting no values for List B, and executing a move action (or
> > action listener)?   This is what would normally happen if you had two
> > SelectMany components and a button on a page.
> >
> I assume you're referring to submission when the Add/Remove buttons are
> clicked.  For better or worse (most likely worse), everything is client side
> until the form is submitted.  The Direct-to-DOM feature of ICEFaces would be
> great for this if list A didnt potentially have 400+ items.  This absolutely
> kills performance.
>
>
> Mike Kienenberger wrote:
> >
> > The validation for List B should happen when List B still has no
> > elements.  Maybe validation is failing because you told it that List B
> > requires a value?
> >
> I have required="false" for the component.  In fact, here is the code:
>
> List A
> <ice:selectManyListbox id="availableLocations" required="false"
>     size="11" styleClass="inputText" style="width:200px"
> ondblclick="NEMAdd();return false;" immediate="true">
>     <f:selectItems value="#{advancedSearchAction.availableTowns}" />
> </ice:selectManyListbox>
>
> Add Button
> <ice:commandButton value="#{messages['propertysearch.button.add']}"
>
> onclick="addSelectedOptions('advancedPropertySearch:advPropTabSet:availableLocations',
> 'advancedPropertySearch:advPropTabSet:userLocations');return false;"
> />
> Remove Button
> <ice:commandButton value="#{messages['propertysearch.button.remove']}"
>
> onclick="removeSelectedOptions('advancedPropertySearch:advPropTabSet:userLocations',
> 'advancedPropertySearch:advPropTabSet:availableLocations');return false;"
> />
>
> List B
> <ice:selectManyListbox immediate="true" id="userLocations" size="11"
> styleClass="inputText" style="width:200px" required="false"
>     value="#{advancedSearchAction.submittedTowns}"
>
> ondblclick="removeSelectedOptions('advancedPropertySearch:advPropTabSet:userLocations',
> 'advancedPropertySearch:advPropTabSet:availableLocations');return false;">
>     <f:selectItems value="#{advancedSearchAction.selectedTowns}" />
> </ice:selectManyListbox>
>
> And, last but not least, the button which submits:
> <ice:commandButton id="searchNowA"
>
> onclick="processLocations();selectAll('advancedPropertySearch:advPropTabSet:userLocations',
> 0);selectAll('advancedPropertySearch:advPropTabSet:availableLocations', 0);"
>     value="#{messages['propertysearch.label.button.searchNow']}"
>     action="#{advancedSearchAction.search}"
> />
>
>
> Mike Kienenberger wrote:
> >
> > Are you sure that validation isn't failing for some other reason than
> > the one you think?  Put some messages tags on your page.
> >
> I'm positive.
>
>
> Mike Kienenberger wrote:
> >
> > As for subclassing, you can add things like this to your faces-config.xml
> > file.
> >
> >       <component>
> >
> > <component-type>com.xyz.jsf.component.PropertyComparator</component-type>
> >
> > <component-class>com.xyz.jsf.component.PropertyComparator</component-class>
> >       </component>
> >
> >       <render-kit>
> >         <render-kit-id>HTML_BASIC</render-kit-id>
> >
> >         <renderer>
> >             <component-family>org.apache.myfaces.Radio</component-family>
> >             <renderer-type>org.apache.myfaces.Radio</renderer-type>
> >
> > <renderer-class>com.xyz.jsf.component.ExtendedHtmlRadioRenderer</renderer-class>
> >         </renderer>
> >
> >     </render-kit>
> >
> > I know for sure that overriding a renderer works this easily.
> >
> Doesn't this setting extend this method for all occurances of
> "org.apache.myfaces.Radio" in your application?
>
>
> Mike Kienenberger wrote:
> >
> > I don't know for sure that overriding a component works in standard
> > JSF/JSP.   It'd be easy to test.
> >
> > I know that in Facelets, you can trivially redefine a new tag name
> > with a different component and renderer.
> >
> >     <tag>
> >         <tag-name>dataTable</tag-name>
> >         <component>
> >
> > <component-type>org.apache.myfaces.HtmlDataTable</component-type>
> >             <renderer-type>org.apache.myfaces.Table</renderer-type>
> >         </component>
> >     </tag>
> >
> > Worse case, you might need to also define a new tld/jsp TagHandler.
> >
> On 4/11/07, monkeyden <monkeyden@gmail.com> wrote:
> >
> > Here is why I believe I need to do this...correct me if Im wrong.
> >
> > I have two lists (A and B).  List A has values 1,2,3,4,5 .  List B has
> > nothing.  I move the values 1,2,3 over to list B and submit.  Because the
> > values 1,2,3 are not a subset of the original <f:selectItems> used to
> > populate list B, the submitted values are invalid.
> >
> > I can't get to the "update model phase" because the component has already
> > failed validation in the previous phase.  I would like to know about
> > extending UISelect, mainly how to tell JSF to use my subclass.  I've never
> > extended JSF in this manner.
> >
> > Thanks for the response.
> >
> >
> > Mike Kienenberger wrote:
> > >
> > > Would it be easier for you to override the following method in
> > > UISelect in your own component subclass?
> > >
> > > protected void validateValue(FacesContext context, Object
> > convertedValue)
> > >
> > > I'm actually kind of confused why you'd even need to do this.
> > >
> > > Your source select many component has a list of items, and any items
> > > you select in it should be valid.   The same should be true for your
> > > destination component.
> > >
> > > You would update the lists after the update model phase (invoke
> > > action) and before rendering a new response, so there shouldn't be any
> > > trickery necessary.
> > >
> > > I do something similar with two UIData components and two lists.   My
> > > "picker" only works for one item at a time, but should be pretty much
> > > the same other than that.
> > >
> > >
> > > On 4/11/07, monkeyden <monkeyden@gmail.com> wrote:
> > >>
> > >> I'm implementing a "mover box control", which consists of two select
> > >> boxes
> > >> and two mover buttons (Add/Remove).
> > >> In the valueChangeListener method,  I need to programmatically take the
> > >> submitted values and create SelectItems out of them.  In order to trick
> > >> JSF
> > >> into thinking that they are valid, I'd like to update the model.  This
> > is
> > >> done to get around the problem of submitted values not being valid when
> > >> they
> > >> are not a subset of the original list.  I've tried several of the
> > methods
> > >> on
> > >> UIInput and UIViewRoot but none seem to be working correctly.  I know
> > >> Tomahawk has something like this in the sandbox.  We're using ICEFaces
> > >> but I
> > >> think this is a standard JSF question.
> > >>
> > >> Thanks for the guidance
> > >> --
> > >> View this message in context:
> > >>
> > http://www.nabble.com/Programatically-updating-the-model-tf3562422.html#a9949895
> > >> Sent from the MyFaces - Users mailing list archive at Nabble.com.
> > >>
> > >>
> > >
> > >
> >
> > --
> > View this message in context:
> > http://www.nabble.com/Programatically-updating-the-model-tf3562422.html#a9951617
> > Sent from the MyFaces - Users mailing list archive at Nabble.com.
> >
> >
>
>
>
> --
> View this message in context: http://www.nabble.com/Programatically-updating-the-model-tf3562422.html#a9952049
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>
>

Mime
View raw message