It should also include t:saveState. Possibly t:aliasBean (havent used it myself).
Maybe verison of t:dataList (the "simple" mode) that doesn't render state? This one is more of a stretch, I expect, but an enhanced component iterator would be a good thing in commons. Are the client-side validation parts of the validators going to cause issues with a commons library, or can just the "server-side" part of the validators be in commons? I haven't looked at how this was implemented. On 5/3/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
Greetings from the ApacheCon in Amsterdam. It was discussed a lot on the list and Bernd and I are now taking the time to layout a "apache-myfaces-commons-[SUBSET]-VERSION.jar" file. Commons: -What should go into a commons JAR? Non renderKit related things like -Converters and Validators -NonFacesRequestServlet from Tobago -FacesContextFactory from Tobago to ensure a kind of common layer for doing uploads -the selectItems component from Tomahawk -what are we missing ??? Build dependencies: - Trinidad's plugins/utils to generate stuff like the TagClass file. The vision: Why this is needed ? It is kind of hard to actually use only some "common" pieces of Tomahawk. At least to add a custom validator, the complete jar is needed. The vision is also to add some "common" pieces from Trinidad/tobago to it. For Tomahawk this will not mean, you have to introduce a new namespace for adding the converter/validator, the "commons-jar" can be a rt dependency so that the TLD file is only referencing to the classes w/in the commons.jar. What are you missing ? We will compile a list into the MyFaces wiki, based on your feedback/comments -Bernd/Matthias
