>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.
>
I guess that make sense since the focus is on the page author.
>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.
>
Good point. I looked in the 1.2 spec but didn't see anything addressing
this issue. But, it looks like converters, validators and listeners
will have binding too.
Clay's strength is in managing component metadata at a more reusable level
than JSP tags. I think that bound components could take advantage of that
if we allowed the metadata to take precedence over values set in code. It
sounds like that decision would be in line with the JSF 1.1.
My vote would be to allow config data to win.
>>Thanks,
>> >Ryan
>>
>> Gary
>>
>
>Craig
Gary
