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