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