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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]> wrote: > >> > >> +1 for starting off with commons > >> > >> +1 for your first naming suggestion > >> > >> regards, > >> > >> Martin > >> > >> On 11/24/06, Manfred Geiler <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > >> > > > >
