Hi,
just my few ideas about this ;)
What about reversing the flow by answering the 'simple question':
What code is specific to render kit?
By answering this question we can really begin discussion about the
way of putting remaining classes to so called 'commons'.
-----
My current view of 'commons' contents:
From start we should agree only that we have only 1 starting base
dependancy - JSF API (not impl!) and even that with restriction - not
components in .html package.
As of today, almost all components from libraries by their tight
coupling with tags are disqualified for getting into 'commons'.
The main reason for my thinking is not using any generic means of
manipulating arbitrary attributes.
IMO whole path of JSF components implementation (either RI of MF)
diverted from 1st vision of using Map of attributes (see
_ComponentAttributesMap class) WITHOUT using getter/setter specific to
the attribute in the component's code.
If implementation was based solely on using Map, some components WOULD
make it to 'commons' if:
1. they had NO dependency on anything beside JSF API (base
components, NOT html ones) and classes in 'commons'
2. they declared crucial attributes from Map they work with to be
functional (in the simpliest form)
Not to mention that adding new attributes would be almost painless -
just matter of adding them to tags (which would NOT be in 'commons') and
tweaking renderrers (also NOT in 'commons').
Tag related stuff should be seen as outlaws for 'commons', because
they depend on render kits - when i hear (or read :D ) word TAG i'm
immediatly thinking of CONCRETE language.
Convertors and validators are quite different matter - they should get
into 'commons' BUT if and only if they use only crucial attributes from
components (see above) and NOT specific tag attributes from ANY language.
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
