But if you call it myfaces basics, or myfaces components aren't you then at
least sending the message that this is myfaces impl specific?.
>From following the thread here I was under the impression that the
components for this common project would be usable, like the apache commons,
in JSF projects. Not just myfaces specific, but general jsf projects. At
work we use tomahawk 1.1.5 for example, but I have done several projects
where the sun implementation was used instead of the myfaces one (don't ask
me why, just repeat "office politics" a few times). This kind of cross usage
was what I was expecting in the commons project we are talking about here.
Ron Smits
On 10/27/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
>
> Also, just as another side note, other than requests for programming
> apis to make JSF AJAX easier, I don't really recall end-users asking
> for convenience JSF programming APIs. Most of those who talk about
> it are already using them in Tomahawk as Tomahawk committers.
>
> But there have been a number of end-users asking for the ability to
> use t:saveState or validators or converters from Tomahawk (and
> t:dataList, although no one is interested in the html-rendering
> functionality of this component, just the enhanced repeat loop it
> provides). This is why we're proposing it.
>
> And since I see that I didn't directly answer your comment on "MyFaces
> Base Components", I'm ok with that name instead of MyFaces Commons :-)
>
> In fact, I think maybe "MyFaces Basics" makes even more sense.
>
>
> On 10/27/07, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> > Yes, we need to be careful about what goes in. And we should agree on
> > some rules here. Is lazy consensus enough? Or should every addition
> > require an official vote (on a regarding jira issue)?
> >
> > Mike, the original intention of the jsf commons project was a
> > collection of useful jsf stuff (helpers and utilities) that is
> > convenient for component and application (and jsf implementation)
> > developers. This includes renderkit (html) specific stuff. There is no
> > harm in html specific stuff as long as it is really useful for many
> > people and it is located in a clearly separated java package.
> >
> > Having common (renderkit independent) "components" was not the primary
> > goal AFAIR. I'd rather see these in another new project: something
> > like "MyFaces Base Components"
> >
> > WDYT?
> >
> > --Manfred
> >
> >
> >
> > On 10/27/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > > I think we're starting to confuse the focus here.
> > >
> > > There's a difference between common components that can be used with
> > > any JSF project, and common programming utilities, many of which may
> > > be renderkit (like html) specific.
> > >
> > > I'm ok with common programming utilities being in this project, but
> > > we're going to need to be careful regarding what we put into it. But
> > > we do need to be careful about what goes in it.
> > >
> > > On 10/27/07, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> > > > +1
> > > >
> > > > But to avoid common design mistakes I propose some additional
> > > > issues/prerequisites:
> > > >
> > > > 1. Clear separation of API and IMPL (at least on package level,
> better
> > > > by separate artifacts). Mind that the idea behind these commons
> > > > classes is that many other projects use them - and therefore depend
> on
> > > > them. So a clear and stable API is essential.
> > > >
> > > > 2. Let's start to name svn folders the same as the artifacts. This
> > > > seems to be best practice in many other maven projects. And there
> are
> > > > good reasons to do this.
> > > > So, the new project should be located in a folder named like
> > > > "myfaces-commons" with two sub folders "myfaces-commons-api" and
> > > > "myfaces-commons-impl".
> > > >
> > > > BTW, some other candidates for commons classes are "trivial" utils
> > > > like this one:
> > > > public static void doNavigation(String outcome) {
> > > > FacesContext facesContext = FacesContext.getCurrentInstance
> ();
> > > > NavigationHandler navigationHandler =
> > > > facesContext.getApplication().getNavigationHandler();
> > > > navigationHandler.handleNavigation(facesContext, null,
> outcome);
> > > > }
> > > >
> > > > Yes, no big deal. But convenient, though, to have this code in one
> > > > good place instead of inventing a new "JSFUtils" class for every new
> > > > customer project... ;-)
> > > >
> > > >
> > > > -Manfred
> > > >
> > > >
> > > >
> > > > On 10/24/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> > > > > Hi!
> > > > >
> > > > > Lets start up the long awaited MyFaces Commons project.
> > > > >
> > > > > The aim of this project will be to contain all stuff which do not
> belong
> > > > > to a component.
> > > > >
> > > > > [ ] +1 yea, lets start
> > > > > [ ] +0
> > > > > [ ] -1 no, for those reasons .....
> > > > >
> > > > >
> > > > > I'll do the maven work then (a not very sophisticated one, just
> copy it
> > > > > from another of our modules)
> > > > >
> > > > > Ciao,
> > > > > Mario
> > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > http://www.irian.at
> > Your JSF powerhouse - JSF Consulting,
> > Development and Courses in English and
> > German
> >
> > Professional Support for Apache MyFaces
> >
>
--
I reject your reality and substitute my own
--- Adam Savage, the mythbusters
