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