Well, I don't know if you remember the last part of the discussion
you, Adam, Manfred and me had on this topic.

If you remember I originally wanted to have something like a
visitComponent(). Now this is only possible with a spec-change - so I
took your original approach of creating a "ProcessingContext" and used
that on what I had in the current API.

Now that is the findComponent method -  which I took and rebuilt to
deliver a wrapper.

As long as we are in one and only one thread (which is true for JSF of
course), there shouldn't be a problem with your scenario, as on every
call of a method on this wrapper, I set and reset the rowIndex right
before and after the call.

I provide a visitComponent() method on this wrapper en plus - I still
think this is the good stuff, and I'd love to get rid of findComponent
and have a visitComponent instead ;).

And no, this won't work if we're not in a NamingContainer that is not
aware that it has to override findComponent.

regards,

Martin

On 2/12/06, Jacob Hookom <[EMAIL PROTECTED]> wrote:
> The reason why I ask is that we are trying to correct this for JSF 1.2,
> and I'd like to know if you've come up with an alternate, working solution.
>
> Example:
>
> UIComponent cA = root.findComponent("_id0:mytable:4:text");
> UIComponent cB = root.findComponent("_id0:mytable:9:text");
>
> cA.encodeAll(faces);
> cB.encodeAll(faces);
>
> What's the expected output?  Is the instance returned for cA stateful
> for the 4th iteration of 'mytable'?  If I do get the UIComponent and
> 'mytable' is left at row 4, what happens when I operate on cB, does it
> invalidate cA?
>
> Also, will this solution work for all NamingContainers, even if they
> don't extend UIData?
>
> Thanks!
>
> Jacob Hookom wrote:
>
> > But doesn't that break spec?
> >
> > Are you returning the UIComponent itself or some proxy instance?
> >
> > Martin Marinschek wrote:
> >
> >> Yes - but I extended the findComponent concept for data table to allow
> >> scoped id's with a row-identifier included, so this is now much the
> >> same as a client-id, except if the renderer does a conversion.
> >>
> >> So what Dave wants ought to work. In the latest nightly build and
> >> several before them.
> >>
> >> regards,
> >>
> >> Martin
> >>
> >> On 2/12/06, Jacob Hookom <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>> findComponent has nothing to do with client ids.  They work off of
> >>> different logic.
> >>>
> >>> Martin Marinschek (JIRA) wrote:
> >>>
> >>>
> >>>
> >>>>   [
> >>>> http://issues.apache.org/jira/browse/MYFACES-1110?page=comments#action_12366049
> >>>> ]
> >>>>
> >>>> Martin Marinschek commented on MYFACES-1110:
> >>>> --------------------------------------------
> >>>>
> >>>> Hmmm...
> >>>>
> >>>> yes, you should be able to search from the view-root no problem.
> >>>>
> >>>> Can you debug a little through find-component?
> >>>>
> >>>> I have a working test-case in tomahawks test source, plus we use
> >>>> the method successfully in the AJAX part.
> >>>>
> >>>> regards,
> >>>>
> >>>> Martin
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> findComponent return null for a valid clientId
> >>>>> ----------------------------------------------
> >>>>>
> >>>>>        Key: MYFACES-1110
> >>>>>        URL: http://issues.apache.org/jira/browse/MYFACES-1110
> >>>>>    Project: MyFaces
> >>>>>       Type: Bug
> >>>>> Components: Implementation
> >>>>>   Versions: Nightly
> >>>>> Environment: JBoss 4.0.3, XP
> >>>>>   Reporter: Dave
> >>>>>   Assignee: Martin Marinschek
> >>>>>   Priority: Critical
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> In a PhaseListener, first get all the clientId(s) with queued
> >>>>> messages, then try to find the components. But
> >>>>> ViewRoot.findComponent(clientId) return null.
> >>>>>
> >>>>> public void beforePhase(PhaseEvent event) {
> >>>>>   FacesContext context = event.getFacesContext();
> >>>>>   UIViewRoot root = context.getViewRoot();
> >>>>>   Iterator<String> itr = context.getClientIdsWithMessages();
> >>>>>   while (itr.hasNext()) {
> >>>>>     String clientId = itr.next();
> >>>>>     UIComponent component = root.findComponent(clientId);
> >>>>>     // ERROR: component is null
> >>>>>     ....
> >>>>>   }
> >>>>> }
> >>>>>
> >>>>> From debugger, clientId is
> >>>>
> >>>>
> >>>>
> >>>>> emp:empForm:empTable:1:salary:_idJsp144
> >>>>> The clientId is returned from context.getClientIdsWithMessages();
> >>>>> It must be valid, but root.findComponent() returns NULL.
> >>>>> JSF should have the following API
> >>>>> FacesContext.getComponentsWithMessages();
> >>>>> which is better than getClientIdsWithMessages();
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Jacob Hookom  -  Minneapolis
> >>> ----------------------------
> >>> JSF-EG, JSF-RI, EL, Facelets
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >>
> >> http://www.irian.at
> >>
> >> Your JSF powerhouse -
> >> JSF Consulting, Development and
> >> Courses in English and German
> >>
> >> Professional Support for Apache MyFaces
> >>
> >>
> >>
> >
> >
>
>
> --
> Jacob Hookom  -  Minneapolis
> ----------------------------
> JSF-EG, JSF-RI, EL, Facelets
>
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Reply via email to