Ken Paulsen wrote:
>
>
> Gregory Murphy wrote:
>
>> Ken Paulsen wrote:
>>
>>> Adding the @Renderer annotation to a UIComponent class works
>>> provided that you use the rendererClass property as well... AND you
>>> don't have a @Component annotation. The way the current annotation
>>> processor is written, it doesn't support 2 annotations on a single
>>> class... or at least I haven't figured out the correct syntax to get
>>> that to work. I think the problem is that when you specify both
>>> annotations, the first annotation annotates the 2nd annotation
>>> instead of both annotating the class. Separating w/ commas didn't
>>> seem to help. There's a good change I'm doing something wrong when
>>> defining the annotation, though.
>>
>>
>>
>> An annotation may use another annotation as the type of one of its
>> elements, but you can't annotate an annotation. I don't know enough
>> about formal languages to be able to explain why this is.
>
> I'm not sure of the details either... however, when I tried doing:
>
> @Renderer...
> @Component...
>
> It didn't process the @Renderer annotation at all. It did if I
> removed the @Component one. Anyway, in my test cases, I was doing the
> following:
>
> @Component(rendererClass="..." ...)
But this association is not appropriate.
A component should not dictate its renderer-class.
-rick
>
> Which was more concise and worked well.
>
> Ken
>
>>
>> The current library and processor do support multiple renderer
>> annotations, so that one renderer can be assigned to more than one
>> component family. For example:
>>
>> @Renderer({
>> @Renders(componentFamily="org.example.input"),
>> @Renders(componentFamily="org.example.output")
>> })
>> public class MyFavoriteRenderer {
>> }
>>
>> So you can use a single template renderer with a whole mess of
>> components, but you have to annotate the renderer to create these
>> associations, not the components. If users are getting the template
>> renderer as part of a third party JAR, they could always extend it,
>> and annotate the extension.
>>
>> // Gregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_woodstock.dev.java.net
>> For additional commands, e-mail: dev-help_at_woodstock.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_woodstock.dev.java.net
> For additional commands, e-mail: dev-help_at_woodstock.dev.java.net
>