>From: <[EMAIL PROTECTED]> > > 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. >
I think we should stick with components. There is only so much we can squeeze out of a TLD. For this reason, I think it is a good argument to setup archetypes for each component library. We will need to customize Clay for the special method bindings that various component libraries offer anyway. > 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. > That's not a bad idea but we could just as easily list multiple config files in the web.xml versus an XML document include. > Hermod > Gary > -----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" > > > > 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: > > > > > > > Given a specific use within the application: > > > > > > > > > > > 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: > > > > > > > > > > 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. > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >
