Hi My suggestion for the added mapping goes for the Maven build. This means that when you build Clay, the correct configuration file information is build and you don't have to handtweak it afterwards. There would be some minimal maintenance of that list when something new is added though.
Hermod -----Opprinnelig melding----- Fra: Gary VanMatre [mailto:[EMAIL PROTECTED] Sendt: 14. februar 2007 17:52 Til: dev@shale.apache.org Emne: RE: Update to Tld2ClayCfg >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. > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >
