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