myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Volker Weber" <weber.vol...@googlemail.com>
Subject Re: Commons Jsf Utils
Date Mon, 27 Nov 2006 13:58:17 GMT
AFAIK tomahwk is a "html" renderkid library.
AFAIK jsf is not restricted to render html output.
Why not having renderer independend stuff in a own library to enable
use in applications which render pdf/flash/svg/or whatever
jsf-api is spitted into core and html because of this. And users have
to live with that.


2006/11/27, Bruno Aranda <brunoaranda@gmail.com>:
> 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