> > 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 <[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 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>> > >>> > >>> > > > > > > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
