Because it makes things more complicated. We've got enough on our
plate now. At some point when J2SE 5.0 becomes the standard we will
switch to it.
sean
On 9/7/05, Nadeem Bitar <[EMAIL PROTECTED]> wrote:
> 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...
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
>
>
