You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by benjamin van der veen <bv...@gmail.com> on 2006/05/20 19:47:22 UTC
Populating input fields and updating the model separately
Hello,
This is hard to articulate, so let me give an example:
Suppose you are making a message board. The objective is to make a
form the user can use to quote posts below his post, like so:
(user 3 sees this in a text area, and types something above it)
[begin textarea]
> user 2 said:
> second message
>
> > user 1 said:
> > original message
[end textarea]
In this example, user 3 is replying to a message from user 2, which
itself is a reply to a message from user 1.
The initial value of the text area comes from a Post object; I am
iterating (<ui:repeat>) through a collection of Posts to build the
topic view. However, when the user submits this form, I don't want the
value of the Post object to be updated, I want a separate field
(newPostContent) on my backing bean to be updated. The problem is
here:
<h:inputTextarea value="#{post.content}"/>
--I cannot specify that I want the inital value to come from one place
and I want the user-submitted value to go somewhere else. To give an
example of what such a thing might look like:
<h:inputTextarea initialValue="#{post.content}"
bindSubmittedValueTo="#{myBean.newPostContent}"/>
How would this be done in reality?
Thanks,
benjamin
Re: Populating input fields and updating the model separately
Posted by Matthias Wessendorf <ma...@apache.org>.
> get this to fit into the correct JSF phase as the converters are
> applied (I believe) during the processing of validators and not during
> the updating of the model.
Yes.
In "Process Validations" the converters are called before the
validation is started.
Since you need a converted object before you can validate it :-)
The phase should be renamed to "Process Convertions and Validations" IMO.
-Matthias
Re: Populating input fields and updating the model separately
Posted by benjamin van der veen <bv...@gmail.com>.
Andrew,
I certainly see a lot of potential for JSF, and I certainly appreciate
the creativity and time that you and the rest community put forth to
work out the unforseen kinks. But at this point, it's too much effort
(and not fair to my summer employer) for me to have to chase down a
hack for almost every aspect of working with the framework, as has
been my experience with JSF to date. I'll certainly be back after a
major release or two, because I really like the idea, but I'm going to
have to make due with PHP for one more summer.
Thanks for all your help.
benjamin
On 5/21/06, Andrew Robinson <an...@gmail.com> wrote:
> I like PHP too, but I find it hard to maintain. I tried to refactor an
> object in a medium sized site and it was a nightmare (wish I had a
> compiler). Since JSF is new, hopefully it will continue to grow and
> adapt as Sun and the development community flushes out shortcommings
> as people adopt, use and comment on it. The control is there, and the
> power is there, the problem is some things are a bit advanced to
> accomplish. Luckily we have people willing to put their time in to
> help write these 3rd party extensions that make life easier.
>
> On 5/21/06, benjamin van der veen <bv...@gmail.com> wrote:
> > This afternoon I hacked up something like your wrapper collection. I
> > wrapped the individual Post objects in a class whose constructor takes
> > the Post object and a reference to the backing bean. The wrapper's
> > getContent() method returns this.post.getContent() and setContent()
> > sets this.bean.setNewPostContent(). Then the form's action method
> > (which of course is a method on the bean) uses newPostContent to
> > create a new post.
> >
> > In theory this sounded good, but the action method is not being called
> > when I click on a commandButton in one of the reply forms. I think
> > this because there is a separate form for each Post, and somehow the
> > plumbing isn't working out.
> >
> > > value="#{getter: bean.someProperty setter: bean.someOtherProperty}"
> >
> > This syntax would be ideal, but it's a little beyond my expertise to
> > hack up something of this nature. Same goes for the other suggestions
> > you made. The work required to do these things is in my mind
> > disproportional to their actual complexity. I feel that these are
> > simple things that should have been considered when the framework was
> > designed.
> >
> > Perhaps all this angst is my fault because I won't just roll over and
> > sell my soul to JSF. I want more control than it can afford me at this
> > stage in its development.
> >
> > I was really excited about JSF when I started, but it seems like there
> > are still a lot of things missing. I'm pretty much ready to dump it.
> > Call me naive, but I've spent the past 2 hours planning out my own web
> > framework. ;) Last summer I ported ASP.NET to PHP (again, call me
> > naive, but it is a serious boon to my PHP development), so I'm very
> > familiar with that framework and its shortcomings. Maybe this summer I
> > roll a lightweight framework that actually does what I want it to.
> >
> > benjamin
> >
> > On 5/21/06, Andrew Robinson <an...@gmail.com> wrote:
> > > One other idea, would a converter be able to do this? I know it
> > > wouldn't be conventional, but you could "convert" the value to a
> > > different bean and then restore the unmodified value so that the
> > > original value is untouched on the "source" bean. The trick is how to
> > > get this to fit into the correct JSF phase as the converters are
> > > applied (I believe) during the processing of validators and not during
> > > the updating of the model.
> > >
> > > Anyone know if there is a way to override the decode of all components
> > > instead of just one component at a time? Like a submitted visitor
> > > pattern of some sort? I have often thought it would be nice to have
> > > this same ability for rendering (so you could put a css border, for
> > > example, on all controls with a certain attribute on them regardless
> > > of the component type).
> > >
> > > -Andrew
> > >
> > > On 5/21/06, Andrew Robinson <an...@gmail.com> wrote:
> > > > As for collections, I tend to use custom collections for getting
> > > > updates from JSF. It isn't the cleanest solution by any means, but has
> > > > helped me out with the "limitations" of the EL language.
> > > >
> > > > I have made wrappers something like (I am not at my work computer, so
> > > > can't bring up the exact code):
> > > >
> > > > public class CustomMap<K,V> extends AbstractMap<K,V> {
> > > > public V put(K key, V value) {
> > > > V prev = super.put(key, value);
> > > > // do the business logic here
> > > > return prev;
> > > > }
> > > >
> > > > It ends up being a bit of a bean in itself, instead of just a
> > > > collection, but then you have the power to delegate business code when
> > > > binding updates a collection value.
> > > >
> > > > Would be nice if there could be some binding interceptor with JSF that
> > > > could be applied to all components. The only way I know of with that
> > > > is a custom variable resolver. Perhaps that is what you want to do? I
> > > > am not sure all of what you are allowed to do with a variable
> > > > resolver, but you (maybe) could:
> > > >
> > > > value="#{getter: bean.someProperty setter: bean.someOtherProperty}"
> > > >
> > > > As I said, I'm not sure if you are allowed to "hack" the EL like this
> > > > or not, I can't recall at what level the engine leaves off and where
> > > > the variable resolver takes up.
> > > >
> > > > Maybe you could use a JSTL stype function (if you are using facelets)
> > > > and write a function that has a return type of MethodBinding? Once
> > > > again I'm not sure if the specification would allow such a thing.
> > > >
> > > > Just some other ideas, sorry that I don't know if any are feasible.
> > > >
> > > > The other comment, you say you don't know what was replied to, could
> > > > you? Is it possible to use the myfaces updateActionListener to set the
> > > > selected post on the backing bean during post back?
> > > >
> > > > -Andrew
> > > >
> > > > On 5/21/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > > I've been looking into the tag/component thing, and it seems like
> > > > > rather a lot of work. The way I see it, I would have to reimplement
> > > > > all of the tag/component/renderer groups where the component extends
> > > > > UIInput, and that is a little ridiculous. Any suggestions for
> > > > > alternatives?
> > > > >
> > > > > benjamin
> > > > >
> > > > > On 5/20/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > > > This wouldn't quite work because the Posts are in a collection, and I
> > > > > > don't know which one was replied to, so I wouldn't know which to get
> > > > > > the content from.
> > > > > >
> > > > > > Probably the component idea is the best one.
> > > > > >
> > > > > > On 5/20/06, Andrew Robinson <an...@gmail.com> wrote:
> > > > > > > You could accomplish this with a facade. I know it isn't what you are
> > > > > > > exactly looking for, but would work.
> > > > > > >
> > > > > > > Example (Using seam annotations):
> > > > > > >
> > > > > > > @Name("postBean")
> > > > > > > public class Post
> > > > > > > {
> > > > > > > private String content;
> > > > > > > pubic String getContent() { return this.content; }
> > > > > > > }
> > > > > > >
> > > > > > > @Name("postResult")
> > > > > > > pubic class ResultsBean
> > > > > > > {
> > > > > > > private String newContent;
> > > > > > > public String getNewContent() { return this.newContent; }
> > > > > > > public void setNewContent(String content) { this.newContent = content; }
> > > > > > > }
> > > > > > >
> > > > > > > @Name("post")
> > > > > > > public class PostFacade
> > > > > > > {
> > > > > > > @In
> > > > > > > private Post postBean;
> > > > > > > @In(create=true)
> > > > > > > private ResutsBean postResult;
> > > > > > >
> > > > > > > public String getContent()
> > > > > > > {
> > > > > > > return (postResult.getNewContent() != null) ?
> > > > > > > postResult.getNewContent() :
> > > > > > > postBean.getContent();
> > > > > > > }
> > > > > > >
> > > > > > > public String setContent(String content) {
> > > > > > > postResult.setNewContent(content); }
> > > > > > > }
> > > > > > >
> > > > > > > XHTML:
> > > > > > > <t:inputTextarea value="#{post.content}" />
> > > > > > >
> > > > > > > There are other ways, this is just the first that came to mind.
> > > > > > >
> > > > > > > Another would obviously be a custom tag & component and handle the
> > > > > > > decode in the way that you want.
> > > > > > >
> > > > > > > -Andrew
> > > > > > >
> > > > > > > On 5/20/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > This is hard to articulate, so let me give an example:
> > > > > > > >
> > > > > > > > Suppose you are making a message board. The objective is to make a
> > > > > > > > form the user can use to quote posts below his post, like so:
> > > > > > > >
> > > > > > > > (user 3 sees this in a text area, and types something above it)
> > > > > > > >
> > > > > > > > [begin textarea]
> > > > > > > >
> > > > > > > > > user 2 said:
> > > > > > > > > second message
> > > > > > > > >
> > > > > > > > > > user 1 said:
> > > > > > > > > > original message
> > > > > > > > [end textarea]
> > > > > > > >
> > > > > > > > In this example, user 3 is replying to a message from user 2, which
> > > > > > > > itself is a reply to a message from user 1.
> > > > > > > >
> > > > > > > > The initial value of the text area comes from a Post object; I am
> > > > > > > > iterating (<ui:repeat>) through a collection of Posts to build the
> > > > > > > > topic view. However, when the user submits this form, I don't want the
> > > > > > > > value of the Post object to be updated, I want a separate field
> > > > > > > > (newPostContent) on my backing bean to be updated. The problem is
> > > > > > > > here:
> > > > > > > >
> > > > > > > > <h:inputTextarea value="#{post.content}"/>
> > > > > > > >
> > > > > > > > --I cannot specify that I want the inital value to come from one place
> > > > > > > > and I want the user-submitted value to go somewhere else. To give an
> > > > > > > > example of what such a thing might look like:
> > > > > > > >
> > > > > > > > <h:inputTextarea initialValue="#{post.content}"
> > > > > > > > bindSubmittedValueTo="#{myBean.newPostContent}"/>
> > > > > > > >
> > > > > > > > How would this be done in reality?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > benjamin
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Populating input fields and updating the model separately
Posted by Andrew Robinson <an...@gmail.com>.
I like PHP too, but I find it hard to maintain. I tried to refactor an
object in a medium sized site and it was a nightmare (wish I had a
compiler). Since JSF is new, hopefully it will continue to grow and
adapt as Sun and the development community flushes out shortcommings
as people adopt, use and comment on it. The control is there, and the
power is there, the problem is some things are a bit advanced to
accomplish. Luckily we have people willing to put their time in to
help write these 3rd party extensions that make life easier.
On 5/21/06, benjamin van der veen <bv...@gmail.com> wrote:
> This afternoon I hacked up something like your wrapper collection. I
> wrapped the individual Post objects in a class whose constructor takes
> the Post object and a reference to the backing bean. The wrapper's
> getContent() method returns this.post.getContent() and setContent()
> sets this.bean.setNewPostContent(). Then the form's action method
> (which of course is a method on the bean) uses newPostContent to
> create a new post.
>
> In theory this sounded good, but the action method is not being called
> when I click on a commandButton in one of the reply forms. I think
> this because there is a separate form for each Post, and somehow the
> plumbing isn't working out.
>
> > value="#{getter: bean.someProperty setter: bean.someOtherProperty}"
>
> This syntax would be ideal, but it's a little beyond my expertise to
> hack up something of this nature. Same goes for the other suggestions
> you made. The work required to do these things is in my mind
> disproportional to their actual complexity. I feel that these are
> simple things that should have been considered when the framework was
> designed.
>
> Perhaps all this angst is my fault because I won't just roll over and
> sell my soul to JSF. I want more control than it can afford me at this
> stage in its development.
>
> I was really excited about JSF when I started, but it seems like there
> are still a lot of things missing. I'm pretty much ready to dump it.
> Call me naive, but I've spent the past 2 hours planning out my own web
> framework. ;) Last summer I ported ASP.NET to PHP (again, call me
> naive, but it is a serious boon to my PHP development), so I'm very
> familiar with that framework and its shortcomings. Maybe this summer I
> roll a lightweight framework that actually does what I want it to.
>
> benjamin
>
> On 5/21/06, Andrew Robinson <an...@gmail.com> wrote:
> > One other idea, would a converter be able to do this? I know it
> > wouldn't be conventional, but you could "convert" the value to a
> > different bean and then restore the unmodified value so that the
> > original value is untouched on the "source" bean. The trick is how to
> > get this to fit into the correct JSF phase as the converters are
> > applied (I believe) during the processing of validators and not during
> > the updating of the model.
> >
> > Anyone know if there is a way to override the decode of all components
> > instead of just one component at a time? Like a submitted visitor
> > pattern of some sort? I have often thought it would be nice to have
> > this same ability for rendering (so you could put a css border, for
> > example, on all controls with a certain attribute on them regardless
> > of the component type).
> >
> > -Andrew
> >
> > On 5/21/06, Andrew Robinson <an...@gmail.com> wrote:
> > > As for collections, I tend to use custom collections for getting
> > > updates from JSF. It isn't the cleanest solution by any means, but has
> > > helped me out with the "limitations" of the EL language.
> > >
> > > I have made wrappers something like (I am not at my work computer, so
> > > can't bring up the exact code):
> > >
> > > public class CustomMap<K,V> extends AbstractMap<K,V> {
> > > public V put(K key, V value) {
> > > V prev = super.put(key, value);
> > > // do the business logic here
> > > return prev;
> > > }
> > >
> > > It ends up being a bit of a bean in itself, instead of just a
> > > collection, but then you have the power to delegate business code when
> > > binding updates a collection value.
> > >
> > > Would be nice if there could be some binding interceptor with JSF that
> > > could be applied to all components. The only way I know of with that
> > > is a custom variable resolver. Perhaps that is what you want to do? I
> > > am not sure all of what you are allowed to do with a variable
> > > resolver, but you (maybe) could:
> > >
> > > value="#{getter: bean.someProperty setter: bean.someOtherProperty}"
> > >
> > > As I said, I'm not sure if you are allowed to "hack" the EL like this
> > > or not, I can't recall at what level the engine leaves off and where
> > > the variable resolver takes up.
> > >
> > > Maybe you could use a JSTL stype function (if you are using facelets)
> > > and write a function that has a return type of MethodBinding? Once
> > > again I'm not sure if the specification would allow such a thing.
> > >
> > > Just some other ideas, sorry that I don't know if any are feasible.
> > >
> > > The other comment, you say you don't know what was replied to, could
> > > you? Is it possible to use the myfaces updateActionListener to set the
> > > selected post on the backing bean during post back?
> > >
> > > -Andrew
> > >
> > > On 5/21/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > I've been looking into the tag/component thing, and it seems like
> > > > rather a lot of work. The way I see it, I would have to reimplement
> > > > all of the tag/component/renderer groups where the component extends
> > > > UIInput, and that is a little ridiculous. Any suggestions for
> > > > alternatives?
> > > >
> > > > benjamin
> > > >
> > > > On 5/20/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > > This wouldn't quite work because the Posts are in a collection, and I
> > > > > don't know which one was replied to, so I wouldn't know which to get
> > > > > the content from.
> > > > >
> > > > > Probably the component idea is the best one.
> > > > >
> > > > > On 5/20/06, Andrew Robinson <an...@gmail.com> wrote:
> > > > > > You could accomplish this with a facade. I know it isn't what you are
> > > > > > exactly looking for, but would work.
> > > > > >
> > > > > > Example (Using seam annotations):
> > > > > >
> > > > > > @Name("postBean")
> > > > > > public class Post
> > > > > > {
> > > > > > private String content;
> > > > > > pubic String getContent() { return this.content; }
> > > > > > }
> > > > > >
> > > > > > @Name("postResult")
> > > > > > pubic class ResultsBean
> > > > > > {
> > > > > > private String newContent;
> > > > > > public String getNewContent() { return this.newContent; }
> > > > > > public void setNewContent(String content) { this.newContent = content; }
> > > > > > }
> > > > > >
> > > > > > @Name("post")
> > > > > > public class PostFacade
> > > > > > {
> > > > > > @In
> > > > > > private Post postBean;
> > > > > > @In(create=true)
> > > > > > private ResutsBean postResult;
> > > > > >
> > > > > > public String getContent()
> > > > > > {
> > > > > > return (postResult.getNewContent() != null) ?
> > > > > > postResult.getNewContent() :
> > > > > > postBean.getContent();
> > > > > > }
> > > > > >
> > > > > > public String setContent(String content) {
> > > > > > postResult.setNewContent(content); }
> > > > > > }
> > > > > >
> > > > > > XHTML:
> > > > > > <t:inputTextarea value="#{post.content}" />
> > > > > >
> > > > > > There are other ways, this is just the first that came to mind.
> > > > > >
> > > > > > Another would obviously be a custom tag & component and handle the
> > > > > > decode in the way that you want.
> > > > > >
> > > > > > -Andrew
> > > > > >
> > > > > > On 5/20/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > This is hard to articulate, so let me give an example:
> > > > > > >
> > > > > > > Suppose you are making a message board. The objective is to make a
> > > > > > > form the user can use to quote posts below his post, like so:
> > > > > > >
> > > > > > > (user 3 sees this in a text area, and types something above it)
> > > > > > >
> > > > > > > [begin textarea]
> > > > > > >
> > > > > > > > user 2 said:
> > > > > > > > second message
> > > > > > > >
> > > > > > > > > user 1 said:
> > > > > > > > > original message
> > > > > > > [end textarea]
> > > > > > >
> > > > > > > In this example, user 3 is replying to a message from user 2, which
> > > > > > > itself is a reply to a message from user 1.
> > > > > > >
> > > > > > > The initial value of the text area comes from a Post object; I am
> > > > > > > iterating (<ui:repeat>) through a collection of Posts to build the
> > > > > > > topic view. However, when the user submits this form, I don't want the
> > > > > > > value of the Post object to be updated, I want a separate field
> > > > > > > (newPostContent) on my backing bean to be updated. The problem is
> > > > > > > here:
> > > > > > >
> > > > > > > <h:inputTextarea value="#{post.content}"/>
> > > > > > >
> > > > > > > --I cannot specify that I want the inital value to come from one place
> > > > > > > and I want the user-submitted value to go somewhere else. To give an
> > > > > > > example of what such a thing might look like:
> > > > > > >
> > > > > > > <h:inputTextarea initialValue="#{post.content}"
> > > > > > > bindSubmittedValueTo="#{myBean.newPostContent}"/>
> > > > > > >
> > > > > > > How would this be done in reality?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > benjamin
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Populating input fields and updating the model separately
Posted by benjamin van der veen <bv...@gmail.com>.
This afternoon I hacked up something like your wrapper collection. I
wrapped the individual Post objects in a class whose constructor takes
the Post object and a reference to the backing bean. The wrapper's
getContent() method returns this.post.getContent() and setContent()
sets this.bean.setNewPostContent(). Then the form's action method
(which of course is a method on the bean) uses newPostContent to
create a new post.
In theory this sounded good, but the action method is not being called
when I click on a commandButton in one of the reply forms. I think
this because there is a separate form for each Post, and somehow the
plumbing isn't working out.
> value="#{getter: bean.someProperty setter: bean.someOtherProperty}"
This syntax would be ideal, but it's a little beyond my expertise to
hack up something of this nature. Same goes for the other suggestions
you made. The work required to do these things is in my mind
disproportional to their actual complexity. I feel that these are
simple things that should have been considered when the framework was
designed.
Perhaps all this angst is my fault because I won't just roll over and
sell my soul to JSF. I want more control than it can afford me at this
stage in its development.
I was really excited about JSF when I started, but it seems like there
are still a lot of things missing. I'm pretty much ready to dump it.
Call me naive, but I've spent the past 2 hours planning out my own web
framework. ;) Last summer I ported ASP.NET to PHP (again, call me
naive, but it is a serious boon to my PHP development), so I'm very
familiar with that framework and its shortcomings. Maybe this summer I
roll a lightweight framework that actually does what I want it to.
benjamin
On 5/21/06, Andrew Robinson <an...@gmail.com> wrote:
> One other idea, would a converter be able to do this? I know it
> wouldn't be conventional, but you could "convert" the value to a
> different bean and then restore the unmodified value so that the
> original value is untouched on the "source" bean. The trick is how to
> get this to fit into the correct JSF phase as the converters are
> applied (I believe) during the processing of validators and not during
> the updating of the model.
>
> Anyone know if there is a way to override the decode of all components
> instead of just one component at a time? Like a submitted visitor
> pattern of some sort? I have often thought it would be nice to have
> this same ability for rendering (so you could put a css border, for
> example, on all controls with a certain attribute on them regardless
> of the component type).
>
> -Andrew
>
> On 5/21/06, Andrew Robinson <an...@gmail.com> wrote:
> > As for collections, I tend to use custom collections for getting
> > updates from JSF. It isn't the cleanest solution by any means, but has
> > helped me out with the "limitations" of the EL language.
> >
> > I have made wrappers something like (I am not at my work computer, so
> > can't bring up the exact code):
> >
> > public class CustomMap<K,V> extends AbstractMap<K,V> {
> > public V put(K key, V value) {
> > V prev = super.put(key, value);
> > // do the business logic here
> > return prev;
> > }
> >
> > It ends up being a bit of a bean in itself, instead of just a
> > collection, but then you have the power to delegate business code when
> > binding updates a collection value.
> >
> > Would be nice if there could be some binding interceptor with JSF that
> > could be applied to all components. The only way I know of with that
> > is a custom variable resolver. Perhaps that is what you want to do? I
> > am not sure all of what you are allowed to do with a variable
> > resolver, but you (maybe) could:
> >
> > value="#{getter: bean.someProperty setter: bean.someOtherProperty}"
> >
> > As I said, I'm not sure if you are allowed to "hack" the EL like this
> > or not, I can't recall at what level the engine leaves off and where
> > the variable resolver takes up.
> >
> > Maybe you could use a JSTL stype function (if you are using facelets)
> > and write a function that has a return type of MethodBinding? Once
> > again I'm not sure if the specification would allow such a thing.
> >
> > Just some other ideas, sorry that I don't know if any are feasible.
> >
> > The other comment, you say you don't know what was replied to, could
> > you? Is it possible to use the myfaces updateActionListener to set the
> > selected post on the backing bean during post back?
> >
> > -Andrew
> >
> > On 5/21/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > I've been looking into the tag/component thing, and it seems like
> > > rather a lot of work. The way I see it, I would have to reimplement
> > > all of the tag/component/renderer groups where the component extends
> > > UIInput, and that is a little ridiculous. Any suggestions for
> > > alternatives?
> > >
> > > benjamin
> > >
> > > On 5/20/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > This wouldn't quite work because the Posts are in a collection, and I
> > > > don't know which one was replied to, so I wouldn't know which to get
> > > > the content from.
> > > >
> > > > Probably the component idea is the best one.
> > > >
> > > > On 5/20/06, Andrew Robinson <an...@gmail.com> wrote:
> > > > > You could accomplish this with a facade. I know it isn't what you are
> > > > > exactly looking for, but would work.
> > > > >
> > > > > Example (Using seam annotations):
> > > > >
> > > > > @Name("postBean")
> > > > > public class Post
> > > > > {
> > > > > private String content;
> > > > > pubic String getContent() { return this.content; }
> > > > > }
> > > > >
> > > > > @Name("postResult")
> > > > > pubic class ResultsBean
> > > > > {
> > > > > private String newContent;
> > > > > public String getNewContent() { return this.newContent; }
> > > > > public void setNewContent(String content) { this.newContent = content; }
> > > > > }
> > > > >
> > > > > @Name("post")
> > > > > public class PostFacade
> > > > > {
> > > > > @In
> > > > > private Post postBean;
> > > > > @In(create=true)
> > > > > private ResutsBean postResult;
> > > > >
> > > > > public String getContent()
> > > > > {
> > > > > return (postResult.getNewContent() != null) ?
> > > > > postResult.getNewContent() :
> > > > > postBean.getContent();
> > > > > }
> > > > >
> > > > > public String setContent(String content) {
> > > > > postResult.setNewContent(content); }
> > > > > }
> > > > >
> > > > > XHTML:
> > > > > <t:inputTextarea value="#{post.content}" />
> > > > >
> > > > > There are other ways, this is just the first that came to mind.
> > > > >
> > > > > Another would obviously be a custom tag & component and handle the
> > > > > decode in the way that you want.
> > > > >
> > > > > -Andrew
> > > > >
> > > > > On 5/20/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > > > Hello,
> > > > > >
> > > > > > This is hard to articulate, so let me give an example:
> > > > > >
> > > > > > Suppose you are making a message board. The objective is to make a
> > > > > > form the user can use to quote posts below his post, like so:
> > > > > >
> > > > > > (user 3 sees this in a text area, and types something above it)
> > > > > >
> > > > > > [begin textarea]
> > > > > >
> > > > > > > user 2 said:
> > > > > > > second message
> > > > > > >
> > > > > > > > user 1 said:
> > > > > > > > original message
> > > > > > [end textarea]
> > > > > >
> > > > > > In this example, user 3 is replying to a message from user 2, which
> > > > > > itself is a reply to a message from user 1.
> > > > > >
> > > > > > The initial value of the text area comes from a Post object; I am
> > > > > > iterating (<ui:repeat>) through a collection of Posts to build the
> > > > > > topic view. However, when the user submits this form, I don't want the
> > > > > > value of the Post object to be updated, I want a separate field
> > > > > > (newPostContent) on my backing bean to be updated. The problem is
> > > > > > here:
> > > > > >
> > > > > > <h:inputTextarea value="#{post.content}"/>
> > > > > >
> > > > > > --I cannot specify that I want the inital value to come from one place
> > > > > > and I want the user-submitted value to go somewhere else. To give an
> > > > > > example of what such a thing might look like:
> > > > > >
> > > > > > <h:inputTextarea initialValue="#{post.content}"
> > > > > > bindSubmittedValueTo="#{myBean.newPostContent}"/>
> > > > > >
> > > > > > How would this be done in reality?
> > > > > >
> > > > > > Thanks,
> > > > > > benjamin
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Populating input fields and updating the model separately
Posted by Andrew Robinson <an...@gmail.com>.
One other idea, would a converter be able to do this? I know it
wouldn't be conventional, but you could "convert" the value to a
different bean and then restore the unmodified value so that the
original value is untouched on the "source" bean. The trick is how to
get this to fit into the correct JSF phase as the converters are
applied (I believe) during the processing of validators and not during
the updating of the model.
Anyone know if there is a way to override the decode of all components
instead of just one component at a time? Like a submitted visitor
pattern of some sort? I have often thought it would be nice to have
this same ability for rendering (so you could put a css border, for
example, on all controls with a certain attribute on them regardless
of the component type).
-Andrew
On 5/21/06, Andrew Robinson <an...@gmail.com> wrote:
> As for collections, I tend to use custom collections for getting
> updates from JSF. It isn't the cleanest solution by any means, but has
> helped me out with the "limitations" of the EL language.
>
> I have made wrappers something like (I am not at my work computer, so
> can't bring up the exact code):
>
> public class CustomMap<K,V> extends AbstractMap<K,V> {
> public V put(K key, V value) {
> V prev = super.put(key, value);
> // do the business logic here
> return prev;
> }
>
> It ends up being a bit of a bean in itself, instead of just a
> collection, but then you have the power to delegate business code when
> binding updates a collection value.
>
> Would be nice if there could be some binding interceptor with JSF that
> could be applied to all components. The only way I know of with that
> is a custom variable resolver. Perhaps that is what you want to do? I
> am not sure all of what you are allowed to do with a variable
> resolver, but you (maybe) could:
>
> value="#{getter: bean.someProperty setter: bean.someOtherProperty}"
>
> As I said, I'm not sure if you are allowed to "hack" the EL like this
> or not, I can't recall at what level the engine leaves off and where
> the variable resolver takes up.
>
> Maybe you could use a JSTL stype function (if you are using facelets)
> and write a function that has a return type of MethodBinding? Once
> again I'm not sure if the specification would allow such a thing.
>
> Just some other ideas, sorry that I don't know if any are feasible.
>
> The other comment, you say you don't know what was replied to, could
> you? Is it possible to use the myfaces updateActionListener to set the
> selected post on the backing bean during post back?
>
> -Andrew
>
> On 5/21/06, benjamin van der veen <bv...@gmail.com> wrote:
> > I've been looking into the tag/component thing, and it seems like
> > rather a lot of work. The way I see it, I would have to reimplement
> > all of the tag/component/renderer groups where the component extends
> > UIInput, and that is a little ridiculous. Any suggestions for
> > alternatives?
> >
> > benjamin
> >
> > On 5/20/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > This wouldn't quite work because the Posts are in a collection, and I
> > > don't know which one was replied to, so I wouldn't know which to get
> > > the content from.
> > >
> > > Probably the component idea is the best one.
> > >
> > > On 5/20/06, Andrew Robinson <an...@gmail.com> wrote:
> > > > You could accomplish this with a facade. I know it isn't what you are
> > > > exactly looking for, but would work.
> > > >
> > > > Example (Using seam annotations):
> > > >
> > > > @Name("postBean")
> > > > public class Post
> > > > {
> > > > private String content;
> > > > pubic String getContent() { return this.content; }
> > > > }
> > > >
> > > > @Name("postResult")
> > > > pubic class ResultsBean
> > > > {
> > > > private String newContent;
> > > > public String getNewContent() { return this.newContent; }
> > > > public void setNewContent(String content) { this.newContent = content; }
> > > > }
> > > >
> > > > @Name("post")
> > > > public class PostFacade
> > > > {
> > > > @In
> > > > private Post postBean;
> > > > @In(create=true)
> > > > private ResutsBean postResult;
> > > >
> > > > public String getContent()
> > > > {
> > > > return (postResult.getNewContent() != null) ?
> > > > postResult.getNewContent() :
> > > > postBean.getContent();
> > > > }
> > > >
> > > > public String setContent(String content) {
> > > > postResult.setNewContent(content); }
> > > > }
> > > >
> > > > XHTML:
> > > > <t:inputTextarea value="#{post.content}" />
> > > >
> > > > There are other ways, this is just the first that came to mind.
> > > >
> > > > Another would obviously be a custom tag & component and handle the
> > > > decode in the way that you want.
> > > >
> > > > -Andrew
> > > >
> > > > On 5/20/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > > Hello,
> > > > >
> > > > > This is hard to articulate, so let me give an example:
> > > > >
> > > > > Suppose you are making a message board. The objective is to make a
> > > > > form the user can use to quote posts below his post, like so:
> > > > >
> > > > > (user 3 sees this in a text area, and types something above it)
> > > > >
> > > > > [begin textarea]
> > > > >
> > > > > > user 2 said:
> > > > > > second message
> > > > > >
> > > > > > > user 1 said:
> > > > > > > original message
> > > > > [end textarea]
> > > > >
> > > > > In this example, user 3 is replying to a message from user 2, which
> > > > > itself is a reply to a message from user 1.
> > > > >
> > > > > The initial value of the text area comes from a Post object; I am
> > > > > iterating (<ui:repeat>) through a collection of Posts to build the
> > > > > topic view. However, when the user submits this form, I don't want the
> > > > > value of the Post object to be updated, I want a separate field
> > > > > (newPostContent) on my backing bean to be updated. The problem is
> > > > > here:
> > > > >
> > > > > <h:inputTextarea value="#{post.content}"/>
> > > > >
> > > > > --I cannot specify that I want the inital value to come from one place
> > > > > and I want the user-submitted value to go somewhere else. To give an
> > > > > example of what such a thing might look like:
> > > > >
> > > > > <h:inputTextarea initialValue="#{post.content}"
> > > > > bindSubmittedValueTo="#{myBean.newPostContent}"/>
> > > > >
> > > > > How would this be done in reality?
> > > > >
> > > > > Thanks,
> > > > > benjamin
> > > > >
> > > >
> > >
> >
>
Re: Populating input fields and updating the model separately
Posted by Andrew Robinson <an...@gmail.com>.
As for collections, I tend to use custom collections for getting
updates from JSF. It isn't the cleanest solution by any means, but has
helped me out with the "limitations" of the EL language.
I have made wrappers something like (I am not at my work computer, so
can't bring up the exact code):
public class CustomMap<K,V> extends AbstractMap<K,V> {
public V put(K key, V value) {
V prev = super.put(key, value);
// do the business logic here
return prev;
}
It ends up being a bit of a bean in itself, instead of just a
collection, but then you have the power to delegate business code when
binding updates a collection value.
Would be nice if there could be some binding interceptor with JSF that
could be applied to all components. The only way I know of with that
is a custom variable resolver. Perhaps that is what you want to do? I
am not sure all of what you are allowed to do with a variable
resolver, but you (maybe) could:
value="#{getter: bean.someProperty setter: bean.someOtherProperty}"
As I said, I'm not sure if you are allowed to "hack" the EL like this
or not, I can't recall at what level the engine leaves off and where
the variable resolver takes up.
Maybe you could use a JSTL stype function (if you are using facelets)
and write a function that has a return type of MethodBinding? Once
again I'm not sure if the specification would allow such a thing.
Just some other ideas, sorry that I don't know if any are feasible.
The other comment, you say you don't know what was replied to, could
you? Is it possible to use the myfaces updateActionListener to set the
selected post on the backing bean during post back?
-Andrew
On 5/21/06, benjamin van der veen <bv...@gmail.com> wrote:
> I've been looking into the tag/component thing, and it seems like
> rather a lot of work. The way I see it, I would have to reimplement
> all of the tag/component/renderer groups where the component extends
> UIInput, and that is a little ridiculous. Any suggestions for
> alternatives?
>
> benjamin
>
> On 5/20/06, benjamin van der veen <bv...@gmail.com> wrote:
> > This wouldn't quite work because the Posts are in a collection, and I
> > don't know which one was replied to, so I wouldn't know which to get
> > the content from.
> >
> > Probably the component idea is the best one.
> >
> > On 5/20/06, Andrew Robinson <an...@gmail.com> wrote:
> > > You could accomplish this with a facade. I know it isn't what you are
> > > exactly looking for, but would work.
> > >
> > > Example (Using seam annotations):
> > >
> > > @Name("postBean")
> > > public class Post
> > > {
> > > private String content;
> > > pubic String getContent() { return this.content; }
> > > }
> > >
> > > @Name("postResult")
> > > pubic class ResultsBean
> > > {
> > > private String newContent;
> > > public String getNewContent() { return this.newContent; }
> > > public void setNewContent(String content) { this.newContent = content; }
> > > }
> > >
> > > @Name("post")
> > > public class PostFacade
> > > {
> > > @In
> > > private Post postBean;
> > > @In(create=true)
> > > private ResutsBean postResult;
> > >
> > > public String getContent()
> > > {
> > > return (postResult.getNewContent() != null) ?
> > > postResult.getNewContent() :
> > > postBean.getContent();
> > > }
> > >
> > > public String setContent(String content) {
> > > postResult.setNewContent(content); }
> > > }
> > >
> > > XHTML:
> > > <t:inputTextarea value="#{post.content}" />
> > >
> > > There are other ways, this is just the first that came to mind.
> > >
> > > Another would obviously be a custom tag & component and handle the
> > > decode in the way that you want.
> > >
> > > -Andrew
> > >
> > > On 5/20/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > > Hello,
> > > >
> > > > This is hard to articulate, so let me give an example:
> > > >
> > > > Suppose you are making a message board. The objective is to make a
> > > > form the user can use to quote posts below his post, like so:
> > > >
> > > > (user 3 sees this in a text area, and types something above it)
> > > >
> > > > [begin textarea]
> > > >
> > > > > user 2 said:
> > > > > second message
> > > > >
> > > > > > user 1 said:
> > > > > > original message
> > > > [end textarea]
> > > >
> > > > In this example, user 3 is replying to a message from user 2, which
> > > > itself is a reply to a message from user 1.
> > > >
> > > > The initial value of the text area comes from a Post object; I am
> > > > iterating (<ui:repeat>) through a collection of Posts to build the
> > > > topic view. However, when the user submits this form, I don't want the
> > > > value of the Post object to be updated, I want a separate field
> > > > (newPostContent) on my backing bean to be updated. The problem is
> > > > here:
> > > >
> > > > <h:inputTextarea value="#{post.content}"/>
> > > >
> > > > --I cannot specify that I want the inital value to come from one place
> > > > and I want the user-submitted value to go somewhere else. To give an
> > > > example of what such a thing might look like:
> > > >
> > > > <h:inputTextarea initialValue="#{post.content}"
> > > > bindSubmittedValueTo="#{myBean.newPostContent}"/>
> > > >
> > > > How would this be done in reality?
> > > >
> > > > Thanks,
> > > > benjamin
> > > >
> > >
> >
>
Re: Populating input fields and updating the model separately
Posted by benjamin van der veen <bv...@gmail.com>.
I've been looking into the tag/component thing, and it seems like
rather a lot of work. The way I see it, I would have to reimplement
all of the tag/component/renderer groups where the component extends
UIInput, and that is a little ridiculous. Any suggestions for
alternatives?
benjamin
On 5/20/06, benjamin van der veen <bv...@gmail.com> wrote:
> This wouldn't quite work because the Posts are in a collection, and I
> don't know which one was replied to, so I wouldn't know which to get
> the content from.
>
> Probably the component idea is the best one.
>
> On 5/20/06, Andrew Robinson <an...@gmail.com> wrote:
> > You could accomplish this with a facade. I know it isn't what you are
> > exactly looking for, but would work.
> >
> > Example (Using seam annotations):
> >
> > @Name("postBean")
> > public class Post
> > {
> > private String content;
> > pubic String getContent() { return this.content; }
> > }
> >
> > @Name("postResult")
> > pubic class ResultsBean
> > {
> > private String newContent;
> > public String getNewContent() { return this.newContent; }
> > public void setNewContent(String content) { this.newContent = content; }
> > }
> >
> > @Name("post")
> > public class PostFacade
> > {
> > @In
> > private Post postBean;
> > @In(create=true)
> > private ResutsBean postResult;
> >
> > public String getContent()
> > {
> > return (postResult.getNewContent() != null) ?
> > postResult.getNewContent() :
> > postBean.getContent();
> > }
> >
> > public String setContent(String content) {
> > postResult.setNewContent(content); }
> > }
> >
> > XHTML:
> > <t:inputTextarea value="#{post.content}" />
> >
> > There are other ways, this is just the first that came to mind.
> >
> > Another would obviously be a custom tag & component and handle the
> > decode in the way that you want.
> >
> > -Andrew
> >
> > On 5/20/06, benjamin van der veen <bv...@gmail.com> wrote:
> > > Hello,
> > >
> > > This is hard to articulate, so let me give an example:
> > >
> > > Suppose you are making a message board. The objective is to make a
> > > form the user can use to quote posts below his post, like so:
> > >
> > > (user 3 sees this in a text area, and types something above it)
> > >
> > > [begin textarea]
> > >
> > > > user 2 said:
> > > > second message
> > > >
> > > > > user 1 said:
> > > > > original message
> > > [end textarea]
> > >
> > > In this example, user 3 is replying to a message from user 2, which
> > > itself is a reply to a message from user 1.
> > >
> > > The initial value of the text area comes from a Post object; I am
> > > iterating (<ui:repeat>) through a collection of Posts to build the
> > > topic view. However, when the user submits this form, I don't want the
> > > value of the Post object to be updated, I want a separate field
> > > (newPostContent) on my backing bean to be updated. The problem is
> > > here:
> > >
> > > <h:inputTextarea value="#{post.content}"/>
> > >
> > > --I cannot specify that I want the inital value to come from one place
> > > and I want the user-submitted value to go somewhere else. To give an
> > > example of what such a thing might look like:
> > >
> > > <h:inputTextarea initialValue="#{post.content}"
> > > bindSubmittedValueTo="#{myBean.newPostContent}"/>
> > >
> > > How would this be done in reality?
> > >
> > > Thanks,
> > > benjamin
> > >
> >
>
Re: Populating input fields and updating the model separately
Posted by benjamin van der veen <bv...@gmail.com>.
This wouldn't quite work because the Posts are in a collection, and I
don't know which one was replied to, so I wouldn't know which to get
the content from.
Probably the component idea is the best one.
On 5/20/06, Andrew Robinson <an...@gmail.com> wrote:
> You could accomplish this with a facade. I know it isn't what you are
> exactly looking for, but would work.
>
> Example (Using seam annotations):
>
> @Name("postBean")
> public class Post
> {
> private String content;
> pubic String getContent() { return this.content; }
> }
>
> @Name("postResult")
> pubic class ResultsBean
> {
> private String newContent;
> public String getNewContent() { return this.newContent; }
> public void setNewContent(String content) { this.newContent = content; }
> }
>
> @Name("post")
> public class PostFacade
> {
> @In
> private Post postBean;
> @In(create=true)
> private ResutsBean postResult;
>
> public String getContent()
> {
> return (postResult.getNewContent() != null) ?
> postResult.getNewContent() :
> postBean.getContent();
> }
>
> public String setContent(String content) {
> postResult.setNewContent(content); }
> }
>
> XHTML:
> <t:inputTextarea value="#{post.content}" />
>
> There are other ways, this is just the first that came to mind.
>
> Another would obviously be a custom tag & component and handle the
> decode in the way that you want.
>
> -Andrew
>
> On 5/20/06, benjamin van der veen <bv...@gmail.com> wrote:
> > Hello,
> >
> > This is hard to articulate, so let me give an example:
> >
> > Suppose you are making a message board. The objective is to make a
> > form the user can use to quote posts below his post, like so:
> >
> > (user 3 sees this in a text area, and types something above it)
> >
> > [begin textarea]
> >
> > > user 2 said:
> > > second message
> > >
> > > > user 1 said:
> > > > original message
> > [end textarea]
> >
> > In this example, user 3 is replying to a message from user 2, which
> > itself is a reply to a message from user 1.
> >
> > The initial value of the text area comes from a Post object; I am
> > iterating (<ui:repeat>) through a collection of Posts to build the
> > topic view. However, when the user submits this form, I don't want the
> > value of the Post object to be updated, I want a separate field
> > (newPostContent) on my backing bean to be updated. The problem is
> > here:
> >
> > <h:inputTextarea value="#{post.content}"/>
> >
> > --I cannot specify that I want the inital value to come from one place
> > and I want the user-submitted value to go somewhere else. To give an
> > example of what such a thing might look like:
> >
> > <h:inputTextarea initialValue="#{post.content}"
> > bindSubmittedValueTo="#{myBean.newPostContent}"/>
> >
> > How would this be done in reality?
> >
> > Thanks,
> > benjamin
> >
>
Re: Populating input fields and updating the model separately
Posted by Andrew Robinson <an...@gmail.com>.
You could accomplish this with a facade. I know it isn't what you are
exactly looking for, but would work.
Example (Using seam annotations):
@Name("postBean")
public class Post
{
private String content;
pubic String getContent() { return this.content; }
}
@Name("postResult")
pubic class ResultsBean
{
private String newContent;
public String getNewContent() { return this.newContent; }
public void setNewContent(String content) { this.newContent = content; }
}
@Name("post")
public class PostFacade
{
@In
private Post postBean;
@In(create=true)
private ResutsBean postResult;
public String getContent()
{
return (postResult.getNewContent() != null) ?
postResult.getNewContent() :
postBean.getContent();
}
public String setContent(String content) {
postResult.setNewContent(content); }
}
XHTML:
<t:inputTextarea value="#{post.content}" />
There are other ways, this is just the first that came to mind.
Another would obviously be a custom tag & component and handle the
decode in the way that you want.
-Andrew
On 5/20/06, benjamin van der veen <bv...@gmail.com> wrote:
> Hello,
>
> This is hard to articulate, so let me give an example:
>
> Suppose you are making a message board. The objective is to make a
> form the user can use to quote posts below his post, like so:
>
> (user 3 sees this in a text area, and types something above it)
>
> [begin textarea]
>
> > user 2 said:
> > second message
> >
> > > user 1 said:
> > > original message
> [end textarea]
>
> In this example, user 3 is replying to a message from user 2, which
> itself is a reply to a message from user 1.
>
> The initial value of the text area comes from a Post object; I am
> iterating (<ui:repeat>) through a collection of Posts to build the
> topic view. However, when the user submits this form, I don't want the
> value of the Post object to be updated, I want a separate field
> (newPostContent) on my backing bean to be updated. The problem is
> here:
>
> <h:inputTextarea value="#{post.content}"/>
>
> --I cannot specify that I want the inital value to come from one place
> and I want the user-submitted value to go somewhere else. To give an
> example of what such a thing might look like:
>
> <h:inputTextarea initialValue="#{post.content}"
> bindSubmittedValueTo="#{myBean.newPostContent}"/>
>
> How would this be done in reality?
>
> Thanks,
> benjamin
>