Hmm. I honestly don't remember calling saveAttachedState() -- maybe that was my problem :-) Good to know for the future if it ever comes up again.
You can create a JIRA issue for it at any time. Just open it under TOMAHAWK and set it to NEW COMPONENT. If we decide to make a COMMONS or FACELETS jira project (and I don't really think we'll do that), we'll migrate the issue at that time. We're also proposing a new MyFaces facelets project -- that's probably where your facelets code will end up. At some point, we'll hopefully merge it all together, but we're not at that point yet. On 10/24/07, Val <[EMAIL PROTECTED]> wrote: > > 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. > > > > > > > >
