On 2/13/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> >Today I upgraded to the latest nightly build (2/13) for shale-core and
> >shale-clay. It seems my clay onchange properties are being omitted
> >now. Not sure in which nightly they stopped working. Anyone else
> >having this problem?
> >
> ><component jsfid='mySelectOne" extends="selectOneMenu">
> > <attributes>
> > <set name="binding" value="#{myBean.widget}"/>
> > <set name="onchange" value="this.form.submit()"/>
> > </attributes>
> ></component>
> >
> >onchange does not get rendered for above example. I think it may have
> >to do with the recent work on binding because my example does include
> >this attribute and I know it was worked on recently.
> >
> The new binding code doesn't apply any attribute values to the bound
> component. I figured that all of the component property values needed
> to be set in code for bound attributes? I'm ok with letting clay do
> its standard setup but what might happen is that a value set in code
> might get overridden by a configuration param.
>
> Any thoughts?
Interestingly, that parallels a corresponding issue with the JSP rendition
of JSF components in JSF 1.0/1.1 ... if you have a property set in a tag
attribute, AND you set it in code, which wins? For JSP pages, we went round
and round on this, but decided ultimately that the JSP page author's
expectation that the attributes he or she sets in the page should win
outweighed the surprise that the Java developer is going to have when his
change doesn't seem to show up. Note that this ONLY applies when the
component tree is being first produced, and I haven't looked inside 1.2 yet
to see how the changes there (even with JSP, the component tree is now built
up in total, more like what Clay does already) have affected this.
But the point of the rambling paragraph above :-) is that we should look at
how the corresponding concept works with JSP rendering, and then either
deliberately decide to match it or differ with it.
>Thanks,
> >Ryan
>
> Gary
>
Craig
