There are my personal opinions and solutions about each point :
On Wed, Apr 23, 2008 at 12:48 PM, Andrew Robinson <
[EMAIL PROTECTED]> wrote:
> Before I vote, I am curious to know if there has been an audit of the
> functionality compared to the maven-faces-plugin tool.
>
> I am wondering about that I can think of right now:
> 1. component, facet and property meta data extensions that live in
> faces-config.xml
faces-config.xml generation is done using a velocity template. We can add
this info to the model and then use a different template or enhancing the
actual template to put this info on the faces-config.xml. For add a property
on the model you have to take into account this points:
1. QdoxModelBuilder : retrieve the property and save it in the model.
2. XXXXMeta: add the property, setter and getter method.
3. XXXXMeta.writeXml : write the value on the XmlWriter (save model).
4. XXXXMeta.addXmlRules : add the rule, so digester can read and store it
from the model xml file.
5. XXXXMeta.merge : When the model is flattened, if this value is inherited
or not.
>
> 2. importing of code from shared meta data resources (shared
> definition of onMouseOver property for example)
This is an example of how this actually works on myfaces 1.1 generation:
/**
* @JSFComponent
* name = "h:commandButton"
* class = "javax.faces.component.html.HtmlCommandButton"
* tagClass = "org.apache.myfaces.taglib.html.HtmlCommandButtonTag"
* desc = "h:commandButton"
*/
abstract class _HtmlCommandButton
extends UICommand implements _Focus_BlurProperties,
_EventProperties, _StyleProperties, _UniversalProperties,
_AccesskeyProperty, _TabindexProperty, _AltProperty,
_Change_SelectProperties, _Disabled_ReadonlyProperties
{
public static final String COMPONENT_TYPE =
"javax.faces.HtmlCommandButton";
private static final String DEFAULT_RENDERER_TYPE =
"javax.faces.Button";
/**
* HTML: The URL of an image that renders in place of the button.
*
* @JSFProperty
*/
public abstract String getImage();
/**
* HTML: A hint to the user agent about the content type of the linked
resource.
*
* @JSFProperty
* defaultValue = "submit"
*/
public abstract String getType();
}
Each underlined interface looks like this:
interface _EventProperties
{
/**
* HTML: Script to be invoked when the element is clicked.
*
* @JSFProperty
*/
public String getOnclick();
/** ............**/
}
In this way, we have what we had with myfaces-faces-plugin (in thas plugin
we import xml property definitions using xstl), with interfaces.
The generated class does not implement this interfaces but has all
properties defined on component class and interfaces.
>
> 3. Ability to use a custom JSP tag if needed
Actually this is not implemented yet. The proposal is do something like this
(I want to generate myfaces-core.tld automatically):
/**
* @JSFJspTag
**/
public class ViewTag
extends UIComponentBodyTag
{
/**
* @JSFJspProperty
**/
public void setLocale(String locale)
{
_locale = locale;
}
}
Suggestions are welcome.
> 4. Ability to specify a custom TagHandler to use
Mojarra has a tag handler for each tag defined (the same for all), but we
can add this property.
>
> 5. Ability to generate events and event listeners
add property, but I don't know how this should looks like. The plugin is
enough flexible for do that.
>
> 6. Ability to add event type properties to components (addXListener,
> getXListeners, etc.)
add property, but I don't know how this should looks like. The plugin is
enough flexible for do that.
>
> 7. Support for validators and converters to be registered without
> manual faces-config.xml settings
Now we have this:
/**
* @JSFConverter
*/
public class ByteConverter
implements Converter{
}
We need to add a tagClass property to this and @JSFProperty related stuff.
>
> 8. Ability to have a base taglib.xml that the generator adds to
MakeConfigMojo generate what we want (one file at the time), since it is
using velocity.
With this single plugin, faces-config.xml and .tld is generated.
>
> 9. Ability to have a base TLD that the generator adds to
>
The plugin scans for templates first on the project and then inside the
plugin. no prob.
>
> People keep dogging the maven-faces-plugin and I personally don't see
> that the arguments are that compelling. Once I got over the learning
> curve I find it very easy to use and very extensible. I still am not
> sure why the wheel must be reinvented, but I am willing to try to keep
> an open mind.
>
I agree with you. I used myfaces-faces-plugin for generation on tomahawk,
and I have
enhanced the myfaces generation part of the plugin, so I know very well the
internals.
In my opinion myfaces builder plugin is a lot easier to use, but this is my
personal opinion only.
The idea is explore the possibilities, so the community can have all info to
decide.
Leonardo Uribe
> -Andrew
>
> On Wed, Apr 23, 2008 at 10:56 AM, Werner Punz <[EMAIL PROTECTED]>
> wrote:
> > [EMAIL PROTECTED] schrieb:
> >
> >
> > > Werner Punz schrieb:
> > >
> > > > +1 definitely for jsf 1.1 we need something
> > > > working and well documented.
> > > >
> > >
> > > Just to be clear: the options for the next core-1.1and tomahawk
> releases
> > > are:
> > > (a) the new myfaces-builder-plugin
> > >
> >
> > I am voting for a in this case
> > the old trinidad plugin is xml based which is an extra very verbose
> > codebase to maintain
> > and to the worse it is not documented
> > the annotations approach feels quite natural and way less verbose.
> >
> > Werner
> >
> >
>
