Re: Commons Jsf Utils

2006-11-27 Thread Volker Weber
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

Re: Commons Jsf Utils

2006-11-27 Thread Bruno Aranda
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

Re: Commons Jsf Utils

2006-11-27 Thread Volker Weber
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

Re: Commons Jsf Utils

2006-11-27 Thread Manfred Geiler
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

Re: Commons Jsf Utils

2006-11-25 Thread Bernd Bohmann
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

Re: Commons Jsf Utils

2006-11-24 Thread Matthias Wessendorf
I'd also like to see a jar for renderkit independent stuff, like converter/validators -M On 11/24/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

Re: Commons Jsf Utils

2006-11-24 Thread Bruno Aranda
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

Re: Commons Jsf Utils

2006-11-24 Thread Werner Punz
Matthias Wessendorf schrieb: I'd also like to see a jar for renderkit independent stuff, like converter/validators One of the big issues we have is how we handle all the common javascript stuff. For now we have the dojo lib in tomahawk, but the Tobago guys want to start to use it as well. I

Re: Commons Jsf Utils

2006-11-24 Thread Manfred Geiler
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:

Re: Commons Jsf Utils

2006-11-24 Thread Martin Marinschek
+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

Re: Commons Jsf Utils

2006-11-24 Thread Cagatay Civici
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

RE: Commons Jsf Utils

2006-11-24 Thread Jesse Alexander \(KSFD 121\)
Does it make sense to coordinate together with SUN... as you define the goal must not depend on a certain JSF implementation regards Alexander -Original Message- From: Manfred Geiler [mailto:[EMAIL PROTECTED] Sent: Friday, November 24, 2006 10:50 AM To: MyFaces Development Subject:

Re: Commons Jsf Utils

2006-11-24 Thread Matthias Wessendorf
I don't mind Bruno/Manfredo meant more myfaces-versions independent and independent from org.apache.myfaces.impl code (at least I got it that way) -M On 11/24/06, Jesse Alexander (KSFD 121) [EMAIL PROTECTED] wrote: Does it make sense to coordinate together with SUN... as you define the goal

Re: Commons Jsf Utils

2006-11-24 Thread Manfred Geiler
Yes, that was the intention: Independent of any other myfaces lib. Depending only on specified javax.faces.* classes, which means it is running on top of either myfaces-api or SUN's jsf-api. We are speaking of utils. No need to coordinate with SUN in my opinion. However, if an util class gets

Re: Commons Jsf Utils

2006-11-24 Thread Ole Ersoy
Sounds really useful. Especially for classes like the ones John Fallows and Jonas Jacobi developed in their book to support resource loading, etc. --- Manfred Geiler [EMAIL PROTECTED] wrote: Hi *, Anyone remembering the old idea of having a separate commons jsf utils project? Mission: