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