It just make sure you didn't make a spelling error, and that the methods really overrides a similar method from the super class.
I'll wait until there is a real sandbox stuff to see if it makes sense to add it there.
Sylvain.
On Wed, 2005-05-11 at 15:41 -0400, Sean Schofield wrote:
Sylvain, Something like this could definitely be useful although I'm not sure where the proper home should be. I agree the EL is a bit constraining right now and I have some tricks similar to this myself. BTW, what is @Override? Never seen that before. I'm assuming its a SE5 feature? As for the specifics of your idea, we should probably discuss on a separate thread (and after we have resolved sandbox, etc.) My gut reaaction is that this would go in the "Tomahawk" (components + goodies project.) sean 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...
