Hi So should we leave the Tld2ClayCfg as it is now (with the latest patch) ? It outputs al the required components, but lacks the information that we can't get from the ld or by introspecting the tags.
Another possible solution that I have is to add another section to the plugin where one could link special things like these with the "componentType". This way the tool would build a complete definition file that would need no further manual tweaking. SInce these definitions only are related to a few tld's and there or not that many of them I think that this is a viable solution. Hermod -----Original Message----- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 13, 2007 11:38 PM To: dev@shale.apache.org Subject: Re: Update to Tld2ClayCfg >From: "Craig McClanahan" <[EMAIL PROTECTED]> > > On 2/12/07, Hermod Opstvedt wrote: > > > > Hi > > > > I updated the Tld2ClayCfg tool in order to support Validators, Converters > > and rendererType. > > > > As I mentioned in the issue, there is a problem with getting hold of the > > componentType for these. There is the possibility of assuming that the > > > > componentType is the same as the tag-class minus the Tag ending, but I > > > > don't > > think that will stick. So if anyone has a bright idea, please shout out. > > > > Could someone also commit the patches to the Clay starter archetype. There > > are som bugfixes in there. > > > I haven't followed all the details of this, but does Clay require some > association between particular converter/validator classes and part icular > component classes? If it does, that doesn't really make sense to me. > When you add a validator, converter or listener to a component, it requires using a nested element under the "component" top-level element. These nested elements, point to a top-level component definition. The Clay XML configs define component, converters, validators and listeners as top-level components. This is similar to defining a tag definition in the TLD for each associated components, validators, converters and listeners. For a top-level component definition (components, converters, validators and listeners), the componentType attribute is the JSF componentType, converterId, validatorId or the fully qualified class path to the listener. Historically, the clay config used a neutral mnemonic "displayElement". A "displayElement" captured generic metadata about these JSF elements. We changed to "component", while it was still in a bugzilla ticket, to make it more familiar with the Tapestry terminology. In hindsight, "displayElement" might have been a better name. For example, a custom converter with a property: <component jsfid="myconverter" componentType="myregisteredConverterId" > <attributes> <set name="customProperty" bindingType="Early" /> </attributes> </component> Given a specific use within the application: <component jsfid="myinputwidget" extends="inputText" > <attributes/> <conveter jsfid="myconverter"> <set name="customProperty" value="something" /> </converter> </component> > For validators, there isn't really any formal linkage between validator > > classes and component classes at the JSF level. It seems to me that we > > should not try to enforce such a distinction in Clay either. > Yeah, I think the best we can do is load the tag and determine that it extends ValidatorTag or ConverterTag and then just dump the attributes and fill the componentType with a dummy value that has to be manually addressed. That's what I did with the Trinidad library but I don't see a way to even attempt to handle action and value change listners. For example: <component jsfid="setActionListener" componentType="FIXME.<Tagclassname>"> <attributes> <set name="from" bindingType="VB"/> <set name="to" bindingType="VB"/> </attributes> </component> > For converters, JSF has the concept of converter-for-class ... but it is > > visible only in faces-config.xml not in a TLD. That is because the correct > converter is selected automatically if you have a value binding on the > "value" property, and the JSF runtime can determine the destination type. > > This works no matter what view handler is used, so you should be getting it > for free with Clay. > Using the "converter" value binding attribtue of the component doesn't require a Clay "component" defintion for the converter. It is only needed if you need to pass properties to the converter which would be handled in JSP with a custom tag. Clay will also allow you to "bind" converters, validators and listeners to backing beans - a JSF 1.2 feature. > Outside of that, it should be technically possible to configure any > converter on any component that implements ValueHolder, and to configure any > validator on any component that implements EditableValueHolder. > It's unfortunately we can't rip all of the clay config from the TLD's. Maybe in the future, this metadata could be ripped from mandated annotations..... > Hermod > > > > > Craig Gary * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that the DnB NOR Group cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the anti virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
