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