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