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
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
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
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
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
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
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
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
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:
+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
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
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:
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
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
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:
15 matches
Mail list logo