You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Volker Weber <v....@inexso.de> on 2007/11/01 09:42:38 UTC

Re: [result][vote] start up the MyFaces Commons project

Hi,

see inline

2007/10/31, Manfred Geiler <ma...@gmail.com>:
> A taglib and a faces-config in the META-INF are loaded/registered
> automatically.

loading/register converters, validators, components, ... has no
inluence to the application as long they are not used. Other things
like ViewHandler, ... should not included in the faces-config as mario
wrote.

> And as I already mentioned, it should be possible to use the commons utils
> from the core impl. Automatically loading extensions(!) is not what we want
> when using the myfaces core implementation.

We have already shared for this. When introducing the shared code
there was a discussion about/against putting this into a own jar with
dependency in impl. The result was against, because is should be
possible to replace the two RI jars by just two myfaces jars.
I don't like the repackaging of shared into impl and tomahawk, but i
don't think this commons-utils should be a renamed shared?

> There is some stuff in shared that makes sense to be moved to commons utils.
> So this is not only theoretical.
>
> And don't forget about all those (renderkit-independent!) converters and
> validators. People might argue for putting them into a jsfcommons components
> artifact. What about the Joda converter that Matthias suggested? What is the
> reason it should go into Trinidad? It is not renderkit-specific or somehow
> related to Trinidad. So, a perfect candidate for jsfcommons-components,
> right?

Converters and Validators should go into the commons, as long there is
nothing of the faces-config which makes influence to a running app
just py putting this jar into classpath.


> (There would even be place for a separate jsfcommons-converters artifacts,
> IMHO)
>
> BTW, I do not understand why some of you are so scared by multiple
> jsfcommons artifacts.
> The Apache Commons Proper consists of 35 different "Components" and nobody
> cares. Quite the contrary, everybody is glad there is not only one bloated
> commons.jar when he/she needs just commons-logging or some of the DbUtils,
> right?

I'm not scared about multiple jsf-commons artifacts, i'ts perfectly ok
for me to have a jsfcommons-validators, jsfcommons-converters,
jsfcommons-components (if someone could describe what is going in
here), and so on.

I didn't know before that jsfcommons-utils was proposed as
jsf-developer utils and i don't know why we need this as replacement
for shared.
Imho the myfaces-jsf-commons should contain classes and tools for
application developers.
I have no problem in making shared a own artifact, but i don't like
the name commons-util for that.
I also don't like having validators, converters and maybe other non
components in a *-components artifact.


Regards,
    Volker


>
> --Manfred
>
>
>
> On 10/31/07, Volker Weber < v.weber@inexso.de> wrote:
> > What is the problem having a taglib in the jar?
> >
> > 2007/10/31, Manfred Geiler <ma...@gmail.com>:
> > >
> > >
> > > On 10/31/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> > > > Hi!
> > > > >
> > > > >     > which is itself an "umbrella" project for two artifacts**
> called
> > > > >     > "MyFaces JSF Commons Utils" and "MyFaces JSF Commons
> Components"
> > > > >
> > > > > I suggest that I prepare an initial setup, and check it in, so that
> > > > > there is some concrete stuff we can talk about.
> > > > > Ok?
> > > > I still don't get why we should increase the number of modules here.
> > > > Two artifacts means two jars, no?
> > >  Yes, sure.
> > >
> > >
> > > > And then, what is a Component? I think we agreed that we just want to
> > > > add render-less components, no? Else it has to go into tomahawk. The
> > > > Commons should not be just a "component-library without (the dreaded)
> > > > shared".
> > > >
> > > > Is a UrlNavigationHandler a Component then or a util? It has no
> > > > component yet, but what if it has one in the future?
> > > > I know, we then can simply just add this component to the Components,
> > > > but why should we split the stuff?
> > > >
> > > > In this case I'd have a
> > > org.apache.myfaces.commons.urlNavigationHandler
> > > > package where everything lives in.
> > > >
> > > > org.apache.myfaces.commons.urlNavigationHandler (the
> api)
> > > > org.apache.myfaces.commons.urlNavigationHandler.impl
> > > >
> org.apache.myfaces.commons.urlNavigationHandler.component
> > > > etc
> > > >
> > > >
> > >
> > >
> > >  Also renderkit independent "components" need a taglib in the META-INF
> dir.
> > > This is the main difference between a "component" and a goodie class a
> user
> > > can decide to use or not.
> > >
> > > --Manfred
> > >
> > >
> >
>
>
>
> --
>
> http://www.irian.at
> Your JSF powerhouse - JSF Consulting,
> Development and Courses in English and
> German
>
> Professional Support for Apache MyFaces