Why not have a separate module for jdk 5.0 stuff? The Spring framework
and acegi security both build things differently depending on the
detected jdk allowing the project to take advantage of jdk 5.0 features
without penalizing the people stuck with older jdks.
Nadeem
On Tue, 2005-09-06 at 18:38 -0400, Sylvain Vieujot wrote:
> Well doing a branch for the few classes I have right now really isn't
> worth it.
>
> Maybe it's better to hold on this until we start JSF 1.2.
>
> On Wed, 2005-09-07 at 00:21 +0200, Bruno Aranda wrote:
> > I do not thing that including JDK5.0 code in the sandbox and not in
> > the rest is a good idea. It might create confusion... maybe we could
> > add a JDK5.0 branch to the sandbox SVN tree and then we would keep
> > your need code, but, IMO valid JDK1.4 code should be everywhere...
> >
> > Bruno
> >
> > P.S Currently, I am developing all my projects in JDK5.0. I have to
> > think twice when programming for myfaces! ;-)
> >
> > 2005/9/7, Sylvain Vieujot <[EMAIL PROTECTED]>:
> > > I didn't mean to include it in the sandbox and hope to refactor it later.
> > > I meant to add it to the sandbox, and to move it to tomahawk only when we
> > > accept JSE5 code in tomahawk (which is required for JSF 1.2 if I'm not
> > > wrong).
> > > The point is that be refactoring those classes, we lose a lot of safety,
> > > so
> > > I would prefer to either commit them to the sandbox if we accept JSE5 code
> > > into it, or just hold them until we do.
> > >
> > > It's not crucial anyway, as those cases are still limited right now.
> > >
> > >
> > > On Tue, 2005-09-06 at 17:34 -0400, Sean Schofield wrote:
> > > IMO that's a bad idea. Why would you add it with JSE 5 to the sandbox
> > > but chance it to 1.4 when moving to tomahawk? What would be the point
> > > of that?
> > > Why not refactor before adding to sandbox if this is the eventual plan?
> > >
> > > I'm not sure how I feel about requiring JSE 5 (I don't use it myself)
> > > but I definitely don't think we should add stuff and hope to refactor
> > > it later.
> > >
> > > sean
> > >
> > > On 9/6/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> > > > Hello,
> > > >
> > > > I was about to commit the few Maps util classes I have when I realized
> > > it's
> > > > all Java 5 code (with many generics and a few annotations).
> > > > Removing the generics would really be bad as those classes needs to be
> > > > extended, and the generics add a lot of safety.
> > > >
> > > > For me it would be ok to add Java 5, and later to move it to tomahawk
> > > > when
> > > > we move to JSF 1.2, but I would need the approval of the others to do
> > > that,
> > > > as it would break the sandbox compilation on Java 1.4.
> > > >
> > > > What do you think ?
> > > >
> > > > Sylvain.
> > > >
> > > > On Tue, 2005-09-06 at 13:09 +0200, Martin Marinschek wrote:
> > > > Yes...
> > > >
> > > > Let's put it there, and go on from this!
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 9/6/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> > > > > Hello Martin,
> > > > >
> > > > > No, I never committed it.
> > > > > I think a new package would be great, but where do you want to put it
> > > > > ?
> > > > > The logic would be to have it first in the sandbox, and then move it
> > > class
> > > > > by class tomahawk.
> > > > >
> > > > > Maybe a better package name would be org.apache.myfaces.utils
> > > > > as jsfutils is redundant with myfaces. I also dropped the tomahawk
> > > > > part
> > > as
> > > > > it would be in the sandbox first, but I'm not sure about this.
> > > > >
> > > > > If you agree, I can commit those classes to the sandbox's
> > > > > org.apache.myfaces.utils package, and we can start from here.
> > > > >
> > > > > Sylvain.
> > > > >
> > > > >
> > > > > On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
> > > > > Sylvain,
> > > > >
> > > > > did you ever get around to commit this stuff? I didn't find it in the
> > > > > sources...
> > > > >
> > > > > I'd like to use that as an example for something I am writing on -
> > > > > would be great if I could just point to the MyFaces sourcebase.
> > > > >
> > > > > How about a new package
> > > > >
> > > > > org apache myfaces tomahawk jsfutils
> > > > >
> > > > > We could also have the user contributions like the message-remembering
> > > > > facilities and the newly added remember request-bean over redirect
> > > > > facilities there...
> > > > >
> > > > > regards,
> > > > >
> > > > > Martin
> > > > >
> > > > > On 5/11/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> > > > > > I'm fine with that and find it simpler to have it in the trunk.
> > > > > >
> > > > > > I have a related question.
> > > > > >
> > > > > > Right now, I have done 2 little utilities that help me resolve small
> > > > > > problems.
> > > > > > They are 2 abstract implementations of Map : ActionMap and TestMap,
> > > and
> > > > I
> > > > > > find them handy to use in many common cases.
> > > > > >
> > > > > > Here are 2 examples :
> > > > > > 1) ActionMap : For example, when you have a list of file, and want
> > > > > > to
> > > > have
> > > > > > a checkbox to delete a file, you just add the following code in your
> > > > page
> > > > > :
> > > > > > <h:column>
> > > > > > <h:selectBooleanCheckbox
> > > value="#{pageFace.removeFileName[file.name]}"/>
> > > > > > <h:outputText value="delete"/>
> > > > > > </h:column>
> > > > > >
> > > > > >
> > > > > > And in your backing bean : public ActionsMap getRemoveFileName(){
> > > > > > return new ActionsMap(){
> > > > > > @Override
> > > > > > public void performAction(String fileName) {
> > > > > > getFiles().remove( fileName );
> > > > > > }
> > > > > > };
> > > > > > }
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2) TestMap : I use it to pass parameters to methods using a map, and
> > > > > > getting a boolean result.
> > > > > > For example, if you want to render a component if a user is in 2
> > > roles,
> > > > > the
> > > > > > visibleOnUserRole isn't enough.
> > > > > > So, in my backing bean, I have this method :
> > > > > >
> > > > > > public TestsMap getUserInRole(){
> > > > > > return new TestsMap(){
> > > > > > @Override
> > > > > > public boolean getTest(String roleName) {
> > > > > > return getHttpServletRequest().isUserInRole( roleName
> > > > );
> > > > > > }
> > > > > > };
> > > > > > }
> > > > > >
> > > > > > And now, I can do any test I want in EL :
> > > > > > #{myBean.isUserInRole['Accountant'] &&
> > > > myBean.isUserInRole['CountryUnit']}
> > > > > >
> > > > > > It's quite limited now, but due to the limitations of the EL, small
> > > > > > utilities like that can help.
> > > > > > My suggestion is to do a utilities library (similar to commons.lang,
> > > > with
> > > > > > StringUtils, ...) for EL, and maybe for JSF if more good candidates
> > > > > emerge.
> > > > > >
> > > > > > So, I wonder first if you guys feels this is of any use to include
> > > this
> > > > in
> > > > > > MyFaces, and if so, how do we handle that ?
> > > > > > Those aren't components, but should we do a sandbox for libraries
> > > > > > to,
> > > or
> > > > > > just an additional myfaces-utilities.jar ????
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Sylvain.
> > > > > >
> > > > > >
> > > > > > On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
> > > > > >
> > > > > > I recall correctly, the consensus was to have a "sandbox
> > > > > > subproject"
> > > > > > for new components. I would like to propose a simpler solution: Why
> > > not
> > > > > > have the sandbox as a subdirectory of the existing project. Then we
> > > can
> > > > > > just specify all "s:" components as sandbox components until they
> > > > > > are
> > > > > > completely accepted by the community. At that time they can become
> > > "x:"
> > > > > > components.
> > > > > >
> > > > > > Would this satisfy the ASF's requirement for "All New Components
> > > > > > Must
> > > Go
> > > > > > Through the Incubator" ? Hopefully...
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
