On 9/18/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
> >> BTW, I'm going to take a try at moving commons valiator out of the core. > > I might need some help with the clean up. Does "shale-commons-validator" > > sound ok for the project under "framework"? > > > I'd think shale-validator would be better, unless we contemplate alternative > validation strategies. > That name would also work if we wanted to add other types of validators to the project. I almost had this done and realized that we really need to change the package names. I started moving the validator stuff out into corresponding packages but realized that that wouldn't work for "resources/Bundle.properties". What about moving these packages under "validator". shale/component shale/resource shale/taglib shale/renderer shale/faces shale/view shale/validator/component shale/validator/resource shale/validator/taglib shale/validator/renderer shale/validator/faces shale/validator/view Any thoughts?
I presume you're thinking only of moving the "validator" related classes, right? Among other things, the token component would need to stay. Doing this means a new tag library for the validator stuff (as well as its own faces-config.xml file). What do anticipate is the endgame? Would we pull the validator stuff out of the release, or try to label it as something not release quality? I'm not sure I am game for all of this ... if we're willing to label this API as not being stable, I don't see the point in doing the separation. If we are not going to ship it at all, this might be OK. But any existing users would still want the functionality available from the sandbox -- and they would probably prefer it to not require any changes. Hmm.... Craig
>> Gary > > > Craig > Gary
