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.
I was ONLY speaking here about converters/validators. API (containing the validators/converters) AND! and IMPL (containing the TAGs) *might* be a solution, but IMO that is a little bit overhead. -Matthias > > >> 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 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >>>> > > > > > > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
