• Post Reply Bookmark Topic Watch Topic
  • New Topic

Which Binding Type Do You Prefer And Why  RSS feed

 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was curious as to what other JSF users prefer as far as binding their HTML components to backing beans. Do you prefer to bind using the actual binding attribute to an actual component in the backing bean or do you prefer to bind to a backing bean property via the value attribute?

Are there cases when you should and should not use one or the other? I ask this because a few weeks ago I was looking at JSC (don't get me started) and they use they binding attribute for everything.
 
Varun Khanna
Ranch Hand
Posts: 1400
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
They look same but I feel they are different. If you want to modify the submitted value of a component you will require that component and you can do so in two ways,

1) first by having a component binding
-----------------------------------------------
myComponent.setSubmittedValue("blah .. blah");
-----------------------------------------------

or

2) By
i) getting facesContext instance
ii) getting External context
iii)getting View Root
iv) finding Component in view root and passing formName:componentId
as parameter.
v) finally calling setSubmittedValue in the component.

first approach looks cleaner than the second one. Hence I will prefer a component binding. But can we do the same with value binding? I guess not.
In update_model_phase, submitted value updates the object referred by value binding attribute (provided the validation succeeds).
Hence both has it's own use I guess.
[ July 08, 2005: Message edited by: Varun Khanna ]
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ahh, you complicated the issue. This is what I am talking about..




VS




The difference in how you retreive values would be something like




VS



That is what I am talking about.
 
Varun Khanna
Ranch Hand
Posts: 1400
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now, if you are asking *strictly* over the above scenario, I would say you can use any, it makes no difference.

But if you ask me if component binding and value binding are the same thing, I would quote the example I mentioned in my first post to show that for few things, I would require component binding since value binding can't do that stuff for me.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Varun Khanna:
Now, if you are asking *strictly* over the above scenario, I would say you can use any, it makes no difference.

But if you ask me if component binding and value binding are the same thing, I would quote the example I mentioned in my first post to show that for few things, I would require component binding since value binding can't do that stuff for me.


Ok, I gotcha. Sorry, I misunderstood your first post.
 
Rick Beaver
Ranch Hand
Posts: 464
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I tend to go for direct value binding simply because I like to have clear distinction between user data and the component itself to make it easier to maintain. Also you get a lot less code when you bind directly to a value (as you can see in JSC).

I use component binding to customise the actual component's properties (validation, style, visibility etc.) but not to mess with the value.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rick Beaver:
I use component binding to customise the actual component's properties (validation, style, visibility etc.) but not to mess with the value.


I'd argue that you are doing things backwards. Well, at least the style part. That definatly belongs in the JSP code. And I'd say the main compelling reason for component binding is for manipulating/using the data. I did change one of my pages to complete component binding and the page really cleaned up nice. Not near as much in the JSP as before so a lot easier to maintain.
 
Rick Beaver
Ranch Hand
Posts: 464
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gregg Bolinger:


I'd argue that you are doing things backwards. Well, at least the style part. That definatly belongs in the JSP code. And I'd say the main compelling reason for component binding is for manipulating/using the data. I did change one of my pages to complete component binding and the page really cleaned up nice. Not near as much in the JSP as before so a lot easier to maintain.


Normally I would agree that view customisation should be in the JSP. In my case however component properties are set based on application logic so to avoid putting logic inside the JSP's I populate the component's properties from the backing bean. This is the only time I use component binding.

All my values are handled with value binding. I have found I have to generate much less code in my backing beans if I just deal with the values rather than the components.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rick Beaver:


Normally I would agree that view customisation should be in the JSP. In my case however component properties are set based on application logic so to avoid putting logic inside the JSP's I populate the component's properties from the backing bean. This is the only time I use component binding.

All my values are handled with value binding. I have found I have to generate much less code in my backing beans if I just deal with the values rather than the components.


That makes sense to me. Ok, since we are on this topic, I have a question. Say I want to change an outputText component to be red when there is an error with it's associated inputText field. If I am using the standard validatators, where can I check for errors to exist to change that label? Would I have to catch this in a phase listener of some sort?
 
Mauro Castaldo
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gregg Bolinger:


That makes sense to me. Ok, since we are on this topic, I have a question. Say I want to change an outputText component to be red when there is an error with it's associated inputText field. If I am using the standard validatators, where can I check for errors to exist to change that label? Would I have to catch this in a phase listener of some sort?


try this:

I can't test it now but it should run.

Mauro
 
Mauro Castaldo
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mauro Castaldo:


Mauro


Sorry, should be
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That didn't work. Here are some code snipits:





Nothing happens when the field is left blank as far as the style is concerned. The normal style is not even being applied.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am assuming that the styleClass attribute won't evaluate expressions. I changed the outputText to an outputLabel also because outputText just renders text which you can't have a style on. Kind of silly the attribute is there for outputText. Anyway, not sure what else to try here. Good idea though. I wish it worked.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, sidenote. If you add styleClass to an outputText component it wraps it up in a span.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, fixed it. You need single quote around the outcomes based on the expression. So it should be:



Perfect! Thanks a bunch Mauro.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!