Exactly, that would be a poor man's API :-) I'd not buy such a lib -M On Nov 29, 2007 4:22 PM, Volker Weber <[EMAIL PROTECTED]> wrote: > Hi, > > the tags for converters/validators e.g. must be in here, or the > components are not useable. > > > 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
