myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manfred Geiler" <manfred.gei...@gmail.com>
Subject Re: Commons Jsf Utils
Date Mon, 27 Nov 2006 14:00:28 GMT
Yes, and therefore I propose to keep this new commons thingy as simple
as possible.
That means: No abstract monster classes for different component libs,
no complex component like goodies. "Shared" is responsible for the
former, tomahawk (or any other component set lib) is responsible for
the latter.

Let's start with all those simple utility methods and/or classes. You
know, those methods that tend to be implemented in convenient public
static methods.
Please have a look at UIComponentTagUtils to get a feeling which type
of utils I meant in my original proposal.

+1 for having separated commons packages (named according to the
javax.faces.* packages)

+1 for aligning the major/minor version to the jsf spec version

Manfred



On 11/27/06, Bruno Aranda <brunoaranda@gmail.com> wrote:
> IMO, instead of having different incompatible component libraries
> depending on the same abstract classes I would fight to have
> completely compatible libraries, so a component in tomahawk could be
> used everywhere instead of having different implementations of the
> same abstract class. However, I realise this is not always possible...
> But I think that adding more libraries components would confuse the
> users,
>
> Cheers,
>
> Bruno
>
> On 27/11/06, Volker Weber <weber.volker@googlemail.com> wrote:
> > Hi,
> >
> > my +1 to Bernds suggestion of having separated commons packages.
> >
> > And to move the discussion back to this thread:
> > If we want to include converters/validators and components into the
> > new "common",
> > than we need to have new TLDs with new prefixes here.
> >
> > Regards,
> >   Volker
> >
> > 2006/11/25, Bernd Bohmann <bernd.bohmann@atanion.com>:
> > > Hello,
> > >
> > > I like the proprosal of a commons package.
> > > But I would prefer more separated packages(artifacts)
> > >
> > > org.apache.myfaces.commons.util
> > > org.apache.myfaces.commons.fileupload
> > > org.apache.myfaces.commons.security
> > > org.apache.myfaces.commons.security.tiger
> > > org.apache.myfaces.commons.validator
> > > org.apache.myfaces.commons.convert
> > > org.apache.myfaces.commons.component
> > > .
> > > .
> > >
> > > I don't like commons-jsf.
> > > In my opinion myfaces is jsf we don't need a jsf in the name.
> > >
> > > We should discuss the version scheme of the commons artifacts, too.
> > >
> > > Maybe we need a
> > >
> > > Minor.major.fixpack.point scheme
> > >
> > > and the Minor.major version is equivalent to the jsf version
> > >
> > > Regards
> > >
> > >
> > > Bernd
> > >
> > >
> > >
> > > Cagatay Civici wrote:
> > > > Yes, having separate commons packages sounds good.
> > > >
> > > > Cagatay
> > > >
> > > > On 11/24/06, Martin Marinschek <martin.marinschek@gmail.com> wrote:
> > > >>
> > > >> +1 for starting off with commons
> > > >>
> > > >> +1 for your first naming suggestion
> > > >>
> > > >> regards,
> > > >>
> > > >> Martin
> > > >>
> > > >> On 11/24/06, Manfred Geiler <manfred.geiler@gmail.com> wrote:
> > > >> > Important hint, thanks!
> > > >> > My feeling is, we should have only one jsf-commons project and
resolve
> > > >> > version issues in the way springframework does support both
> > > >> > hibernate2.1 and hibernate3. They have separate packages and
only
> > > >> > optional maven dependencies.
> > > >> >
> > > >> > So we could start like this:
> > > >> >
> > > >> >  org.apache.myfaces.commons-jsf
> > > >> >  org.apache.myfaces.commons-jsf-1-1
> > > >> >  org.apache.myfaces.commons-jsf-1-2
> > > >> >
> > > >> > and have
> > > >> >  org.apache.myfaces.commons-jsf-2-0
> > > >> > and so on
> > > >> > later.
> > > >> >
> > > >> > Or alternatively:
> > > >> >  org.apache.myfaces.commons-jsf
> > > >> >  org.apache.myfaces.commons-jsf.jsf-1-1
> > > >> >  org.apache.myfaces.commons-jsf.jsf-1-2
> > > >> >
> > > >> > Or:
> > > >> >  org.apache.myfaces.commons-jsf.webapp
> > > >> >  org.apache.myfaces.commons-jsf.webapp.jsf-1-1
> > > >> >  org.apache.myfaces.commons-jsf.webapp.jsf-1-2
> > > >> >  org.apache.myfaces.commons-jsf.render.html
> > > >> >  org.apache.myfaces.commons-jsf.render.html.jsf-1-1
> > > >> >  org.apache.myfaces.commons-jsf.render.html.jsf-1-2
> > > >> >
> > > >> > WDYT?
> > > >> >
> > > >> > Manfred
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On 11/24/06, Bruno Aranda <brunoaranda@gmail.com> wrote:
> > > >> > > It seems a good idea to me. But should this commons lib
be jsf
> > > >> version
> > > >> > > independent (I mean, same jar to be used in jsf 1.1 and
jsf 1.2 or
> > > >> > > not). There are classes, like UIComponentTagUtils, which
would have a
> > > >> > > different implementation for jsf 1.1 and 1.2, but there
are other
> > > >> > > (many) classes that can work for 1.1 and 1.2 out of the
box. I would
> > > >> > > say it would be better to have a unique implementation of
> > > >> > > myfaces-commons and it should be jsf version independent...
> > > >> > >
> > > >> > > Cheers,
> > > >> > >
> > > >> > > Bruno
> > > >> > >
> > > >> > > On 24/11/06, Manfred Geiler <manfred.geiler@gmail.com>
wrote:
> > > >> > > > Hi *,
> > > >> > > > Anyone remembering the old idea of having a separate
"commons jsf
> > > >> > > > utils" project?
> > > >> > > >
> > > >> > > > Mission:
> > > >> > > > - provide utilities for JSF component developers as
well as JSF
> > > >> > > > application developers
> > > >> > > > - provide a stable API
> > > >> > > > - must not depend on a certain JSF implementation
> > > >> > > > - own release schedule independent of core and tomahawk.
Maybe
> > > >> > > > propelled by a sister project of course... ;-)
> > > >> > > >
> > > >> > > > One perfect example of a jsf-commons class I just stumbled
> > > >> across is
> > > >> > > > UIComponentTagUtils. It's the class where all those
boring
> > > >> > > > set*Property methods are implemented, that do the "if
value-binding
> > > >> > > > then... else..." things.
> > > >> > > >
> > > >> > > > Proposal:
> > > >> > > > - Initiate a new MyFaces sub-project called "commons-jsf"
> > > >> > > > (Yes! There did exist a "commons" in ancient times.
It was the
> > > >> > > > forerunner for our current "shared" project and the
reason we
> > > >> renamed
> > > >> > > > "commons" to "shared" was, that we planned to create
a REAL commons
> > > >> > > > project later. Remember?)
> > > >> > > > - We start with those obvious common jsf utils (like
> > > >> UIComponentTagUtils)
> > > >> > > > - Each (new) util class must be carefully designed
to be able to
> > > >> > > > provide a robust API
> > > >> > > >
> > > >> > > > Thoughts?
> > > >> > > >
> > > >> > > >
> > > >> > > > Manfred
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > > >> --
> > > >>
> > > >> http://www.irian.at
> > > >>
> > > >> Your JSF powerhouse -
> > > >> JSF Consulting, Development and
> > > >> Courses in English and German
> > > >>
> > > >> Professional Support for Apache MyFaces
> > > >>
> > > >
> > >
> > >
> >
>

Mime
View raw message