myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <martin.marinsc...@gmail.com>
Subject Re: Commons Jsf Utils
Date Fri, 24 Nov 2006 12:02:03 GMT
+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