Why does Creator discourage placing bean properties in the Page Bean?
When I right click on the Request, Session or Application Bean I get a contextual menu allowing me to add properties to these beans. Not so with the page bean.
From a design point of view, if I'm going to use a property only on one page it's far simpler, neater and better encapsulated to have that property in the page bean. The page bean is a bona fida Request Bean isn't it? The Database dropping mechanism can be cajoled into creating the Rowset and Dataprovider on the page. Manually creating bean properties in the Page Bean works fine and the binding navigator recognizes them.
So I'm wondering why Creator seems to discourage this practice? Is it just an oversight in the program or is this a bad practice thats gonna blow up in my face, or does it just not conform to someone's idea of what is good?
[832 byte] By [
yossarian] at [2007-11-26 11:35:24]
# 1
Page Beans and Request Beans are not the same thing - Request Beans are designed to maintain scope while navigating between Page Beans.
And if you have a lot of pages in your application (like 30+, I've seen this), Page Bean scope might become inefficient and hard to debug.
So for real world applications this might have been considered not a good practice, and therefore was never implementated.
Regards,
-Brad Mayer
# 3
Well personally i find this easier to debug since my data and the code that changes it is all in one place (granted the jsp is separate but still immediately accessable). Also, I am not using page bean properties to pass data between pages.
Craig McClanahan posted this reply on nbusers to a similar question. He is basically explaining the point of the request bean here:
Begin Quote
==========================
Consider the scenario where you process a postback for Page1, and you know that you need to navigate to Page2. But, the data that Page2 will process depends on some of the input values entered on the form for Page1. How does the backing bean for Page1 forward those values to Page2?
I can think of three different approaches:
* Make the information available as public properties on Page1.java. This is
accessible from Page2.java, but it only works if that is the only way to get
to Page2 ... if there is a path from Page3 to Page2, this will break.
* Make the Page1 class update public properties on Page2's class. That will
work as long as Page2 is the only way to produce the required output, but
what happens if the navigation rules are changed later so that it is some other
page instead?
* Make the data available as a request scope bean "somewhere else". This was the intent for RequestBean1 being created by default. If you ever have to pass, say, a customer primary key from one page to another, create a public "customerId" property on RequestBean1, and use that to pass the information from page to page. In our scenario, Page1 can just pass the information in the request bean,and not care what page will actually be used to display it. And, Page2 will just go to RequestBean1 to receive its information, and not care who sent it.
Why not use completely separate request scoped managed beans instead? That is perfectly reasonable, but it's a lot more work than just making the data you want to pass a property of the request scoped bean that VWP gives you out of the box. In addition, using RequestBean1 means you get some extra help at development time, like code completion on the property getter and setter method names -- plus, you never risk the possibility that you've mistyped the name of the request scoped managed bean. It will "just worik" because you'll get compile errors immediately if you use this pattern, versus runtime null pointer exceptions.
==========================================
End quote
Also the restriction has been removed from VWP so, in a sense, this is no longer a valid question.
# 4
> Page Beans and Request Beans are not the same thing -
> Request Beans are designed to maintain scope while
> navigating between Page Beans.
Actually, they are not the same thing. Consider a page with a button that returns null (that is, it causes the same page to redisplay). When the page is first visited, a page bean is instantiated and sends the rendered page. The page bean is then destroyed. When you click the button, the page is submitted and a new page bean is instantiated. Thus the page bean properties are re-initialized.
If your properties are always the same, then it is perfectly fine to add the property to the page bean. One example is when I set a static text component's value to the current date. No need to put this in the request bean. Another example would be a static Options array that would NEVER change, such as a list of Month names.
For more information: http://developers.sun.com/prodtech/javatools/jscreator/learning/tutorials/2/sco pes.html
