You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Martin Marinschek <ma...@gmail.com> on 2006/01/20 11:57:20 UTC
findComponent, dataTable, messages
Hi *,
I am having the following problem:
whenever I use dataTables
- and use messages alongside, or AJAX, or other stuff using findComponent -
I have the problem that I can't work with the components that are
children of the dataTables if I call a findComponent. Of course - I
won't find the correct component instance, due to the generated id and
the things the dataTable is doing to set the context of the current
row.
I've been thinking of a solution to this problem, and the only
solution that has come to my mind is to get rid of findComponent for
such things - and create an "executeOnComponent" method, which can be
implemented by all components doing special things with their
children.
I believe that components are too much of a black box for
findComponent ever to work at all - what's your impression?
Thoughts? feedback? Better ideas ;) ?
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: findComponent, dataTable, messages
Posted by Martin Marinschek <ma...@gmail.com>.
Simon,
you understood me exactly. I could never have expressed it this way in
English, though, thank you ;)
About the fragility: thing is that a component is a black box in JSF -
for every phase (decodes, updates, validations, etc...) but not for
this findComponent issue.
I believe it needs to be a black box for this as well - I don't want
to introduce fragility by treating the dataTable different, but fix
fragility by treating the component as the black box it is ;)
regards,
Martin
On 1/20/06, Simon Kitching <sk...@apache.org> wrote:
> Ok. I think I see....here's my understanding of the issue; please
> correct me if I've misinterpreted.
>
> The problem is when you've got an id of form "form:table:3:component",
> eg received via an ajax call.
>
> Just adding a colon to the front forms an absolute path that
> findComponent can use to locate that component by tracing from the
> UIViewRoot down, yes?
>
> However the "row" bit in the middle is a problem. The findComponent
> method will fail, looking for a component of id "3". Even if it does
> recognise that "table" is a UIData, steps into it, finds the child
> component, then returns it the problem remains that you've got a
> reference to a component but can't call it because its "state" does not
> reflect the row it's on. If findComponent were to call setRowIndex on
> the UIData component, that would work, but would potentially stuff up
> the UIData's current state for other purposes.
>
> An "executeOnComponent" that works like findComponent but takes a
> "callback" does sound useful here. It walks the component tree like
> findComponent, detecting UIData components, saving their current
> rowIndex and setting it to the provided index from the path. When the
> component is finally found, the callback is executed passing the
> component. On completion, the find process is then unwound, restoring
> any UIData components to their original rowIndex.
>
> It does sound a little fragile, though. It means treating UIData
> components specially which I don't like. Any use of "instanceof" in an
> OO program is a warning sign. Or can the UIData override findComponent
> on itself to manage that transparently? If so, that would be nice.
> Possibly non-portable though.
>
> Or did you mean something else??
>
> Cheers,
>
> Simon
>
> On Fri, 2006-01-20 at 12:24 +0100, Martin Marinschek wrote:
> > Example 1: try to use an input-field in your data-table, and look at
> > the output of the <h:messages> - the messages won't indicate the row
> > of the component in the dataTable - they can't, due to this problem.
> >
> > Example 2: try to use the new AJAX-form components (which rely on the
> > usage of find-component heavily) in a dataTable.
> >
> > regards,
> >
> > Martin
> >
> > On 1/20/06, Simon Kitching <sk...@apache.org> wrote:
> > > On Fri, 2006-01-20 at 11:57 +0100, Martin Marinschek wrote:
> > > > Hi *,
> > > >
> > > > I am having the following problem:
> > > >
> > > > whenever I use dataTables
> > > >
> > > > - and use messages alongside, or AJAX, or other stuff using findComponent -
> > > >
> > > > I have the problem that I can't work with the components that are
> > > > children of the dataTables if I call a findComponent. Of course - I
> > > > won't find the correct component instance, due to the generated id and
> > > > the things the dataTable is doing to set the context of the current
> > > > row.
> > > >
> > > > I've been thinking of a solution to this problem, and the only
> > > > solution that has come to my mind is to get rid of findComponent for
> > > > such things - and create an "executeOnComponent" method, which can be
> > > > implemented by all components doing special things with their
> > > > children.
> > > >
> > > > I believe that components are too much of a black box for
> > > > findComponent ever to work at all - what's your impression?
> > > >
> > > > Thoughts? feedback? Better ideas ;) ?
> > >
> > > I've found findComponent very useful (once I figured out what it does;
> > > the sun-provided documenation really sucked).
> > >
> > > Of course I've never had the need for a component to "find" another
> > > component that is nested inside a table.
> > >
> > > I don't understand your "executeOnComponent" suggestion. Could you give
> > > an example?
> > >
> > > Regards,
> > >
> > > Simon
> > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: findComponent, dataTable, messages
Posted by Martin Marinschek <ma...@gmail.com>.
To clarify: I'd say it's a little bit more complicated in its approach
- is it worth the added complexity?
regards,
Martin
On 1/21/06, Martin Marinschek <ma...@gmail.com> wrote:
> Hmmm....
>
> that could work.
>
> the question is if it is any better than letting the component extend
> from a marker interface and implement the functionality itself.
>
> Thoughts?
>
> regards,
>
> Martin
>
> On 1/20/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi
> > > ad 1) no - not even protected is allowed. The problem is that you
> > > don't want an application to rely on a certain implementation of the
> > > api - you change the api, and nothing works anymore ;)
> > >
> > Ok, thats bad.
> > > ad 2) yes, well, instanceof to UIData is bad. There I'm completely
> > > d'accord with Simon. But an instanceof to an interface defining some
> > > generic behaviour is pretty ok in my opinion. not marker interface
> > > instead of instanceof, but instanceof to marker interface instead of
> > > to UIData.
> > >
> > Ok, I understand.
> >
> > There is still one last idea, a little bit complicated, but this avoids
> > this marker interface too.
> > You could have a TraversePolicyProvider.
> >
> > Lets speak code:
> >
> > TraversePolicyFactroy.register(UIComponent.class, new
> > TraverseComponentChildren());
> > TraversePolicyFactroy.register(UIData.class, new TraverseDataChildren());
> >
> > Then on TraversePolicyFactroy:
> > TraversePolicy create(UIComponent component)
> > {
> > find a TraversePolicy for component.getClass() or one of its super
> > classes.
> > return it;
> > }
> >
> > Somewhat complicated, but hey it works. Is extensible and didnt need any
> > change on the api and no marker interface.
> >
> >
> > Ciao,
> > Mario
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: findComponent, dataTable, messages
Posted by Martin Marinschek <ma...@gmail.com>.
Ok, so do you have sample code available?
regards,
Martin
On 1/21/06, Jacob Hookom <ja...@hookom.net> wrote:
> Ed kind of did his own thing-- not sure what he wrote or where it's at.
>
> Martin Marinschek wrote:
>
> >I've looked into the glassfish web-cvs tree under jsf-extensions, and
> >not found the sources.
> >
> >Have they been moved?
> >
> >regards,
> >
> >Martin
> >
> >On 1/21/06, Jacob Hookom <ja...@hookom.net> wrote:
> >
> >
> >>Yeah, I've implemented this with an external Visitor instance--
> >>'hacking' the NamingContainer checks.
> >>
> >>The thing is to treat this behavior just like UIData's Event wrappers--
> >>something that is a facade over the targeted instance. To assert that
> >>you need to be able to have the actual component instance available
> >>within an iterative context is a far shot-- you are dealing with a
> >>transient instance-- so a limited facade (Perspective) allows some
> >>degree of logical protection within the 'API'.
> >>
> >>-- Jacob
> >>
> >>Martin Marinschek wrote:
> >>
> >>
> >>
> >>>That sounds interesting.
> >>>
> >>>so a Perspective is basically a wrapper for the properly initalized
> >>>and pre-configured component-instance then?
> >>>
> >>>Where's the source for Avatar? In the JSF-RI?
> >>>
> >>>I'll need to do that right now, though, and so probably without API changes ;)
> >>>
> >>>regards,
> >>>
> >>>Martin
> >>>
> >>>On 1/21/06, Jacob Hookom <ja...@hookom.net> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>This ties somewhat appropriately to the ideas behing ProcessingContexts
> >>>>(or Perspectives) with Avatar--
> >>>>
> >>>>It involved creating a read-only (like event) interface for UIComponent
> >>>>such that you can allow the UIComponent to tranverse itself, returning
> >>>>an (event-facade) for the given component, if found.
> >>>>
> >>>>http://weblogs.java.net/blog/jhook/archive/2005/09/jsf_avatar_vs_m_1.html
> >>>>
> >>>>Perspective p = uiData.findPerspective(faces, "_id0:foo:3:bar");
> >>>>p.encodeAll(faces);
> >>>>
> >>>>public Perspective findPerspective(FacesContext faces, String clientId) {
> >>>> String myId = this.getClientId(faces);
> >>>> if (clientId.equals(myId) {
> >>>> return new Perspective(this);
> >>>> } else if (clientId.startsWith(myId)) {
> >>>> int idx = //find idx from clientId
> >>>> int oidx = this.getRow();
> >>>>
> >>>> // modify my state
> >>>> this.setRow(idx);
> >>>>
> >>>> // find child now
> >>>> Perspective p;
> >>>> try {
> >>>> p = super.findPerspective(faces, clientId);
> >>>> } finally {
> >>>> this.setRow(oidx);
> >>>> }
> >>>> if (p != null) {
> >>>> return new IndexedPerspective(this, idx, p);
> >>>> }
> >>>> }
> >>>> return null;
> >>>>}
> >>>>
> >>>>-- Jacob
> >>>>
> >>>>Martin Marinschek wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Yeah,
> >>>>>
> >>>>>in fact I wanted to also hear feedback on the JSF-side of things. Like
> >>>>>- if there's anything like that already implemented in Tobago, ADF
> >>>>>Faces, planned for JSF 2.0.
> >>>>>
> >>>>>would be interesting to hear about that.
> >>>>>
> >>>>>regards,
> >>>>>
> >>>>>Martin
> >>>>>
> >>>>>On 1/21/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>Yes, only for extended components. Not for API stuff.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>Ok, so from now on its a matter of personal preferences.
> >>>>>>Personally I like to use factories/providers and so on ;-)
> >>>>>>In the current case it will make no difference between the various
> >>>>>>components just try to lookup and execute.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>- a third person might want to be able to change the behaviour (I
> >>>>>>>don't believe they can, though, cause most of the stuff is private in
> >>>>>>>the components)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>And this might be the strongest point why to use the marker interface,
> >>>>>>then the component is able to use its internal private states to do
> >>>>>>stuff more efficient, eventually.
> >>>>>>
> >>>>>>Said all that, I think its not that bad to use the marker stuff here.
> >>>>>>Only that it might lead to duplicate code if one requires the same
> >>>>>>traversing policy but didnt extend from the myfaces component.
> >>>>>>So maybe, where possible, you could create a new utility class which
> >>>>>>will do the hard work, in your component the implemented method is only
> >>>>>>a one-liner then.
> >>>>>>
> >>>>>>Whatever solution you decide to use, it wont save the world ;-)
> >>>>>>
> >>>>>>Ciao,
> >>>>>>Mario
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>--
> >>>>>
> >>>>>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
> >>
> >>
> >>
> >>
> >
> >
> >--
> >
> >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
Re: findComponent, dataTable, messages
Posted by Jacob Hookom <ja...@hookom.net>.
Ed kind of did his own thing-- not sure what he wrote or where it's at.
Martin Marinschek wrote:
>I've looked into the glassfish web-cvs tree under jsf-extensions, and
>not found the sources.
>
>Have they been moved?
>
>regards,
>
>Martin
>
>On 1/21/06, Jacob Hookom <ja...@hookom.net> wrote:
>
>
>>Yeah, I've implemented this with an external Visitor instance--
>>'hacking' the NamingContainer checks.
>>
>>The thing is to treat this behavior just like UIData's Event wrappers--
>>something that is a facade over the targeted instance. To assert that
>>you need to be able to have the actual component instance available
>>within an iterative context is a far shot-- you are dealing with a
>>transient instance-- so a limited facade (Perspective) allows some
>>degree of logical protection within the 'API'.
>>
>>-- Jacob
>>
>>Martin Marinschek wrote:
>>
>>
>>
>>>That sounds interesting.
>>>
>>>so a Perspective is basically a wrapper for the properly initalized
>>>and pre-configured component-instance then?
>>>
>>>Where's the source for Avatar? In the JSF-RI?
>>>
>>>I'll need to do that right now, though, and so probably without API changes ;)
>>>
>>>regards,
>>>
>>>Martin
>>>
>>>On 1/21/06, Jacob Hookom <ja...@hookom.net> wrote:
>>>
>>>
>>>
>>>
>>>>This ties somewhat appropriately to the ideas behing ProcessingContexts
>>>>(or Perspectives) with Avatar--
>>>>
>>>>It involved creating a read-only (like event) interface for UIComponent
>>>>such that you can allow the UIComponent to tranverse itself, returning
>>>>an (event-facade) for the given component, if found.
>>>>
>>>>http://weblogs.java.net/blog/jhook/archive/2005/09/jsf_avatar_vs_m_1.html
>>>>
>>>>Perspective p = uiData.findPerspective(faces, "_id0:foo:3:bar");
>>>>p.encodeAll(faces);
>>>>
>>>>public Perspective findPerspective(FacesContext faces, String clientId) {
>>>> String myId = this.getClientId(faces);
>>>> if (clientId.equals(myId) {
>>>> return new Perspective(this);
>>>> } else if (clientId.startsWith(myId)) {
>>>> int idx = //find idx from clientId
>>>> int oidx = this.getRow();
>>>>
>>>> // modify my state
>>>> this.setRow(idx);
>>>>
>>>> // find child now
>>>> Perspective p;
>>>> try {
>>>> p = super.findPerspective(faces, clientId);
>>>> } finally {
>>>> this.setRow(oidx);
>>>> }
>>>> if (p != null) {
>>>> return new IndexedPerspective(this, idx, p);
>>>> }
>>>> }
>>>> return null;
>>>>}
>>>>
>>>>-- Jacob
>>>>
>>>>Martin Marinschek wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Yeah,
>>>>>
>>>>>in fact I wanted to also hear feedback on the JSF-side of things. Like
>>>>>- if there's anything like that already implemented in Tobago, ADF
>>>>>Faces, planned for JSF 2.0.
>>>>>
>>>>>would be interesting to hear about that.
>>>>>
>>>>>regards,
>>>>>
>>>>>Martin
>>>>>
>>>>>On 1/21/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>Yes, only for extended components. Not for API stuff.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>Ok, so from now on its a matter of personal preferences.
>>>>>>Personally I like to use factories/providers and so on ;-)
>>>>>>In the current case it will make no difference between the various
>>>>>>components just try to lookup and execute.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>- a third person might want to be able to change the behaviour (I
>>>>>>>don't believe they can, though, cause most of the stuff is private in
>>>>>>>the components)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>And this might be the strongest point why to use the marker interface,
>>>>>>then the component is able to use its internal private states to do
>>>>>>stuff more efficient, eventually.
>>>>>>
>>>>>>Said all that, I think its not that bad to use the marker stuff here.
>>>>>>Only that it might lead to duplicate code if one requires the same
>>>>>>traversing policy but didnt extend from the myfaces component.
>>>>>>So maybe, where possible, you could create a new utility class which
>>>>>>will do the hard work, in your component the implemented method is only
>>>>>>a one-liner then.
>>>>>>
>>>>>>Whatever solution you decide to use, it wont save the world ;-)
>>>>>>
>>>>>>Ciao,
>>>>>>Mario
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>--
>>>>>
>>>>>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
>>
>>
>>
>>
>
>
>--
>
>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
Re: findComponent, dataTable, messages
Posted by Martin Marinschek <ma...@gmail.com>.
I've looked into the glassfish web-cvs tree under jsf-extensions, and
not found the sources.
Have they been moved?
regards,
Martin
On 1/21/06, Jacob Hookom <ja...@hookom.net> wrote:
> Yeah, I've implemented this with an external Visitor instance--
> 'hacking' the NamingContainer checks.
>
> The thing is to treat this behavior just like UIData's Event wrappers--
> something that is a facade over the targeted instance. To assert that
> you need to be able to have the actual component instance available
> within an iterative context is a far shot-- you are dealing with a
> transient instance-- so a limited facade (Perspective) allows some
> degree of logical protection within the 'API'.
>
> -- Jacob
>
> Martin Marinschek wrote:
>
> >That sounds interesting.
> >
> >so a Perspective is basically a wrapper for the properly initalized
> >and pre-configured component-instance then?
> >
> >Where's the source for Avatar? In the JSF-RI?
> >
> >I'll need to do that right now, though, and so probably without API changes ;)
> >
> >regards,
> >
> >Martin
> >
> >On 1/21/06, Jacob Hookom <ja...@hookom.net> wrote:
> >
> >
> >>This ties somewhat appropriately to the ideas behing ProcessingContexts
> >>(or Perspectives) with Avatar--
> >>
> >>It involved creating a read-only (like event) interface for UIComponent
> >>such that you can allow the UIComponent to tranverse itself, returning
> >>an (event-facade) for the given component, if found.
> >>
> >>http://weblogs.java.net/blog/jhook/archive/2005/09/jsf_avatar_vs_m_1.html
> >>
> >>Perspective p = uiData.findPerspective(faces, "_id0:foo:3:bar");
> >>p.encodeAll(faces);
> >>
> >>public Perspective findPerspective(FacesContext faces, String clientId) {
> >> String myId = this.getClientId(faces);
> >> if (clientId.equals(myId) {
> >> return new Perspective(this);
> >> } else if (clientId.startsWith(myId)) {
> >> int idx = //find idx from clientId
> >> int oidx = this.getRow();
> >>
> >> // modify my state
> >> this.setRow(idx);
> >>
> >> // find child now
> >> Perspective p;
> >> try {
> >> p = super.findPerspective(faces, clientId);
> >> } finally {
> >> this.setRow(oidx);
> >> }
> >> if (p != null) {
> >> return new IndexedPerspective(this, idx, p);
> >> }
> >> }
> >> return null;
> >>}
> >>
> >>-- Jacob
> >>
> >>Martin Marinschek wrote:
> >>
> >>
> >>
> >>>Yeah,
> >>>
> >>>in fact I wanted to also hear feedback on the JSF-side of things. Like
> >>>- if there's anything like that already implemented in Tobago, ADF
> >>>Faces, planned for JSF 2.0.
> >>>
> >>>would be interesting to hear about that.
> >>>
> >>>regards,
> >>>
> >>>Martin
> >>>
> >>>On 1/21/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>>Yes, only for extended components. Not for API stuff.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>Ok, so from now on its a matter of personal preferences.
> >>>>Personally I like to use factories/providers and so on ;-)
> >>>>In the current case it will make no difference between the various
> >>>>components just try to lookup and execute.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>- a third person might want to be able to change the behaviour (I
> >>>>>don't believe they can, though, cause most of the stuff is private in
> >>>>>the components)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>And this might be the strongest point why to use the marker interface,
> >>>>then the component is able to use its internal private states to do
> >>>>stuff more efficient, eventually.
> >>>>
> >>>>Said all that, I think its not that bad to use the marker stuff here.
> >>>>Only that it might lead to duplicate code if one requires the same
> >>>>traversing policy but didnt extend from the myfaces component.
> >>>>So maybe, where possible, you could create a new utility class which
> >>>>will do the hard work, in your component the implemented method is only
> >>>>a one-liner then.
> >>>>
> >>>>Whatever solution you decide to use, it wont save the world ;-)
> >>>>
> >>>>Ciao,
> >>>>Mario
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>--
> >>>
> >>>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
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: findComponent, dataTable, messages
Posted by Jacob Hookom <ja...@hookom.net>.
Yeah, I've implemented this with an external Visitor instance--
'hacking' the NamingContainer checks.
The thing is to treat this behavior just like UIData's Event wrappers--
something that is a facade over the targeted instance. To assert that
you need to be able to have the actual component instance available
within an iterative context is a far shot-- you are dealing with a
transient instance-- so a limited facade (Perspective) allows some
degree of logical protection within the 'API'.
-- Jacob
Martin Marinschek wrote:
>That sounds interesting.
>
>so a Perspective is basically a wrapper for the properly initalized
>and pre-configured component-instance then?
>
>Where's the source for Avatar? In the JSF-RI?
>
>I'll need to do that right now, though, and so probably without API changes ;)
>
>regards,
>
>Martin
>
>On 1/21/06, Jacob Hookom <ja...@hookom.net> wrote:
>
>
>>This ties somewhat appropriately to the ideas behing ProcessingContexts
>>(or Perspectives) with Avatar--
>>
>>It involved creating a read-only (like event) interface for UIComponent
>>such that you can allow the UIComponent to tranverse itself, returning
>>an (event-facade) for the given component, if found.
>>
>>http://weblogs.java.net/blog/jhook/archive/2005/09/jsf_avatar_vs_m_1.html
>>
>>Perspective p = uiData.findPerspective(faces, "_id0:foo:3:bar");
>>p.encodeAll(faces);
>>
>>public Perspective findPerspective(FacesContext faces, String clientId) {
>> String myId = this.getClientId(faces);
>> if (clientId.equals(myId) {
>> return new Perspective(this);
>> } else if (clientId.startsWith(myId)) {
>> int idx = //find idx from clientId
>> int oidx = this.getRow();
>>
>> // modify my state
>> this.setRow(idx);
>>
>> // find child now
>> Perspective p;
>> try {
>> p = super.findPerspective(faces, clientId);
>> } finally {
>> this.setRow(oidx);
>> }
>> if (p != null) {
>> return new IndexedPerspective(this, idx, p);
>> }
>> }
>> return null;
>>}
>>
>>-- Jacob
>>
>>Martin Marinschek wrote:
>>
>>
>>
>>>Yeah,
>>>
>>>in fact I wanted to also hear feedback on the JSF-side of things. Like
>>>- if there's anything like that already implemented in Tobago, ADF
>>>Faces, planned for JSF 2.0.
>>>
>>>would be interesting to hear about that.
>>>
>>>regards,
>>>
>>>Martin
>>>
>>>On 1/21/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>>>
>>>
>>>
>>>
>>>>>Yes, only for extended components. Not for API stuff.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Ok, so from now on its a matter of personal preferences.
>>>>Personally I like to use factories/providers and so on ;-)
>>>>In the current case it will make no difference between the various
>>>>components just try to lookup and execute.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>- a third person might want to be able to change the behaviour (I
>>>>>don't believe they can, though, cause most of the stuff is private in
>>>>>the components)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>And this might be the strongest point why to use the marker interface,
>>>>then the component is able to use its internal private states to do
>>>>stuff more efficient, eventually.
>>>>
>>>>Said all that, I think its not that bad to use the marker stuff here.
>>>>Only that it might lead to duplicate code if one requires the same
>>>>traversing policy but didnt extend from the myfaces component.
>>>>So maybe, where possible, you could create a new utility class which
>>>>will do the hard work, in your component the implemented method is only
>>>>a one-liner then.
>>>>
>>>>Whatever solution you decide to use, it wont save the world ;-)
>>>>
>>>>Ciao,
>>>>Mario
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>--
>>>
>>>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
Re: findComponent, dataTable, messages
Posted by Martin Marinschek <ma...@gmail.com>.
That sounds interesting.
so a Perspective is basically a wrapper for the properly initalized
and pre-configured component-instance then?
Where's the source for Avatar? In the JSF-RI?
I'll need to do that right now, though, and so probably without API changes ;)
regards,
Martin
On 1/21/06, Jacob Hookom <ja...@hookom.net> wrote:
> This ties somewhat appropriately to the ideas behing ProcessingContexts
> (or Perspectives) with Avatar--
>
> It involved creating a read-only (like event) interface for UIComponent
> such that you can allow the UIComponent to tranverse itself, returning
> an (event-facade) for the given component, if found.
>
> http://weblogs.java.net/blog/jhook/archive/2005/09/jsf_avatar_vs_m_1.html
>
> Perspective p = uiData.findPerspective(faces, "_id0:foo:3:bar");
> p.encodeAll(faces);
>
> public Perspective findPerspective(FacesContext faces, String clientId) {
> String myId = this.getClientId(faces);
> if (clientId.equals(myId) {
> return new Perspective(this);
> } else if (clientId.startsWith(myId)) {
> int idx = //find idx from clientId
> int oidx = this.getRow();
>
> // modify my state
> this.setRow(idx);
>
> // find child now
> Perspective p;
> try {
> p = super.findPerspective(faces, clientId);
> } finally {
> this.setRow(oidx);
> }
> if (p != null) {
> return new IndexedPerspective(this, idx, p);
> }
> }
> return null;
> }
>
> -- Jacob
>
> Martin Marinschek wrote:
>
> >Yeah,
> >
> >in fact I wanted to also hear feedback on the JSF-side of things. Like
> >- if there's anything like that already implemented in Tobago, ADF
> >Faces, planned for JSF 2.0.
> >
> >would be interesting to hear about that.
> >
> >regards,
> >
> >Martin
> >
> >On 1/21/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> >
> >
> >>>Yes, only for extended components. Not for API stuff.
> >>>
> >>>
> >>>
> >>Ok, so from now on its a matter of personal preferences.
> >>Personally I like to use factories/providers and so on ;-)
> >>In the current case it will make no difference between the various
> >>components just try to lookup and execute.
> >>
> >>
> >>
> >>>- a third person might want to be able to change the behaviour (I
> >>>don't believe they can, though, cause most of the stuff is private in
> >>>the components)
> >>>
> >>>
> >>>
> >>And this might be the strongest point why to use the marker interface,
> >>then the component is able to use its internal private states to do
> >>stuff more efficient, eventually.
> >>
> >>Said all that, I think its not that bad to use the marker stuff here.
> >>Only that it might lead to duplicate code if one requires the same
> >>traversing policy but didnt extend from the myfaces component.
> >>So maybe, where possible, you could create a new utility class which
> >>will do the hard work, in your component the implemented method is only
> >>a one-liner then.
> >>
> >>Whatever solution you decide to use, it wont save the world ;-)
> >>
> >>Ciao,
> >>Mario
> >>
> >>
> >>
> >>
> >
> >
> >--
> >
> >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
Re: findComponent, dataTable, messages
Posted by Jacob Hookom <ja...@hookom.net>.
This ties somewhat appropriately to the ideas behing ProcessingContexts
(or Perspectives) with Avatar--
It involved creating a read-only (like event) interface for UIComponent
such that you can allow the UIComponent to tranverse itself, returning
an (event-facade) for the given component, if found.
http://weblogs.java.net/blog/jhook/archive/2005/09/jsf_avatar_vs_m_1.html
Perspective p = uiData.findPerspective(faces, "_id0:foo:3:bar");
p.encodeAll(faces);
public Perspective findPerspective(FacesContext faces, String clientId) {
String myId = this.getClientId(faces);
if (clientId.equals(myId) {
return new Perspective(this);
} else if (clientId.startsWith(myId)) {
int idx = //find idx from clientId
int oidx = this.getRow();
// modify my state
this.setRow(idx);
// find child now
Perspective p;
try {
p = super.findPerspective(faces, clientId);
} finally {
this.setRow(oidx);
}
if (p != null) {
return new IndexedPerspective(this, idx, p);
}
}
return null;
}
-- Jacob
Martin Marinschek wrote:
>Yeah,
>
>in fact I wanted to also hear feedback on the JSF-side of things. Like
>- if there's anything like that already implemented in Tobago, ADF
>Faces, planned for JSF 2.0.
>
>would be interesting to hear about that.
>
>regards,
>
>Martin
>
>On 1/21/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
>
>>>Yes, only for extended components. Not for API stuff.
>>>
>>>
>>>
>>Ok, so from now on its a matter of personal preferences.
>>Personally I like to use factories/providers and so on ;-)
>>In the current case it will make no difference between the various
>>components just try to lookup and execute.
>>
>>
>>
>>>- a third person might want to be able to change the behaviour (I
>>>don't believe they can, though, cause most of the stuff is private in
>>>the components)
>>>
>>>
>>>
>>And this might be the strongest point why to use the marker interface,
>>then the component is able to use its internal private states to do
>>stuff more efficient, eventually.
>>
>>Said all that, I think its not that bad to use the marker stuff here.
>>Only that it might lead to duplicate code if one requires the same
>>traversing policy but didnt extend from the myfaces component.
>>So maybe, where possible, you could create a new utility class which
>>will do the hard work, in your component the implemented method is only
>>a one-liner then.
>>
>>Whatever solution you decide to use, it wont save the world ;-)
>>
>>Ciao,
>>Mario
>>
>>
>>
>>
>
>
>--
>
>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
Re: findComponent, dataTable, messages
Posted by Martin Marinschek <ma...@gmail.com>.
Yeah,
in fact I wanted to also hear feedback on the JSF-side of things. Like
- if there's anything like that already implemented in Tobago, ADF
Faces, planned for JSF 2.0.
would be interesting to hear about that.
regards,
Martin
On 1/21/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> > Yes, only for extended components. Not for API stuff.
> >
> Ok, so from now on its a matter of personal preferences.
> Personally I like to use factories/providers and so on ;-)
> In the current case it will make no difference between the various
> components just try to lookup and execute.
>
> > - a third person might want to be able to change the behaviour (I
> > don't believe they can, though, cause most of the stuff is private in
> > the components)
> >
> And this might be the strongest point why to use the marker interface,
> then the component is able to use its internal private states to do
> stuff more efficient, eventually.
>
> Said all that, I think its not that bad to use the marker stuff here.
> Only that it might lead to duplicate code if one requires the same
> traversing policy but didnt extend from the myfaces component.
> So maybe, where possible, you could create a new utility class which
> will do the hard work, in your component the implemented method is only
> a one-liner then.
>
> Whatever solution you decide to use, it wont save the world ;-)
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: findComponent, dataTable, messages
Posted by Mario Ivankovits <ma...@ops.co.at>.
> Yes, only for extended components. Not for API stuff.
>
Ok, so from now on its a matter of personal preferences.
Personally I like to use factories/providers and so on ;-)
In the current case it will make no difference between the various
components just try to lookup and execute.
> - a third person might want to be able to change the behaviour (I
> don't believe they can, though, cause most of the stuff is private in
> the components)
>
And this might be the strongest point why to use the marker interface,
then the component is able to use its internal private states to do
stuff more efficient, eventually.
Said all that, I think its not that bad to use the marker stuff here.
Only that it might lead to duplicate code if one requires the same
traversing policy but didnt extend from the myfaces component.
So maybe, where possible, you could create a new utility class which
will do the hard work, in your component the implemented method is only
a one-liner then.
Whatever solution you decide to use, it wont save the world ;-)
Ciao,
Mario
Re: findComponent, dataTable, messages
Posted by Martin Marinschek <ma...@gmail.com>.
Yes, only for extended components. Not for API stuff.
Hmm - but any component extending from the jsf base class can also
implement the marker interface, right?
The tradeoff is
- component is a black box, knows how it does stuff - noone else knows,
and
- a third person might want to be able to change the behaviour (I
don't believe they can, though, cause most of the stuff is private in
the components)
regards,
Martin
On 1/21/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi Martin!
> > the question is if it is any better than letting the component extend
> > from a marker interface and implement the functionality itself.
> >
> But I thought its not allowed to change the api. Or do you plan to add
> this only to the myfaces classes?
> Then I think the policy solution is better as it might work with any
> component extending one of the jsf base classes.
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: findComponent, dataTable, messages
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Martin!
> the question is if it is any better than letting the component extend
> from a marker interface and implement the functionality itself.
>
But I thought its not allowed to change the api. Or do you plan to add
this only to the myfaces classes?
Then I think the policy solution is better as it might work with any
component extending one of the jsf base classes.
Ciao,
Mario
Re: findComponent, dataTable, messages
Posted by Martin Marinschek <ma...@gmail.com>.
Hmmm....
that could work.
the question is if it is any better than letting the component extend
from a marker interface and implement the functionality itself.
Thoughts?
regards,
Martin
On 1/20/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi
> > ad 1) no - not even protected is allowed. The problem is that you
> > don't want an application to rely on a certain implementation of the
> > api - you change the api, and nothing works anymore ;)
> >
> Ok, thats bad.
> > ad 2) yes, well, instanceof to UIData is bad. There I'm completely
> > d'accord with Simon. But an instanceof to an interface defining some
> > generic behaviour is pretty ok in my opinion. not marker interface
> > instead of instanceof, but instanceof to marker interface instead of
> > to UIData.
> >
> Ok, I understand.
>
> There is still one last idea, a little bit complicated, but this avoids
> this marker interface too.
> You could have a TraversePolicyProvider.
>
> Lets speak code:
>
> TraversePolicyFactroy.register(UIComponent.class, new
> TraverseComponentChildren());
> TraversePolicyFactroy.register(UIData.class, new TraverseDataChildren());
>
> Then on TraversePolicyFactroy:
> TraversePolicy create(UIComponent component)
> {
> find a TraversePolicy for component.getClass() or one of its super
> classes.
> return it;
> }
>
> Somewhat complicated, but hey it works. Is extensible and didnt need any
> change on the api and no marker interface.
>
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: findComponent, dataTable, messages
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi
> ad 1) no - not even protected is allowed. The problem is that you
> don't want an application to rely on a certain implementation of the
> api - you change the api, and nothing works anymore ;)
>
Ok, thats bad.
> ad 2) yes, well, instanceof to UIData is bad. There I'm completely
> d'accord with Simon. But an instanceof to an interface defining some
> generic behaviour is pretty ok in my opinion. not marker interface
> instead of instanceof, but instanceof to marker interface instead of
> to UIData.
>
Ok, I understand.
There is still one last idea, a little bit complicated, but this avoids
this marker interface too.
You could have a TraversePolicyProvider.
Lets speak code:
TraversePolicyFactroy.register(UIComponent.class, new
TraverseComponentChildren());
TraversePolicyFactroy.register(UIData.class, new TraverseDataChildren());
Then on TraversePolicyFactroy:
TraversePolicy create(UIComponent component)
{
find a TraversePolicy for component.getClass() or one of its super
classes.
return it;
}
Somewhat complicated, but hey it works. Is extensible and didnt need any
change on the api and no marker interface.
Ciao,
Mario
Re: findComponent, dataTable, messages
Posted by Martin Marinschek <ma...@gmail.com>.
ad 1) no - not even protected is allowed. The problem is that you
don't want an application to rely on a certain implementation of the
api - you change the api, and nothing works anymore ;)
ad 2) yes, well, instanceof to UIData is bad. There I'm completely
d'accord with Simon. But an instanceof to an interface defining some
generic behaviour is pretty ok in my opinion. not marker interface
instead of instanceof, but instanceof to marker interface instead of
to UIData.
regards,
Martin
On 1/20/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi Martin!
> > we won't be able to do this on UIComponent. The problem is, that we
> > can't extend the API - that's fixed.
> Even if you make it protected? You can use reflection then to call the
> entry point.
>
> > Of course not instanceOf for UIData, but some generic
> > marker interface.
> Marker interface?
> I know what a marker interface is, but how can this help here? Why would
> it be better than instanceof?
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: findComponent, dataTable, messages
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Martin!
> we won't be able to do this on UIComponent. The problem is, that we
> can't extend the API - that's fixed.
Even if you make it protected? You can use reflection then to call the
entry point.
> Of course not instanceOf for UIData, but some generic
> marker interface.
Marker interface?
I know what a marker interface is, but how can this help here? Why would
it be better than instanceof?
Ciao,
Mario
Re: findComponent, dataTable, messages
Posted by Martin Marinschek <ma...@gmail.com>.
Well,
we won't be able to do this on UIComponent. The problem is, that we
can't extend the API - that's fixed. So there'll be the need for some
extra-handling to be done outside of UIComponent, and also for some
instanceOfs. Of course not instanceOf for UIData, but some generic
marker interface.which implements this functionality.
regards,
Martin
On 1/20/06, Mario Ivankovits <im...@apache.org> wrote:
> Hi!
> > It does sound a little fragile, though. It means treating UIData
> > components specially which I don't like. Any use of "instanceof" in an
> > OO program is a warning sign. Or can the UIData override findComponent
> > on itself to manage that transparently? If so, that would be nice.
> > Possibly non-portable though.
> >
> You can delegate this executeOnComponent to the component and thus each
> component can implement its own strategy to find the requested child. So
> no instanceof needed, though an addition to UIComponent (overriden by
> UIData).
> Using a "boolean" return value to indicate the work has been done.
> Something like the visitor pattern
>
> So something like this (for sure, not jdk15 - I've done just do keep it
> smaller):
>
> on UIComponent:
>
> public boolean executeOnComponent(String id, ComponentExecutor process)
> {
> if (id.equals(getId())
> {
> process.process(this);
> return true;
> }
>
> for (UIComponent component : components)
> {
> if (component.executeOnComponent(id, process)
> {
> return true;
> }
> }
> return false;
> }
>
> on UIData:
>
> public boolean executeOnComponent(String id, ComponentExecutor process)
> {
> for (int row : rows)
> {
> // save the rowNum
> //skim through rows
> //set the rowNum
> // call executeOnComponent on each child
> // restore the rowNum
> }
>
> reutrn super.executeOnComponent(id, process);
> }
>
> And dont forget to iterate through the facets too. Else you might not
> find the component embedded in e.g. an panelLayout (a bug with ajax I
> already filed)
>
> No need of instanceof, or do I miss something yet?
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: findComponent, dataTable, messages
Posted by Mario Ivankovits <im...@apache.org>.
Hi!
> It does sound a little fragile, though. It means treating UIData
> components specially which I don't like. Any use of "instanceof" in an
> OO program is a warning sign. Or can the UIData override findComponent
> on itself to manage that transparently? If so, that would be nice.
> Possibly non-portable though.
>
You can delegate this executeOnComponent to the component and thus each
component can implement its own strategy to find the requested child. So
no instanceof needed, though an addition to UIComponent (overriden by
UIData).
Using a "boolean" return value to indicate the work has been done.
Something like the visitor pattern
So something like this (for sure, not jdk15 - I've done just do keep it
smaller):
on UIComponent:
public boolean executeOnComponent(String id, ComponentExecutor process)
{
if (id.equals(getId())
{
process.process(this);
return true;
}
for (UIComponent component : components)
{
if (component.executeOnComponent(id, process)
{
return true;
}
}
return false;
}
on UIData:
public boolean executeOnComponent(String id, ComponentExecutor process)
{
for (int row : rows)
{
// save the rowNum
//skim through rows
//set the rowNum
// call executeOnComponent on each child
// restore the rowNum
}
reutrn super.executeOnComponent(id, process);
}
And dont forget to iterate through the facets too. Else you might not
find the component embedded in e.g. an panelLayout (a bug with ajax I
already filed)
No need of instanceof, or do I miss something yet?
Ciao,
Mario
Re: Fwd: findComponent, dataTable, messages
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
>> I don't want to access the data-model. I need to access the component
>> directly, cause I need to access it from another component.
>>
> I guess I don't get the difference, maybe I havent learned enough yet.
>
Ok, foget it, thought about it a little bit more, now I know what you
mean :-(
Though, no idea now.
Ciao,
Mario
Re: Fwd: findComponent, dataTable, messages
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Martin!
> I don't want to access the data-model. I need to access the component
> directly, cause I need to access it from another component.
I guess I don't get the difference, maybe I havent learned enough yet.
irc @ #myfaces now ?
---
Mario
Re: Fwd: findComponent, dataTable, messages
Posted by Martin Marinschek <ma...@gmail.com>.
Sorry, I kind of left out the myfaces-list in the forward, put it again.
I don't want to access the data-model. I need to access the component
directly, cause I need to access it from another component. The
problem is e.g. with messages, when a validation fails and the input
field the message is referring to is wrapped in a dataTable.
I'm re-adding two of my original mails for more context.
regards,
Martin
=============================
Hi *,
I am having the following problem:
whenever I use dataTables
- and use messages alongside, or AJAX, or other stuff using findComponent -
I have the problem that I can't work with the components that are
children of the dataTables if I call a findComponent. Of course - I
won't find the correct component instance, due to the generated id and
the things the dataTable is doing to set the context of the current
row.
I've been thinking of a solution to this problem, and the only
solution that has come to my mind is to get rid of findComponent for
such things - and create an "executeOnComponent" method, which can be
implemented by all components doing special things with their
children.
I believe that components are too much of a black box for
findComponent ever to work at all - what's your impression?
Thoughts? feedback? Better ideas ;) ?
regards,
Martin
============================================
Example 1: try to use an input-field in your data-table, and look at
the output of the <h:messages> - the messages won't indicate the row
of the component in the dataTable - they can't, due to this problem.
Example 2: try to use the new AJAX-form components (which rely on the
usage of find-component heavily) in a dataTable.
regards,
Martin
On 1/20/06, Ed Burns <ed...@sun.com> wrote:
> >>>>> On Fri, 20 Jan 2006 15:36:29 +0100, Martin Marinschek <ma...@gmail.com> said:
>
> MM> Can we have a comment of the experts on this ;) ?
> MM> This message - dataTable problem really bugs me in every project I'm
> MM> doing with JSF...
>
> You can use the DataProvider API that's a part of Creator.
>
> Or, you could find the table, get its DataModel, and use the DataModel
> API to get the row data.
>
> Ed
>
> --
> | ed.burns@sun.com | {home: 407 869 9587, office: 408 884 9519 OR x31640}
> | homepage: | http://purl.oclc.org/NET/edburns/
> | aim: edburns0sunw | iim: ed.burns@sun.com
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: findComponent, dataTable, messages
Posted by Simon Kitching <sk...@apache.org>.
Ok. I think I see....here's my understanding of the issue; please
correct me if I've misinterpreted.
The problem is when you've got an id of form "form:table:3:component",
eg received via an ajax call.
Just adding a colon to the front forms an absolute path that
findComponent can use to locate that component by tracing from the
UIViewRoot down, yes?
However the "row" bit in the middle is a problem. The findComponent
method will fail, looking for a component of id "3". Even if it does
recognise that "table" is a UIData, steps into it, finds the child
component, then returns it the problem remains that you've got a
reference to a component but can't call it because its "state" does not
reflect the row it's on. If findComponent were to call setRowIndex on
the UIData component, that would work, but would potentially stuff up
the UIData's current state for other purposes.
An "executeOnComponent" that works like findComponent but takes a
"callback" does sound useful here. It walks the component tree like
findComponent, detecting UIData components, saving their current
rowIndex and setting it to the provided index from the path. When the
component is finally found, the callback is executed passing the
component. On completion, the find process is then unwound, restoring
any UIData components to their original rowIndex.
It does sound a little fragile, though. It means treating UIData
components specially which I don't like. Any use of "instanceof" in an
OO program is a warning sign. Or can the UIData override findComponent
on itself to manage that transparently? If so, that would be nice.
Possibly non-portable though.
Or did you mean something else??
Cheers,
Simon
On Fri, 2006-01-20 at 12:24 +0100, Martin Marinschek wrote:
> Example 1: try to use an input-field in your data-table, and look at
> the output of the <h:messages> - the messages won't indicate the row
> of the component in the dataTable - they can't, due to this problem.
>
> Example 2: try to use the new AJAX-form components (which rely on the
> usage of find-component heavily) in a dataTable.
>
> regards,
>
> Martin
>
> On 1/20/06, Simon Kitching <sk...@apache.org> wrote:
> > On Fri, 2006-01-20 at 11:57 +0100, Martin Marinschek wrote:
> > > Hi *,
> > >
> > > I am having the following problem:
> > >
> > > whenever I use dataTables
> > >
> > > - and use messages alongside, or AJAX, or other stuff using findComponent -
> > >
> > > I have the problem that I can't work with the components that are
> > > children of the dataTables if I call a findComponent. Of course - I
> > > won't find the correct component instance, due to the generated id and
> > > the things the dataTable is doing to set the context of the current
> > > row.
> > >
> > > I've been thinking of a solution to this problem, and the only
> > > solution that has come to my mind is to get rid of findComponent for
> > > such things - and create an "executeOnComponent" method, which can be
> > > implemented by all components doing special things with their
> > > children.
> > >
> > > I believe that components are too much of a black box for
> > > findComponent ever to work at all - what's your impression?
> > >
> > > Thoughts? feedback? Better ideas ;) ?
> >
> > I've found findComponent very useful (once I figured out what it does;
> > the sun-provided documenation really sucked).
> >
> > Of course I've never had the need for a component to "find" another
> > component that is nested inside a table.
> >
> > I don't understand your "executeOnComponent" suggestion. Could you give
> > an example?
> >
> > Regards,
> >
> > Simon
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
Re: findComponent, dataTable, messages
Posted by Martin Marinschek <ma...@gmail.com>.
As for your final question - just like Simon indicated it should work ;)
regards,
Martin
On 1/20/06, Martin Marinschek <ma...@gmail.com> wrote:
> No we can't - you'd have to reset that rowIndex thing after the
> component that called setRowIndex has finished processing the
> component.
>
> you don't know when that will be.
>
> regards,
>
> Martin
>
> On 1/20/06, Volker Weber <us...@weber-oldenburg.de> wrote:
> > Hi,
> >
> > Martin Marinschek wrote:
> > > Example 1: try to use an input-field in your data-table, and look at
> > > the output of the <h:messages> - the messages won't indicate the row
> > > of the component in the dataTable - they can't, due to this problem.
> >
> > how will you solve this with the "executeOnComponent" method?
> >
> > >
> > > Example 2: try to use the new AJAX-form components (which rely on the
> > > usage of find-component heavily) in a dataTable.
> >
> > Can't we do a setRowIndex() in the datatables findComponent() method?
> > Of cause this wouldn't help on multiple findComponent() calls in
> > different rows, but on e.g. inputsuggestajax (i don't know the others)
> > it should work.
> >
> > Can you explain how the suggested executeOnComponent method should work?
> >
> > Regards,
> > Volker
> >
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 1/20/06, Simon Kitching <sk...@apache.org> wrote:
> > >
> > >>On Fri, 2006-01-20 at 11:57 +0100, Martin Marinschek wrote:
> > >>
> > >>>Hi *,
> > >>>
> > >>>I am having the following problem:
> > >>>
> > >>>whenever I use dataTables
> > >>>
> > >>>- and use messages alongside, or AJAX, or other stuff using findComponent -
> > >>>
> > >>>I have the problem that I can't work with the components that are
> > >>>children of the dataTables if I call a findComponent. Of course - I
> > >>>won't find the correct component instance, due to the generated id and
> > >>>the things the dataTable is doing to set the context of the current
> > >>>row.
> > >>>
> > >>>I've been thinking of a solution to this problem, and the only
> > >>>solution that has come to my mind is to get rid of findComponent for
> > >>>such things - and create an "executeOnComponent" method, which can be
> > >>>implemented by all components doing special things with their
> > >>>children.
> > >>>
> > >>>I believe that components are too much of a black box for
> > >>>findComponent ever to work at all - what's your impression?
> > >>>
> > >>>Thoughts? feedback? Better ideas ;) ?
> > >>
> > >>I've found findComponent very useful (once I figured out what it does;
> > >>the sun-provided documenation really sucked).
> > >>
> > >>Of course I've never had the need for a component to "find" another
> > >>component that is nested inside a table.
> > >>
> > >>I don't understand your "executeOnComponent" suggestion. Could you give
> > >>an example?
> > >>
> > >>Regards,
> > >>
> > >>Simon
> > >>
> > >>
> > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> >
> > --
> > Don't answer to From: address!
> > Mail to this account are droped if not recieved via mailinglist.
> > To contact me direct create the mail address by
> > concatenating my forename to my senders domain.
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: findComponent, dataTable, messages
Posted by Martin Marinschek <ma...@gmail.com>.
No we can't - you'd have to reset that rowIndex thing after the
component that called setRowIndex has finished processing the
component.
you don't know when that will be.
regards,
Martin
On 1/20/06, Volker Weber <us...@weber-oldenburg.de> wrote:
> Hi,
>
> Martin Marinschek wrote:
> > Example 1: try to use an input-field in your data-table, and look at
> > the output of the <h:messages> - the messages won't indicate the row
> > of the component in the dataTable - they can't, due to this problem.
>
> how will you solve this with the "executeOnComponent" method?
>
> >
> > Example 2: try to use the new AJAX-form components (which rely on the
> > usage of find-component heavily) in a dataTable.
>
> Can't we do a setRowIndex() in the datatables findComponent() method?
> Of cause this wouldn't help on multiple findComponent() calls in
> different rows, but on e.g. inputsuggestajax (i don't know the others)
> it should work.
>
> Can you explain how the suggested executeOnComponent method should work?
>
> Regards,
> Volker
>
> >
> > regards,
> >
> > Martin
> >
> > On 1/20/06, Simon Kitching <sk...@apache.org> wrote:
> >
> >>On Fri, 2006-01-20 at 11:57 +0100, Martin Marinschek wrote:
> >>
> >>>Hi *,
> >>>
> >>>I am having the following problem:
> >>>
> >>>whenever I use dataTables
> >>>
> >>>- and use messages alongside, or AJAX, or other stuff using findComponent -
> >>>
> >>>I have the problem that I can't work with the components that are
> >>>children of the dataTables if I call a findComponent. Of course - I
> >>>won't find the correct component instance, due to the generated id and
> >>>the things the dataTable is doing to set the context of the current
> >>>row.
> >>>
> >>>I've been thinking of a solution to this problem, and the only
> >>>solution that has come to my mind is to get rid of findComponent for
> >>>such things - and create an "executeOnComponent" method, which can be
> >>>implemented by all components doing special things with their
> >>>children.
> >>>
> >>>I believe that components are too much of a black box for
> >>>findComponent ever to work at all - what's your impression?
> >>>
> >>>Thoughts? feedback? Better ideas ;) ?
> >>
> >>I've found findComponent very useful (once I figured out what it does;
> >>the sun-provided documenation really sucked).
> >>
> >>Of course I've never had the need for a component to "find" another
> >>component that is nested inside a table.
> >>
> >>I don't understand your "executeOnComponent" suggestion. Could you give
> >>an example?
> >>
> >>Regards,
> >>
> >>Simon
> >>
> >>
> >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
> --
> Don't answer to From: address!
> Mail to this account are droped if not recieved via mailinglist.
> To contact me direct create the mail address by
> concatenating my forename to my senders domain.
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: findComponent, dataTable, messages
Posted by Volker Weber <us...@weber-oldenburg.de>.
Hi,
Martin Marinschek wrote:
> Example 1: try to use an input-field in your data-table, and look at
> the output of the <h:messages> - the messages won't indicate the row
> of the component in the dataTable - they can't, due to this problem.
how will you solve this with the "executeOnComponent" method?
>
> Example 2: try to use the new AJAX-form components (which rely on the
> usage of find-component heavily) in a dataTable.
Can't we do a setRowIndex() in the datatables findComponent() method?
Of cause this wouldn't help on multiple findComponent() calls in
different rows, but on e.g. inputsuggestajax (i don't know the others)
it should work.
Can you explain how the suggested executeOnComponent method should work?
Regards,
Volker
>
> regards,
>
> Martin
>
> On 1/20/06, Simon Kitching <sk...@apache.org> wrote:
>
>>On Fri, 2006-01-20 at 11:57 +0100, Martin Marinschek wrote:
>>
>>>Hi *,
>>>
>>>I am having the following problem:
>>>
>>>whenever I use dataTables
>>>
>>>- and use messages alongside, or AJAX, or other stuff using findComponent -
>>>
>>>I have the problem that I can't work with the components that are
>>>children of the dataTables if I call a findComponent. Of course - I
>>>won't find the correct component instance, due to the generated id and
>>>the things the dataTable is doing to set the context of the current
>>>row.
>>>
>>>I've been thinking of a solution to this problem, and the only
>>>solution that has come to my mind is to get rid of findComponent for
>>>such things - and create an "executeOnComponent" method, which can be
>>>implemented by all components doing special things with their
>>>children.
>>>
>>>I believe that components are too much of a black box for
>>>findComponent ever to work at all - what's your impression?
>>>
>>>Thoughts? feedback? Better ideas ;) ?
>>
>>I've found findComponent very useful (once I figured out what it does;
>>the sun-provided documenation really sucked).
>>
>>Of course I've never had the need for a component to "find" another
>>component that is nested inside a table.
>>
>>I don't understand your "executeOnComponent" suggestion. Could you give
>>an example?
>>
>>Regards,
>>
>>Simon
>>
>>
>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.
Re: findComponent, dataTable, messages
Posted by Martin Marinschek <ma...@gmail.com>.
Example 1: try to use an input-field in your data-table, and look at
the output of the <h:messages> - the messages won't indicate the row
of the component in the dataTable - they can't, due to this problem.
Example 2: try to use the new AJAX-form components (which rely on the
usage of find-component heavily) in a dataTable.
regards,
Martin
On 1/20/06, Simon Kitching <sk...@apache.org> wrote:
> On Fri, 2006-01-20 at 11:57 +0100, Martin Marinschek wrote:
> > Hi *,
> >
> > I am having the following problem:
> >
> > whenever I use dataTables
> >
> > - and use messages alongside, or AJAX, or other stuff using findComponent -
> >
> > I have the problem that I can't work with the components that are
> > children of the dataTables if I call a findComponent. Of course - I
> > won't find the correct component instance, due to the generated id and
> > the things the dataTable is doing to set the context of the current
> > row.
> >
> > I've been thinking of a solution to this problem, and the only
> > solution that has come to my mind is to get rid of findComponent for
> > such things - and create an "executeOnComponent" method, which can be
> > implemented by all components doing special things with their
> > children.
> >
> > I believe that components are too much of a black box for
> > findComponent ever to work at all - what's your impression?
> >
> > Thoughts? feedback? Better ideas ;) ?
>
> I've found findComponent very useful (once I figured out what it does;
> the sun-provided documenation really sucked).
>
> Of course I've never had the need for a component to "find" another
> component that is nested inside a table.
>
> I don't understand your "executeOnComponent" suggestion. Could you give
> an example?
>
> Regards,
>
> Simon
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: findComponent, dataTable, messages
Posted by Simon Kitching <sk...@apache.org>.
On Fri, 2006-01-20 at 11:57 +0100, Martin Marinschek wrote:
> Hi *,
>
> I am having the following problem:
>
> whenever I use dataTables
>
> - and use messages alongside, or AJAX, or other stuff using findComponent -
>
> I have the problem that I can't work with the components that are
> children of the dataTables if I call a findComponent. Of course - I
> won't find the correct component instance, due to the generated id and
> the things the dataTable is doing to set the context of the current
> row.
>
> I've been thinking of a solution to this problem, and the only
> solution that has come to my mind is to get rid of findComponent for
> such things - and create an "executeOnComponent" method, which can be
> implemented by all components doing special things with their
> children.
>
> I believe that components are too much of a black box for
> findComponent ever to work at all - what's your impression?
>
> Thoughts? feedback? Better ideas ;) ?
I've found findComponent very useful (once I figured out what it does;
the sun-provided documenation really sucked).
Of course I've never had the need for a component to "find" another
component that is nested inside a table.
I don't understand your "executeOnComponent" suggestion. Could you give
an example?
Regards,
Simon