Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (herse.apache.org: domain of weber.volker@googlemail.com
 designates 64.233.162.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=googlemail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=V958B35AuOhg72wBd5fBls9wQPC7j6DMtEaDf1DgOOdvUIy7YSAsHp5WBI4BG8Vqlc+WpPLVLMgQGd/c+oPolsYHYXw3JlLPEyXV8vFFt/8Un0NAxOzwPOlV64aNykPgPv8lxK8kNzJsFoxb+gOpvPvu9+4ikpxt1US4Wt1DFCk=
Message-ID: <9a64d7d10611270558hea2309am906876863fb62d42@mail.gmail.com>
Date: Mon, 27 Nov 2006 14:58:17 +0100
From: "Volker Weber" <weber.volker@googlemail.com>
To: "MyFaces Development" <dev@myfaces.apache.org>
Subject: Re: Commons Jsf Utils
In-Reply-To: <1a681ff20611270546n41dec475sb6d7294ff8f191f5@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <564d4f680611240149n50c7af9s608b6a048b9e4d4a@mail.gmail.com>
	 <1a681ff20611240217r6b169643se412ca2de4c9eb4@mail.gmail.com>
	 <564d4f680611240229g2a46b7b9gf57ac615e3578bfb@mail.gmail.com>
	 <5a99335f0611240402i6c8b1782v2c12a6f58594a25d@mail.gmail.com>
	 <8c9d4eaa0611240406n6dfcd3dakb09530eaf75f7968@mail.gmail.com>
	 <456897CA.5030305@atanion.com>
	 <9a64d7d10611270514y47b551adm41ca5a6f00c31154@mail.gmail.com>
	 <1a681ff20611270546n41dec475sb6d7294ff8f191f5@mail.gmail.com>

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 <brunoaranda@gmail.com>:
> 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 <weber.volker@googlemail.com> 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 <bernd.bohmann@atanion.com>:
> > > 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
> > > >>
> > > >
> > >
> > >
> >
>