shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <hermod.opstv...@dnbnor.no>
Subject RE: Update to Tld2ClayCfg
Date Wed, 14 Feb 2007 06:51:27 GMT
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:gvanmatre@comcast.net]
Sent: Tuesday, February 13, 2007 11:38 PM
To: dev@shale.apache.org
Subject: Re: Update to Tld2ClayCfg


>From: "Craig McClanahan" <craigmcc@apache.org> 
>
> 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.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


Mime
View raw message