On Sun, Jun 15, 2008 at 2:51 PM, simon <[EMAIL PROTECTED]> wrote:
> Hi Leonardo,
>
> Ok, I've finally figured out where some of the confusion between us is
> coming from re parent/superClass etc (and classSource, which had me very
> puzzled today). The issue is about what exactly a ComponentMeta instance
> models. It can:
> (a) model the classes that were annotated.
> (b) model the classes that will exist after code generation.
> I was expecting (a) but (b) is what has been implemented. Hence the
> confusion.
>
> I've added a unit test to make it easy to see exactly what does happen
> (see recent commit) [1].
>
> For the simple cases (base classes or interfaces that are not
> components, or hand-written components) these two things are of course
> the same. However they are different once code-generation is considered.
>
> Without "template mode" component generation, I think (a) is better. But
> approach (a) doesn't allow other projects to extend components generated
> using "template mode" component generation (because the actual class
> might not be public). So (b) is needed.
>
> Or we could use approach (c) and model both. I actually like this idea
> quite a lot. A class that is annotated in a way that triggers
> code-generation would create TWO ComponentMeta objects: one for itself,
> and one for the class to be generated. I think that would make things
> much clearer...
>
I don't know if this concept could break some functionality, specially when
you think on what happen
when the plugin merge components (one is the parent of other), and the
generation of tag classes (the
plugin set automatically properties that comes from parent and avoid
generation. I don't have
objections if the change does not affect the current generation (the test is
save actual generated code,
modify, genererate and see if some difference appear with a diff tool).
>
> [1] This unit test seems to have also found a bug in the creation of the
> "parent" field, which currently looks like ".Foo" rather than
> "packagename.Foo".
>
I can see the problem. The solution could be use:
public class Bar extends packagename.Foo
I did this on UISchedule (for remove parent property) and works fine.
QdoxModelBuilder sometimes
does not extract properly the full name, if the file is not included
(sometimes fails).
>
> Regards,
> Simon
>
>
> >
> >
> > In Tomahawk, class AbstractHtmlDataScroller has these
> > annotations:
> > * @JSFJspProperty name = "onkeydown" tagExcluded = "true"
> > * @JSFJspProperty name = "onkeypress" tagExcluded = "true"
> > * @JSFJspProperty name = "onkeyup" tagExcluded = "true"
> > * @JSFJspProperty name = "onmousedown" tagExcluded = "true"
> > * @JSFJspProperty name = "onmousemove" tagExcluded = "true"
> > * @JSFJspProperty name = "onmouseout" tagExcluded = "true"
> > * @JSFJspProperty name = "onmouseover" tagExcluded = "true"
> > * @JSFJspProperty name = "onmouseup" tagExcluded = "true"
> >
> > I can't currently figure out what these are for. These
> > properties are in
> > the Attributes map, so they don't need to be referenced in
> > saveState/restoreState. And because tagExcluded is true, they
> > are not
> > written into the tld.
> >
> > So what do these annotations do?
> >
> >
> > This annotations remove from the tld this properties, because there
> > are not provided by the renderer, but inherited from
> > org.apache.myfaces.component.html.ext.HtmlPanelGroup.
>
> Ah. I didn't see those annotations because I followed the "extends" link
> in my IDE, which took me to the generated class not the template class.
> And only the template class has the annotations on it.
>
> I've updated componentClass11.vm to output the original sourceCource as
> a comment on generated classes so it's easy to find the template class.
>
Good, Theorically, myfaces-builder plugin should use tomahawk core and
core12 velocity
templates as default templates (actually the default templates are never
used).
The idea is create an archetype to allow people start coding components with
myfaces-builder-plugin easily.
>
> > Solutions?
> >
> > 1. Use the same pattern as rendered property for UISelectItem
> > 2. Implement this properties on the renderer.
>
> I think that this is just another case of broken OO hierarchy. I see no
> reason why a DataScroller should subclass HtmlPanelGroup. If it used a
> more appropriate parent class there would be no problem.
>
> For the moment, I guess we can leave things as they are. Later we can
> try to fix the OO hierarchy appropriately.
>
+1
>
> >
> >
> > >
> > > == tagExcluded
> > >
> > > I'm also trying to figure out exactly what
> > "tagExcluded=true"
> > > means on
> > > JSFJspProperty, and whether we can get rid of it.
> >
> > >
> >
> > > Really, id, binding and renderer are the only properties
> > that
> > > sometimes uses extensively
> > > @JSFJspProperty tagExcluded=true, because override it could
> > cause
> > > problems or be imposible (binding)
> >
> >
> > As you've probably seen, I've defined getter/setter methods
> > for id and
> > rendered on the relevant classes, and used
> > @JSFProperty tagExcluded=true
> > on them.
> >
> > Yeap, I see the changes on myfaces api 1.1 and 1.2 yesterday. There is
> > a probem with some tomahawk component that extends from UISelectItem
> > and use rendered property (obviously throw Unsupported....., but the
> > solution is very easy.
>
> Is this just a theoretical problem, or is there really a component that
> does this?
>
The test that fails is this:
myfaces-example-simple/panelnavigation_2.jsf
The stack trace is this:
Caused by: java.lang.UnsupportedOperationException
at javax.faces.component.UISelectItem.setRendered(UISelectItem.java:79)
at
org.apache.myfaces.custom.navmenu.htmlnavmenu.HtmlNavigationMenuRenderer.addUINavigationMenuItems(HtmlNavigationMenuRenderer.java:291)
at
org.apache.myfaces.custom.navmenu.htmlnavmenu.HtmlNavigationMenuRenderer.preprocessNavigationItems(HtmlNavigationMenuRenderer.java:267)
at
org.apache.myfaces.custom.navmenu.htmlnavmenu.HtmlNavigationMenuRenderer.encodeEnd(HtmlNavigationMenuRenderer.java:129)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:762)
We also have problems with UIViewRoot (see MYFACES-1881). For MYFACES-1881
in my opinion the best is do not touch UIComponentClassicTagBase. For
UINavigationMenuItems the best is custom redefinition of rendered property.
But I want to hear your opinion before take any decision.
regards
Leonardo Uribe
>
> Regards,
> Simon
> >
>
>
