> Yes, but your wrapping validator doesn't have the ability to save the > state of the wrapped validator, does it? All I needed to do here was make my wrapping validator a StateHolder and call saveAttachedState() on the wrapped validators. So everything is saved and restored properly this way.
> then at some point open a JIRA issue and > attach a patch to provide your contribution. Since this will probably go into MyFaces Commons, I guess I will need to wait until that project is created, before I can make a patch for it. I am also wondering where I would put the custom tag's Facelets counterpart (the custom MetaTagHandler). Does MyFaces provide any Facelets related code? Or would this be more of a documentation item saying that "If you want to use this with facelets, paste this code in"? Val On Wed, 2007-24-10 at 17:52 -0400, Mike Kienenberger wrote: > 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. > > > >
