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. > 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) 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. -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
