On Sat, Apr 26, 2008 at 2:03 PM, simon <[EMAIL PROTECTED]> wrote: > > On Fri, 2008-04-25 at 19:39 -0500, Leonardo Uribe wrote: > > > > 2008/4/25 Andrew Robinson <[EMAIL PROTECTED]>: > > Forgot to ask, this uses annotations for JSF >= 1.2 right? > > Yes. > > Well, actually it is user's choice, as both are supported. But I would > imagine that people would choose real annotations when available. > > > > > Also one more question, would Jsf* be better than JSF* for the > > names > > (ie JsfProperty vs JSFProperty)? Using all uppercase for an > > acronym in > > a java name is not conventional. Uppercase is usually reserved > > for > > starting a new, unabbreviated word. > > > > Yes, I have seen this too. The convention on xdoclet is use > > namespace.prefix. I would like to use something like this: > > > > oam.Component > > oam.Converter > > oam.Validator > > oam.RenderKit > > oam.Renderer > > oam.Property > > oam.JspProperty > > oam.JspTag > > oam.JspAttribute > > oam.Exclude > > > > or something like that. I would like to see what Simon thinks about > > this, since he proposed the names at start and I don't know if he has > > a particular reason about the choice of the tags. > > > > Simon: What do you think about this? > > I would suggest that it is nicer to have the javadoc tags and real > annotations use the same names. A class obviously cannot have "oam." in > the name. Possibly the real annotations could have the above names with > the "oam." stripped off. However in at least some cases, the result > seems a too-generic name to me. For example, @Property or @Component > aren't immediately obvious when reading the code, and may clash with > other libs (doesn't Seam have @Component already?). > > I think in Eclipse, using a dot name for a javadoc tag also makes the > spelling-checker mark the name as a spelling mistake, which is mildly > annoying. > > If people want JsfComponent rather than JSFComponent, I'm ok with that. > But Sun went to the effort of actually deprecating getUrl() in favour of > getURL(), so presumably the all-caps-for-acronyms is a java convention. > > Looking the java api there is a lot of classes that when use an acronym at start, it put all upercase like this classes:
RMIConnector<file:///C:/jdk-1_5_0-doc/docs/api/javax/management/remote/rmi/RMIConnector.html> RMISecurityException<file:///C:/jdk-1_5_0-doc/docs/api/java/rmi/RMISecurityException.html> AWTEventMulticaster<file:///C:/jdk-1_5_0-doc/docs/api/java/awt/AWTEventMulticaster.html> POAHelper<file:///C:/jdk-1_5_0-doc/docs/api/org/omg/PortableServer/POAHelper.html> SQLException <file:///C:/jdk-1_5_0-doc/docs/api/java/sql/SQLException.html> URLEncoder <file:///C:/jdk-1_5_0-doc/docs/api/java/net/URLEncoder.html> So if we want that Doclets looks like annotations, the best is let the convention as is. Thanks Simon for make clear this point. regards Leonardo Uribe > > > > > On myfaces 1.2 maybe annotations could not be used, because maybe it > > breaks the TCK, but I'm not tested this yet, so its a point to take > > into account. The actual code allows to use annotations and doclets > > (we need to update annotation classes). > > I think it *very* unlikely that annotations would conflict with the TCK. > These are source-retention annotations only, ie have absolutely no > effect on the generated .class files. > > So if this plugin is used with myfaces 1.2.x, I would recommend real > annotations be used and not doclet tags. > > Note that using qdox to scan source for annotations is actually *easier* > than using APT for it, for several reasons. The APT tool is really ugly > to use. So there is no reason to think of the myfaces-builder-plugin as > having a "legacy" architecture just because it also supports doclet > tags. > > Regards, > Simon > > >
