Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Multiple VIEW pages uses the same Backing bean  RSS feed

 
Luke Murphy
Ranch Hand
Posts: 300
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
In my design, I was thinking initially of having one backing bean per view page.
Now I am thinking that's way to fine grained and will lead to a proliferation of backing beans. I am now thinking of having
"smarter" backing beans which can be used by multiple pages.

However, this begs the interesting question in terms of what sort of granularity should backing beans have?

Give me your opinions?

Thanks.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It may seem annoying to have an application that's made up up about a million little parts, but it's a LOT harder to maintain a project that's got a few big lumpy omnibus parts. Basically, overloading functionality on components is the modern-day equivalent of "spaghetti code" with all the grief, wasted time, and expense that comes with it.

I'm pretty good at crunching down things myself. I had a lot of good examples to learn from over the years. But one thing I learn more and more every day even after all these years (the hard way ) is that it's better to do one thing and do it well than to make an app which is simpler in terms of component count but more complex in terms of internal complexity.
 
Luke Murphy
Ranch Hand
Posts: 300
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:It may seem annoying to have an application that's made up up about a million little parts, but it's a LOT harder to maintain a project that's got a few big lumpy omnibus parts. Basically, overloading functionality on components is the modern-day equivalent of "spaghetti code" with all the grief, wasted time, and expense that comes with it.

I'm pretty good at crunching down things myself. I had a lot of good examples to learn from over the years. But one thing I learn more and more every day even after all these years (the hard way ) is that it's better to do one thing and do it well than to make an app which is simpler in terms of component count but more complex in terms of internal complexity.

So are you saying it should 1 backing bean per view page always?

What about this, you have a Create, Read, Update, Delete view page for Tennis ball. Do you really think there should be a Create, View, Read, Delete tennis ball backing beans?

What about just having one TennisBall backing bean for the four?

Go on tell us what you think now...

I'm curious...

 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting that you should choose that example.

Typically, I use the same view for C/R/U/D, so the same bean applies to all of them. As simple as possible, but no simpler. It's not cost-effective for me to maintain 4 different view definitions when only a small number of modes apply and they alter only a few controls and captions according to limited and fixed rules that are easy to understand. I may have an edit view and a display-only view sharing that bean, but that's it.

However, in addition to single-row edit functions, apps also often have table view and/or search functions and those often end up interjecting themselves into the single-row functionality due to the way JSF likes to arrange things. I'm not all that happy on that one getting jammed into the same bean that the single-item edit/display views use. I find it rather untidy.

In the larger world, however, I do generally have a separate bean or beanset - and corresponding views - for tennis balls, golf balls, basketballs, baseballs, and so forth. Although being an old-time OOP hand that doesn't mean that I'm mindlessly cloning stuff. That, after all, is what inheritance and component view templates are for.
 
Luke Murphy
Ranch Hand
Posts: 300
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:Interesting that you should choose that example.

Typically, I use the same view for C/R/U/D, so the same bean applies to all of them. As simple as possible, but no simpler. It's not cost-effective for me to maintain 4 different view definitions when only a small number of modes apply and they alter only a few controls and captions according to limited and fixed rules that are easy to understand. I may have an edit view and a display-only view sharing that bean, but that's it.

However, in addition to single-row edit functions, apps also often have table view and/or search functions and those often end up interjecting themselves into the single-row functionality due to the way JSF likes to arrange things. I'm not all that happy on that one getting jammed into the same bean that the single-item edit/display views use. I find it rather untidy.

In the larger world, however, I do generally have a separate bean or beanset - and corresponding views - for tennis balls, golf balls, basketballs, baseballs, and so forth. Although being an old-time OOP hand that doesn't mean that I'm mindlessly cloning stuff. That, after all, is what inheritance and component view templates are for.

Interesting. I think this is one of those "it depends" questions. However I think a good rule of thumb is before you think about reuse in your backing beans you should think about reuse in your view pages (i.e. use a template or something). I think we'd both agree on this?

Also, do you find yourself using inheritance often in your managed beans? This isn't something I could see being used alot in a real world application. I'm just going off gut instinct here.

Inheritance makes things a little inflexible and I would think backing beans is something you'd want the flexibility for.

If your coffee is still warm...

Discuss...






 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!