myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Bohmann <bernd.bohm...@atanion.com>
Subject Re: Commons Jsf Utils
Date Sat, 25 Nov 2006 19:21:46 GMT
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