Yes, but your wrapping validator doesn't have the ability to save the state of the wrapped validator, does it? Sorry. I really don't remember the details, but I would expect Myfaces 1.1.x to still have the same problem. Perhaps we were just doing it wrong back then, though :-)
The process would be to discuss it here on the dev list (which you are doing) and get feedback, then at some point open a JIRA issue and attach a patch to provide your contribution. The MyFaces developers would be the collective judge of any decision. I'd say there's no reason why we wouldn't accept this contribution since it's frequently-asked-for functionality and the implementation seems to fit with JSF architecture easily enough. On 10/24/07, Val <[EMAIL PROTECTED]> wrote: > > Well, it's been two-and-a-half years, but I seem to remember the > > problem was that under JSF 1.1 + jsp, the converters and validators > > are created from scratch every request rather than restored using the > > JSF state-saving mechanism. So all of the values set on the > > converters/validators would be lost the next request. > Hmm, I am using MyFaces 1.1.3. That's JSF 1.1, right? The code in > UIInput explicitly calls saveAttachedState() on the validators and > converter, so I guess that problem was fixed. > > > In fact, it might fit in with the newly-proposed (earlier > > today) MyFaces Commons project better since it doesn't seem to be > > dependent on any particular renderkit. > ooh, nice - I like the idea of a commons project. And yeah, that looks > like the place where my framework could fit into. > > So, now my ignorance of the Apache development process comes into play > again. Assuming that this change would be welcome in the MyFaces Commons > project (who would be the judge of that, btw?), what do I need to do to > get it there? Since I am not a regular contributor, I suspect I can't > just check it in :), so what is the proper process? > > Thanks. > > > Val > > > On Wed, 2007-24-10 at 15:54 -0400, Mike Kienenberger wrote: > > On 10/24/07, Val <[EMAIL PROTECTED]> wrote: > > > I handled the addition of a converter or validators into the wrapper by > > > having my custom tag push a dummy UIInput tag onto the tag stack that > > > UIComponentTag uses and then having the wrapped converter/validators set > > > themselves up in the dummy component on the top of the stack as they > > > usually do (no changes there). Then when we come back up to the > > > doEndTag() of my wrapper custom tag, I simply steal all the > > > validator/converter info from my dummy UIInput and apply it to the > > > wrapper, which then applies itself to the actual parent UIInput. So this > > > adds a level of indirection, but it is entirely handled by the custom > > > tag during page compilation. This way it works out to be fairly non > > > intrusive. > > > > > > What problems with JSF 1.1 + jsp did you have in mind? > > > > Well, it's been two-and-a-half years, but I seem to remember the > > problem was that under JSF 1.1 + jsp, the converters and validators > > are created from scratch every request rather than restored using the > > JSF state-saving mechanism. So all of the values set on the > > converters/validators would be lost the next request. > > > > > > > Also, a question on mailing list protocol, if you don't mind. This is my > > > first attempt at participating in developer mailing lists so I am > > > uncertain what would be a more appropriate way to show this thing to > > > Tomahawk guys - reposting the whole thing in the tomahawk list, or > > > referencing the post I made here? > > > > This is both the MyFaces Core and MyFaces Tomahawk mailing list. So > > you don't need to repost it. > > > > My comment was that, structurally, this patch would be a candidate for > > the Tomahawk project, but would not be a candidate for the MyFace Core > > project. In fact, it might fit in with the newly-proposed (earlier > > today) MyFaces Commons project better since it doesn't seem to be > > dependent on any particular renderkit. > >
