I think I said in every email response that
I don't think this is appropriate in the annotation processor that is
used by the Woodstock components.
-rick
Ken Paulsen wrote:
>
> Rick, Greg,
>
> Is it OK for me to check this in (w/ the fix to avoid the interface
> change)? Or do you think it is an inappropriate change?
>
> Thanks,
>
> Ken
>
> Ken Paulsen wrote:
>
>>
>> Hi Rick,
>>
>> I understand your point now (I was starting to get it by the end of
>> my last response), you are right. Technically there is no difference
>> in what JSF does... and it would still be possible to override the
>> implicit renderer behavior that the UIComponent provides. All is
>> good (or even arguably better) on the surface.
>>
>> However, this goes in a direction I'm trying to move away from.
>> Right now I do have a set of TemplateComponent base classes that the
>> component author needs to chose from to extend (i.e. an EVH-based
>> one, ActionSource, container, etc.). These base classes do almost
>> nothing right now... they provide a couple methods that really should
>> be utility methods in a different class, and 1 important property:
>> the name of the template to use. I have been considering making this
>> property simply an attribute in the component attribute Map and
>> thereby allowing ANY UIComponent to work w/ the TemplateRenderer.
>>
>> If I add more functionality to the base class (the logic to check for
>> a faces-config.xml-defined Renderer, if not found perform its own
>> Rendering)... then it is more difficult to allow any UIComponent to
>> work. I suppose I could put this logic in a different file and just
>> require the UIComponent to delegate to this code. However, as you
>> can see this isn't as elegant from a UIComponent-developers
>> point-of-view.
>>
>> This is what I'd like to (eventually) make possible:
>>
>> MyComponent.java:
>>
>> @Component(...)
>> public class MyComponent extends UIInput {
>> public MyComponent() {
>> getAttributes().put("templateFile",
>> "templates/myComponent.jsf");
>> }
>>
>> ...
>> }
>>
>> And:
>>
>> myComponent.jsf:
>>
>> <span id="#{component.clientId}">component content</span>
>>
>> And that's all. They should then be able to compile and run it. The
>> necessary faces-config.xml, taglib, and other file stuff should be
>> generated during the build.
>>
>> I supposed I could have the @annotations create the necessary java
>> base-class code for them so they could still do the above code and
>> have it work... but I'm not trying to find every way to solve this.
>> I have a way done already. I just need 1 additional property on the
>> @Component attribute so that the generated faces-config.xml file
>> entry can be complete.
>>
>> I'm willing to consider other options in the future, but I'd like to
>> get this change in so that it works today. This change doesn't
>> impact any existing component in any way, and doesn't require any
>> change to current or future Woodstock components -- it just helps me
>> do what I'm trying to do.
>>
>> Ken
>>
>>
>> richard ratta wrote:
>>
>>> 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.
>>>
>> Yes.
>>
>>>> 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?
>>>
>>>
>>>
>>>
>>> -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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>