Hi,
Matthias Wessendorf napsal(a):
Exactly,
that would be a poor man's API :-)
shouldn't API stand for "Abstract Programming Interface" in JSF way? (i
know it's Application)
I'd not buy such a lib
Why then not going the JSF spec way - API and IMPL?
API for fundamental parts, IMPL for it's real-world use (as of today)
And little extend that way - making those two downloadable as only API
or together - users then can choose if they want the "whole thing" or
just foundation from API.
That way we can really consider it 'commons' - not having ANY specific
requirement on users' targetted language.
Zdenek
-M
On Nov 29, 2007 4:22 PM, Volker Weber <[EMAIL PROTECTED]> wrote:
Hi,
the tags for converters/validators e.g. must be in here, or the
components are not useable.
I should have made myself little clearer - i was speaking of components,
not converters/validators.
Regards,
Volker
2007/11/29, Sochor Zdeněk <[EMAIL PROTECTED]>:
Hi,
Matthias Wessendorf napsal(a):
sure, no dependency to -impl.
Wouldn't make sense, if there were.
Convertors and validators are quite different matter - they should get
into 'commons' BUT if and only if they use only crucial attributes from
(server-side) converters and (server-side) validators, are really
reusable "components",
so they need to be in that *commons* thing.
That was only note from me - not using converters/validators coupled
with render kit's outcome language (like escaping special characters).
components (see above) and NOT specific tag attributes from ANY language.
not sure, what this means. Does it mean, that such a "commons.jar"
(not a final name!)
doesn't (or shouldn't contain) tags ? (for JSP / Facelets)
I think it should contain tags for:
-jsp (that guy is default in JSF spec)
-facelets (that guy is more and more used)
There are NO tags in JSF API (they are ALL in impl), so they don't have
a foundation to be built upon.
If a user of "commons.jar" needs to create TAGs or facelets.xml file,
the user would be a very! poor guy.
Would make they kind of useless, IMO.
These files (tags, descriptors) should go to project where components
are to be useful at all.
Zdenek
-Matthias
Utility classes - only small potion of them are really without any
references to render kit (either direct or indirect through components).
Having convenient classes for working in either backing beans and/or
developing new components in 'commons' would be ...convenient. :D
With regards,
Zdenek
Matthias Wessendorf napsal(a):
The stuff we have (or plan to have) and we need places for are:
1. "renderkit independent stuff" - converters, validators, ... (BTW,
are they really renderkit independent? What about client-side
validation?!)
let me write a wiki page for that + discussion in a separate thread.
-M
2. convenient utils, helpers and base classes for component developers
3. convenient backing(!) bean utils and helpers for jsf application
developers (ie "users")
4. some things in "myfaces-shared" that should not be there (BTW, I
have concrete plans on refactoring shared, but first I need a place
where I can move some stuff to)
5. ???
Let's try to agree on these different categories. After that we try to
find the proper place and name(!) for each item? Okay?
See inline as well -->
-- Manfred
On 11/29/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
Do we really want component like stuff like converters and validators there?
Didn't we discuss this already?
Yes we had discuss this, but it seems we did not reach agreement.
I think we need a own project for converters/validators/other stuff
for application-development
which should not include renderkid/jsf-impl dependend stuff.
+1
that was my real motivation for creating a "commons".
I really don't care on a "coolBackingBean". Utils might be
the better wording for that.
Aren't commons modules as we know it all "utilities" in some sense? ;-)
An i think this one was meant by Matthias and Bernd.
I think so :-)
If we need jar supporting component-developer we should stop the
repackaging of shared, create a shared.jar and add the dependency
instead to impl and tomahwak.
Yes, that's what I want to try. But "shared" is no proper name for
stuff that could be used by "independent" component developers. The
name "shared" means: this is internal code *shared* by some MyFaces
subprojects. Therefore we need a better place: "jsfcommons-???"
that would easy the debugging as well.
why? If you have both sources for api and impl jar in your IDE there
is no difference.
Perhaps we need "stricter" rules for API stability for that.
One major pain was that upgrade from tom1.1.2 to 1.1.3 wasn't possible, because
the whole shared messed up the migration.
(Just my thoughts)
Regards,
Volker
I thought we agreed on not starting yet another jsf component lib.
What is wrong with having convenient converters and validators in
tomahawk? Where they are right now!
Is it because tomahawk has some flaws and maybe have sideeffects on
other component libs? If yes, we have to FIX tomahawk and not turn
around and start a new (better?) project.
My original idea of a jsfcommons project is/was:
- convenient utils, helpers and base classes for component developers
- convenient backing(!) bean utils and helpers for jsf application
developers (ie "users")
What jsfcommons should NOT be:
- a convenient haven for simple components or component like stuff,
that is put there for "strategic" reasons
A need for a "jsfcommons-faces-config.xml" is a definite sign, that we
would start off in the wrong direction. We would start yet another jsf
component lib. That is the main reason I warned of having a
faces-config.xml in jsfcommons in former discussed. It was not only
for technical reasons.
--Manfred
On 11/29/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Hi!
I don't think a separation between api and impl jars is useful.
I second that. For the same reasons. It makes things unnecessary
complicated ....
To ensure api stability community review should be enough - and then
there is a maven plugin for that, no?
BTW: I thought we agreed on a structure like
myfaces-jsfcommons-converters
myfaces-jsfcommons-validators
...
Also overly complex, but something I can learn to understand ....
Lets reiterate: I prefer to start with a simple jsfcommons project where
we have no faces-config.xml (at least not in a place where JSF loads it
automatically).
Providing a jsfcommons-faces-config.xml which the user has to add to the
configuration will avoid any side-effect when dropping in our jsfcommons
jar. It also allows to selectively active things as the users can change
their own configuration as required.
Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox
for myfaces land at all. Lets promote the tomahawk-sandbox one level
higher - thats it.
Ciao,
Mario
