Ken Paulsen wrote:
>
>
> richard ratta wrote:
>
>> Back to the original issue ....
>>
>> I don't think adding a "RendererClass" annotation on the component is
>> appropriate.
>> A Component does not determine its renderer. Its renderer is
>> determined by its
>> component family and renderer type.
>>
>> I believe you can address your original issue by fixing the
>> annotation [rocessor to support
>> a many to one or none, relationship between component and renderer.
>> That funtionality
>> would help everyone.
>
> This does not help the use case I am describing at all. Remember,
> there is no Renderer to annotate (however, there *is* a Renderer
> class... it's just not available to be annotated as it is part of a
> 3rd party library).
>
>>
>> ....
>>
>> As to the side discussion ....
>>
>> I offered a suggestion to your simple use which you were using to
>> justify this change.
>> Your response should show you that using such "simple" use cases to
>> determine functionality
>> is not useful, because it is never the whole story, as we've seen
>> that story unfold.
>
> Not sure what you mean.
>
>> I understood you to be trying to help the 80% of users that use your
>> templating system and
>> to help them not to have to write so many files.
>
> Exactly.
>
>> My suggestion of
>> template components rendering themselves does this and removes those
>> users from ever having
>> to even know about a renderer.
>
> It also removes their ability to associate a different renderer with
> their component.
No. It means that faces-config entries must be made.
> I am not trying to make less powerful components, just easier ones. I
> do not like the idea of mixing the Renderer and the Component.
>
> Consider the case where you have a "h:inputText". Let's say the
> page-author decides they don't like the component-author's Renderer
> behavior.
It is not necessarliy the component author's renderer. There is just a
renderer associated
with the component if there is a faces config entry that matches the
component-family and
renderer-type.
> So page-author replaces the renderer with their own. This works for
> most JSF components... however, w/ your suggestion of merging the
> component & renderer, this use case is NOT possible. So your solution
> is not a solution.
This is not true.
The built in component renderer behavior must defer to a renderer that
matches the component-family
and renderer-type.
>> It also does not prevent changing renderkits, or substituting a
>> renderer for a given renderer-type and component family. That depends
>> on how you write the
>> rendering functionality. The standard JSF design pattern could be
>> used to just check for a
>> renderer for that component.
>
> Perhaps I misunderstood you before. Are you suggesting making the
> component do the checking to see if there is a registered Renderer and
> using it if it exists...
This is always done today. Remembere that technically a component always
renders itself. However
it makes a choice of looking for a renderer based on the component
family and renderer-type.
In our components we require an external renderkit therefore there are
no components in the Woodstock
set that write to the response. But components initiate rendering
themselves.
Renderers are note required by JSF.
> otherwise handing the Rendering itself? Perhaps this could work.
> However, this isn't how I currently handle things... and I'm not sure
> I want to change it. Making a class that extends from Renderer
> sometimes handle decode...
It does not have to extend from Renderer.
> and the UIComponent sometimes handle decode... except when you extend
> it. I think this may just add confusion, not simplification.
this is no different than the current component spec.
> Plus it is not obvious where the Renderer is to an end user (who could
> otherwise see the mapping in the faces-config.xml file and simply
> change it).
We were initially talking about rendering template'd components for
users that did not have renderers
and you wanted to reduce the noise for them.
>
> Yes, this solution may work... but it's not as nice as the one I
> currently have.
It is effectively the same.
>> In the use case you are using, you say there are no renderers to
>> annotate so most of the
>> time there won't be any renderer and the simple user can be supported.
>
> You misunderstood. There is no Renderer to annotate... however, there
> *is* a Renderer. It cannot be annotated because:
>
> 1) It is part of a 3rd party .jar file that they do not build
Subclass it and annotate it.
> 2) I don't want them to extend from it b/c that adds a 3rd file they
> have to work with, I want to keep it to 2 files only.
You say you want to simplify but yet you discuss very sophisticated use
casess like replacing
render kits.
>> A user with more
>> complicated needs should have no problem editing faces-config.xml in
>> which case they
>> wouldn't use your new annotation because they would just annotate the
>> renderer.
>
> This would require a 3rd file to edit. The whole point of this
> solution is to reduce the # of *required* files to edit.
>
> Am I making sense?
Yes and no.
I don't believe this change, just to reduce a simple file edit is
justifiable.
Adding this annotation by allowing a Component to be associated with a
RendererClass is not appropriate
in general.
-rick
>
> Ken
>
>>
>> ....
>>
>> -rick
>>
>> Ken Paulsen wrote:
>>
>>>
>>>
>>> richard ratta wrote:
>>>
>>>> The more I think about this the more confused I get as to why changing
>>>> a very specific annotation processor is the solution.
>>>>
>>>> JSF defines two strategies for rendering components. One is with a
>>>> renderkit
>>>> and the flexibility it offers . It defines a second strategy where
>>>> components render themselves.
>>>>
>>>> Your design appears to fall into the second strategy. In fact why
>>>> doesn's the template component superclass
>>>> implement the template rendering as well ?
>>>
>>>
>>> Why don't all the JSF standard components do it this way? Why don't
>>> any of the Woodstock components do it that way? The
>>> JSFTemplating-based Renderer have the SAME answer.
>>>
>>> There is NO difference between a Renderer that is template-based vs.
>>> one that is Java-based (except that there is not .java file for a
>>> template-based Renderer to annotate ;) ).
>>>
>>>> You don't need the a renderer at all as you claim, it just becomes
>>>> part of your
>>>> inherited component behavior.
>>>
>>>
>>> This reduces the options a component developer and the end users of
>>> the component have for Rendering a UIComponent. The would have
>>> hard-coded a 1-to-1 mapping between the output of the UIComponent
>>> and the UIComponent itself b/c there would be no mapping done at all.
>>>
>>> I do not want this. I want 1 UIComponent to be capable of being
>>> Rendered to N different devices / markup. I want the end-user to be
>>> able to override the default Renderer and provide their own
>>> implementation. Perhaps they'd extend the TemplateRenderer and add
>>> some monitoring / auditing features... perhaps they'd generate .java
>>> code from the template and use a .java based renderer which they've
>>> modified... perhaps they'd write their own alternate implementation
>>> of the Renderer. These are the SAME use-cases for which JSF
>>> provides the Renderer mappings.
>>>
>>>> We know that the current annotation processor supports components
>>>> that do not have a
>>>> a renderkit renderer. Unfortunately the processor reports warnings
>>>> because of this
>>>> but that is because of its specific nature.
>>>>
>>>> Just curious, what happens if a Woodstock component were to add the
>>>> @Renderer
>>>> annotation in error or is it appropriate in any way for the
>>>> Woodstock components ?
>>>
>>>
>>> The way I intended for this change to be used is to add the
>>> "rendererClass" attribute to a @Component annotation:
>>>
>>> @Component(type="com.sun.webui.jsf.DropDown",
>>> family="com.sun.webui.jsf.DropDown",
>>> rendererClass="com.sun.webui.jsf.renderkit.html.DropDownRenderer",
>>> ...)
>>>
>>> The above would work and you would not be required to annotate the
>>> DropDown Renderer. However... good practice would be to annotate
>>> it. And for cases where you have 1 UIComponent w/ many Renderers
>>> would not be satisified by this implementation.
>>>
>>> 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.
>>>
>>>> This really flies in the face of the strategy to have renderkits
>>>> for the Woodstock components
>>>> as well as JSF.
>>>
>>>
>>> ? I don't see how.
>>>
>>>> This makes me think even more so that if your components don't
>>>> utililize renderers in a
>>>> renderkit, then they are either components that are not rendered,
>>>> or they render themselves.
>>>
>>>
>>> They DO utilize this... but they do not DEFINE the Renderer in the
>>> Renderkit when using the template Renderer.
>>>
>>>
>>> Thanks!
>>>
>>> Ken
>>>
>>>>
>>>> -rick
>>>>
>>>> richard ratta wrote:
>>>>
>>>>>
>>>>>
>>>>> Ken Paulsen wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> richard ratta wrote:
>>>>>>
>>>>>>> I would like to see real requirements for this change, a little
>>>>>>> more on what
>>>>>>> is needed and why this change satisfies those requirements.
>>>>>>>
>>>>>>>> The motivation for this new feature is to be able to skip
>>>>>>>> creating a new Renderer for a component entirely. Jason Lee
>>>>>>>> and I are experimenting around with the Woodstock annotations +
>>>>>>>> JSFTemplating's TemplateRenderer to create components. I think
>>>>>>>> this is a good combination that reduces development to 2 files:
>>>>>>>> UIComponent file, and a template file. However, the current
>>>>>>>> annotations require a Renderer class to be present to place a
>>>>>>>> @Renderer annotation... and we don't have such a file in our
>>>>>>>> environment.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This rationalization really isn't very clear, technically speaking.
>>>>>>>
>>>>>>> I also don't see the relationship between a renderer-type and
>>>>>>> the renderer-class which is the relationship
>>>>>>> JSF defines. There is no relationship in JSF between a Component
>>>>>>> and a renderer-class. It is
>>>>>>>
>>>>>>> component-family
>>>>>>> renderer-type
>>>>>>> renderer-class
>>>>>>>
>>>>>>> And we have created complexities by dynamically changing a
>>>>>>> component's renderer-type
>>>>>>> at runtime based on the "type of request"; "normal" or "ajax".
>>>>>>>
>>>>>>
>>>>>> Hi Rick,
>>>>>>
>>>>>> Yes, JSF supports an N to N mapping between UIComponent and
>>>>>> Renderers. You can map N components to a single Renderer, or 1
>>>>>> UIComponent can end up being server by N different Renderers. In
>>>>>> order for this to work, as you pointed out, there cannot exist a
>>>>>> hard-coded relationship between the UIComponent class and the
>>>>>> Renderer class.
>>>>>>
>>>>>> For this reason this solution is not perfect... however, in my
>>>>>> scenario there is only 1 Java file, yet I'd like to take
>>>>>> advantage of the code generation done by the annotations so I can
>>>>>> alleviate developers of the need to write ANY xml in the
>>>>>> faces-config.xml file. I don't see any other practical way to do
>>>>>> this w/ the current Woodstock annotations / development environment.
>>>>>>
>>>>>> Also, if you look at the @annotations as the "default" generated
>>>>>> faces-config.xml file. Then this change *ONLY* provides a
>>>>>> *default* mapping between the UIComponent and 1 possible
>>>>>> Renderer. I see this as VERY valuable in my use case. Let me
>>>>>> elaborate on my use case....
>>>>>>
>>>>>> I have a template that might look something like:
>>>>>>
>>>>>> myComp.jsf:
>>>>>>
>>>>>> <span id="$this{componentId}"><b>$property{value}</b></span>
>>>>>>
>>>>>> Ok... that's a VERY simple component that wraps the "value"
>>>>>> property of the component in a span w/ bold tags... but valid...
>>>>>> see my TSS article for a much more complicated example
>>>>>> (http://www.theserverside.com/tt/articles/article.tss?l=JSFTemplateComponent).
>>>>>>
>>>>>>
>>>>>> I then have a UIComponent that is something like:
>>>>>>
>>>>>> public class MyComp extends TemplateInsertComponentBase
>>>>>> implements NamingContainer {
>>>>>> public MyComp() {
>>>>>> super();
>>>>>> setRendererType("com.sun.MyComp");
>>>>>> setLayoutDefinitionKey("jsftemplating/myComp.jsf");
>>>>>> }
>>>>>>
>>>>>> public String getFamily() {
>>>>>> return "com.sun.MyComp";
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> I don't have ANY other files for the component... however, I
>>>>>> would like to use Woodstock annotations to further simplify this
>>>>>> so that I don't have to configure the *faces-config.xml* file or
>>>>>> write a *JSP tag class*. With the current annotations I can't
>>>>>> quite do this because I do NOT have a Renderer class
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> then what is
>>>>> 'rendererClass="com.sun.jsftemplating.renderer.TemplateRenderer"' ?
>>>>> Why not just annotate that renderer, to support the family,
>>>>> "com.sun.Template" with renderer
>>>>> type "com.sun.Template", and have anyone that wants to use you
>>>>> "templates" make their component
>>>>> belong to that family ?
>>>>>
>>>>> Currently the annotation processor does enforce a 1 to 1 mapping
>>>>> and that is what I would rather
>>>>> see fixed so that it supports the JSF mapping possibilities.
>>>>>
>>>>> Adding other arbitraty rules and annotations just makes the
>>>>> annotations more cofusing.
>>>>> If they followed the JSF spec with respect to mapping components
>>>>> to renderers then
>>>>> it is easier to understand since it follows a standard specification.
>>>>> That should solve your use case as well, no ?
>>>>>
>>>>> I'm surprised everyone wants to get away from faces-config.xml. It
>>>>> seemed pretty useful to
>>>>> me to be able to map and define meta-data for compoents,
>>>>> unfortunately we didn't conform to
>>>>> it more strictly.
>>>>>
>>>>>
>>>>> -rick
>>>>>
>>>>>> where I can put the @Renderer annotation. With my proposed
>>>>>> change, I can add
>>>>>> *rendererClass="com.sun.jsftemplating.renderer.TemplateRenderer"*
>>>>>> to the @Component annotation and everything works.
>>>>>>
>>>>>> Does this make more sense?
>>>>>>
>>>>>> If we can do this... I'd like to write a java.sun.com article
>>>>>> explaining how this is done. My TSS article has already
>>>>>> generated a lot of interest, I think combining this with the
>>>>>> Woodstock annotations offers a solution that a lot of people
>>>>>> would be interested in.
>>>>>>
>>>>>>> See more inline
>>>>>>>
>>>>>>
>>>>>> ... (see below)
>>>>>>
>>>>>>>
>>>>>>> - RendersInfo(Map annotationValueMap) {
>>>>>>> + RendersInfo(Map annotationValueMap, String className) {
>>>>>>> this.annotationValueMap = annotationValueMap;
>>>>>>> + this.className = className;
>>>>>>> }
>>>>>>>
>>>>>>> You are changing an existing interface here.
>>>>>>> Any existing code that relies on the previous interface will break.
>>>>>>> You have to support the original interface as well as the new one.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes, you are correct. However, this is a class that is used
>>>>>> (indirectly) by APT only during compile time and doesn't manifest
>>>>>> itself at all during runtime (afaik). So unless someone has
>>>>>> extended the framework Woodstock has to develop their own JSF
>>>>>> annotations AND directly instantiates this static inner class
>>>>>> (DeclaredRendererInfo.RendersInfo), then this isn't a problem.
>>>>>>
>>>>>> Nevertheless, I'd be happy to support the old single-argument
>>>>>> constructor as well since this is easy to do and good practice.
>>>>>>
>>>>>> Ken
>>>>>>
>>>>>>>
>>>>>>> -rick
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Ken Paulsen wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I would like to commit a minor change to the annotations
>>>>>>>> woodstock provides. The change allows a @Component annotation
>>>>>>>> to take a "rendererClass" attribute to specify a Renderer that
>>>>>>>> should be used to Renderer the UIComponent.
>>>>>>>>
>>>>>>>> The motivation for this new feature is to be able to skip
>>>>>>>> creating a new Renderer for a component entirely. Jason Lee
>>>>>>>> and I are experimenting around with the Woodstock annotations +
>>>>>>>> JSFTemplating's TemplateRenderer to create components. I think
>>>>>>>> this is a good combination that reduces development to 2 files:
>>>>>>>> UIComponent file, and a template file. However, the current
>>>>>>>> annotations require a Renderer class to be present to place a
>>>>>>>> @Renderer annotation... and we don't have such a file in our
>>>>>>>> environment.
>>>>>>>>
>>>>>>>> I have run the annotation processor before and after this
>>>>>>>> change and compared the results. There is no difference at all
>>>>>>>> (as there shouldn't be since it only adds an optional property
>>>>>>>> which isn't currently present on any Woodstock components).
>>>>>>>>
>>>>>>>> The diffs are attached. Please let me know if you have any
>>>>>>>> objections to me checking in this change. Or if I should check
>>>>>>>> it in somewhere other than the HEAD.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Ken
>>>>>>>>
>>>>>>>> woodstock/annotations> cvs -q diff -u
>>>>>>>> Index: library/src/com/sun/faces/annotation/Component.java
>>>>>>>> ===================================================================
>>>>>>>>
>>>>>>>> RCS file:
>>>>>>>> /cvs/woodstock/annotations/library/src/com/sun/faces/annotation/Component.java,v
>>>>>>>>
>>>>>>>> retrieving revision 1.1
>>>>>>>> diff -u -r1.1 Component.java
>>>>>>>> --- library/src/com/sun/faces/annotation/Component.java 15 Feb
>>>>>>>> 2007 21:47:16 -0000 1.1
>>>>>>>> +++ library/src/com/sun/faces/annotation/Component.java 31 Aug
>>>>>>>> 2007 21:28:05 -0000
>>>>>>>> @@ -134,6 +134,8 @@
>>>>>>>> * is set to false), then providing a value for this
>>>>>>>> element has no effect.
>>>>>>>> */
>>>>>>>> public String tagRendererType() default "";
>>>>>>>> +
>>>>>>>> + public String rendererClass() default "";
>>>>>>>>
>>>>>>>> /**
>>>>>>>> * An optional short description of this component,
>>>>>>>> typically used as a tool
>>>>>>>> Index: library/src/com/sun/faces/annotation/Renderer.java
>>>>>>>> ===================================================================
>>>>>>>>
>>>>>>>> RCS file:
>>>>>>>> /cvs/woodstock/annotations/library/src/com/sun/faces/annotation/Renderer.java,v
>>>>>>>>
>>>>>>>> retrieving revision 1.1
>>>>>>>> diff -u -r1.1 Renderer.java
>>>>>>>> --- library/src/com/sun/faces/annotation/Renderer.java 15 Feb
>>>>>>>> 2007 21:48:01 -0000 1.1
>>>>>>>> +++ library/src/com/sun/faces/annotation/Renderer.java 31 Aug
>>>>>>>> 2007 21:28:05 -0000
>>>>>>>> @@ -82,6 +82,8 @@
>>>>>>>> @Target(ElementType.ANNOTATION_TYPE)
>>>>>>>> public @interface Renders {
>>>>>>>>
>>>>>>>> + public String rendererClass() default "";
>>>>>>>> +
>>>>>>>> /**
>>>>>>>> * The renderer type for this component and renderer
>>>>>>>> combination. If
>>>>>>>> * this annotation contains a single component family,
>>>>>>>> and a renderer type
>>>>>>>> Index:
>>>>>>>> processor/src/com/sun/faces/mirror/DeclaredRendererInfo.java
>>>>>>>> ===================================================================
>>>>>>>>
>>>>>>>> RCS file:
>>>>>>>> /cvs/woodstock/annotations/processor/src/com/sun/faces/mirror/DeclaredRendererInfo.java,v
>>>>>>>>
>>>>>>>> retrieving revision 1.1
>>>>>>>> diff -u -r1.1 DeclaredRendererInfo.java
>>>>>>>> ---
>>>>>>>> processor/src/com/sun/faces/mirror/DeclaredRendererInfo.java
>>>>>>>> 15 Feb 2007 21:56:49 -0000 1.1
>>>>>>>> +++
>>>>>>>> processor/src/com/sun/faces/mirror/DeclaredRendererInfo.java
>>>>>>>> 31 Aug 2007 21:28:06 -0000
>>>>>>>> @@ -44,9 +44,10 @@
>>>>>>>> this.annotationValueMap = annotationValueMap;
>>>>>>>> renderings = new ArrayList<RendersInfo>();
>>>>>>>> if (this.annotationValueMap.containsKey(VALUE)) {
>>>>>>>> + String qn = decl.getQualifiedName();
>>>>>>>> for (Object value : (List)
>>>>>>>> this.annotationValueMap.get(VALUE)) {
>>>>>>>> Map nestedAnnotationValueMap = (Map) value;
>>>>>>>> - renderings.add(new
>>>>>>>> RendersInfo(nestedAnnotationValueMap));
>>>>>>>> + renderings.add(new
>>>>>>>> RendersInfo(nestedAnnotationValueMap, qn));
>>>>>>>> }
>>>>>>>> }
>>>>>>>> }
>>>>>>>> @@ -60,15 +61,28 @@
>>>>>>>> */
>>>>>>>> static public class RendersInfo {
>>>>>>>>
>>>>>>>> + static String RENDERER_CLASS = "rendererClass";
>>>>>>>> static String RENDERER_TYPE = "rendererType";
>>>>>>>> static String COMPONENT_FAMILY = "componentFamily";
>>>>>>>>
>>>>>>>> Map annotationValueMap;
>>>>>>>> + String className;
>>>>>>>>
>>>>>>>
>>>>>>>> + /**
>>>>>>>> + * The renderer class (the qualified name by default).
>>>>>>>> + */
>>>>>>>> + public String getRendererClass() {
>>>>>>>> + if
>>>>>>>> (this.annotationValueMap.containsKey(RENDERER_CLASS)) {
>>>>>>>> + return (String)
>>>>>>>> this.annotationValueMap.get(RENDERER_CLASS);
>>>>>>>> + }
>>>>>>>> + return this.className;
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> /**
>>>>>>>> * The renderer type.
>>>>>>>> */
>>>>>>>> Index:
>>>>>>>> processor/src/com/sun/faces/mirror/FacesAnnotationProcessor.java
>>>>>>>> ===================================================================
>>>>>>>>
>>>>>>>> RCS file:
>>>>>>>> /cvs/woodstock/annotations/processor/src/com/sun/faces/mirror/FacesAnnotationProcessor.java,v
>>>>>>>>
>>>>>>>> retrieving revision 1.2
>>>>>>>> diff -u -r1.2 FacesAnnotationProcessor.java
>>>>>>>> ---
>>>>>>>> processor/src/com/sun/faces/mirror/FacesAnnotationProcessor.java
>>>>>>>> 9 Jun 2007 13:35:41 -0000 1.2
>>>>>>>> +++
>>>>>>>> processor/src/com/sun/faces/mirror/FacesAnnotationProcessor.java
>>>>>>>> 31 Aug 2007 21:28:08 -0000
>>>>>>>> @@ -197,6 +197,30 @@
>>>>>>>>
>>>>>>>> this.declaredComponentSet.add(componentInfo);
>>>>>>>>
>>>>>>>> this.declaredClassMap.put(typeDecl.getQualifiedName(),
>>>>>>>> componentInfo);
>>>>>>>> typeInfo = componentInfo;
>>>>>>>> + // Check to see if this annotation also
>>>>>>>> specifies a Renderer
>>>>>>>> + Object rendererClass =
>>>>>>>> annotationValueMap.get("rendererClass");
>>>>>>>> + if ((rendererClass != null)
>>>>>>>> + &&
>>>>>>>> !rendererClass.toString().equals("")) {
>>>>>>>> + // Create the "Renders" Map
>>>>>>>> + Map renders = new HashMap();
>>>>>>>> + renders.put("rendererClass",
>>>>>>>> rendererClass);
>>>>>>>> + Object type =
>>>>>>>> annotationValueMap.get("tagRendererType");
>>>>>>>> + if ((type == null) ||
>>>>>>>> type.toString().equals("")) {
>>>>>>>> + type =
>>>>>>>> annotationValueMap.get("type");
>>>>>>>> + }
>>>>>>>> + renders.put("rendererType", type);
>>>>>>>> + ArrayList families = new ArrayList();
>>>>>>>> +
>>>>>>>> families.add(annotationValueMap.get("family"));
>>>>>>>> + renders.put("componentFamily",
>>>>>>>> families);
>>>>>>>> +
>>>>>>>> + List list = new ArrayList();
>>>>>>>> + list.add(renders);
>>>>>>>> + Map rendererMap = new HashMap();
>>>>>>>> + rendererMap.put("value", list);
>>>>>>>> + DeclaredRendererInfo rendererInfo =
>>>>>>>> + new
>>>>>>>> DeclaredRendererInfo(rendererMap, (ClassDeclaration) typeDecl);
>>>>>>>> +
>>>>>>>> this.declaredRendererSet.add(rendererInfo);
>>>>>>>> + }
>>>>>>>> } else if
>>>>>>>> (typeDecl.getAnnotation(Renderer.class) != null) {
>>>>>>>> // This is a renderer class
>>>>>>>> Map<String,Object> annotationValueMap =
>>>>>>>> Index:
>>>>>>>> processor/src/com/sun/faces/mirror/generator/FacesConfig.template
>>>>>>>> ===================================================================
>>>>>>>>
>>>>>>>> RCS file:
>>>>>>>> /cvs/woodstock/annotations/processor/src/com/sun/faces/mirror/generator/FacesConfig.template,v
>>>>>>>>
>>>>>>>> retrieving revision 1.2
>>>>>>>> diff -u -r1.2 FacesConfig.template
>>>>>>>> ---
>>>>>>>> processor/src/com/sun/faces/mirror/generator/FacesConfig.template
>>>>>>>> 17 Feb 2007 23:50:09 -0000 1.2
>>>>>>>> +++
>>>>>>>> processor/src/com/sun/faces/mirror/generator/FacesConfig.template
>>>>>>>> 31 Aug 2007 21:28:08 -0000
>>>>>>>> @@ -52,7 +52,7 @@
>>>>>>>> <renderer>
>>>>>>>>
>>>>>>>> <component-family>${componentFamily}</component-family>
>>>>>>>>
>>>>>>>> <renderer-type>${rendering.rendererType}</renderer-type>
>>>>>>>> -
>>>>>>>> <renderer-class>${rendererInfo.qualifiedName}</renderer-class>
>>>>>>>> +
>>>>>>>> <renderer-class>${rendering.rendererClass}</renderer-class>
>>>>>>>> </renderer>
>>>>>>>> #end
>>>>>>>> #end
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> 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
>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_woodstock.dev.java.net
> For additional commands, e-mail: dev-help_at_woodstock.dev.java.net
>