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 <[EMAIL PROTECTED]> 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 <[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 > > >> > > > > > > > >
