myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Wessendorf" <mat...@apache.org>
Subject Re: [result][vote] start up the MyFaces Commons project
Date Thu, 29 Nov 2007 15:22:48 GMT
> > 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.

...

> These files (tags, descriptors) should go to project where components
> are to be useful at all.

Sure, there are no concrete tags in JSF-API, but from a user's
perspective, I would expect, that
a "commons.jar" (which contains converter/validator) has this:
-tags for JSP (since the JSF spec requires the support of JSP) and
Facelets (if the lib is nice)
-faces-config.xml, containing these converter's / validator.

If not, that lib would be a bit to abstract;
Like when Tomahawk (and/or Trinidad/Tobago) will *reship* those
validators, they build the tags (JSP/Faclets/what_ever).
That work is done three-times.

But... for some reason, the user has to use JSF-lib
"NameItWhatEverYouWant", but want's these COOL extra
validator/converter classes.
He needs to provide tags/cfg on his own, which is odd. Sure... the
other component-lib, could "implement" them... but... well...

I'd not "buy" such a poor solution;
It should be more convenient for users, that "just" want these extra bits

that would be to much, IMO

>
> 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 <matzew@apache.org> 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 <mario@ops.co.at> 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
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>
> >>>
> >>>
> >
> >
> >
> >
>



-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Mime
View raw message