I thought so ;)

Ok, I'm going to add a subform-component to my approach. I still need
the attribute on the command-components, though, cause in my use-case
(and probably many out there) the command component may be _outside_
the subform-component. Additionally, I might have commands which don't
trigger validation and update for _any_ subform at all, even if they
are children of a subform.

Or do you have an idea for handling this as well?

It's a PITA that I need the behaviour right now and can't switch in
neither Tobago (they have something like this as well, but the
components don't work together with normal Tomahawk components) nor
ADF - it not being in incubator so far.

We should get the process of merging together the component sets finished ASAP.

regards,

Martin

On 12/29/05, Adam Winer <[EMAIL PROTECTED]> wrote:
> I don't think tweaking the API classes is legit - even if the signature
> didn't change.  The components would break if you swapped in the
> JSF RI, and that's not OK.  Behavioral portability is just as important
> as successful compilation!
>
> ADF Faces addresses this with a "subform" component:
>
> http://tinyurl.com/b2n2t
>
> -- Adam
>
>
> On 12/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > Hi *,
> >
> > I've implemented a proposal for "partial validation and model update".
> >
> > Essentially what I've done is I've given the commandLink and
> > commandButton a new attribute, "actionFor". This attribute is a
> > comma-separated lists of container-component-ids for which validation
> > and model update should happen.
> >
> > So if you have a
> >
> > <h:panelGroup id="xxx">
> > <h:inputText .../>
> > </h:panelGroup>
> >
> > and a
> >
> > <t:commandButton actionFor="xxx"/>
> >
> > the validation and model-update phases will only be triggered for
> > components which are descendants of the panelGroup with id="xxx".
> >
> > Sounds good?
> >
> > Fellow developers, I had to tweak the API-classes a little to make
> > this happen - I didn't change any signature or so, but I store stuff
> > in the externalContext.getRequestMap(). Maybe someone of you can come
> > up with a better, less intrusive solution to the problem?
> >
> > The only other solution I could think of would have been to implement
> > processValidations() and processUpdates() for every extended
> > component, not a very interesting outlook!
> >
> > regards,
> >
> > Martin
> >
> > --
> >
> > 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

Reply via email to