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