Thanks Martin,
So your feelings are that the API would be better served with being able
to explicitly pass a visitor or callback to a visitComponent?
-- Jacob
Martin Marinschek wrote:
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
--
Jacob Hookom - Minneapolis
----------------------------
JSF-EG, JSF-RI, EL, Facelets
