You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Jadeler <ja...@yahoo.ca> on 2005/09/20 20:51:02 UTC
Facade in the view
To better maintain all the data, I am opting not
having alot of session variables but instead maintain
one object that will contain all data needed and store
that in a session. For example, instead of having
session.setAttribute("product", product),
session.setAttribute("web_preference", webPreference),
etc. just create an object like this which can then be
stored in a session:
public class UserContainer{
private Product product;
private WebPreference webPreference;
public Product getProduct () {
return product;
}
public void setProduct(Product newProduct){
product= newProduct;
}
}
and in the jsp page have something like this
<% UserContainer userContainer = (UserContainer)
session.getAttribute(Constants.USER_CONTAINER_KEY); %>
Do you guys do something similar or any other
recommendations?
Jade
__________________________________________________________
Find your next car at http://autos.yahoo.ca
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Re: Facade in the view
Posted by Jadeler <ja...@yahoo.ca>.
Thanks Dave and Michael. I've implemented the
UserContainer object as a means of just encapsulating
necessary info that would otherwise be in separate
sessions. I have also used the action forms
accordingly to display necessary info that would be
more natural. For pages that require the form to
change depending on user interactions and maintaining
a list of objects within the form, I basically use
them as a form attribute that is a list and store the
form in a session.
Jade
--- Dave Newton <ne...@pingsite.com> wrote:
> Michael Jouravlev wrote:
>
> >It still is decoupled, only nested ;-) Nesting it
> in ActionForm you
> >keep its state and get it populated from request.
> You can do the same
> >for unit test: keep the state and populate.
> >
> >
> Hmm, yeah, I suppose. I guess in this case I felt
> that the stuff in the
> object in question weren't necessarily being
> populated from a request.
> For instance, I carry might around a user object in
> the session that
> contains some info from the user table, but other
> stuff that gets added
> during web-app travel or is calculated somehow, etc.
>
> Basically non-request, potentially non-db, etc.
>
> >A little bit offtopic: say you have a New User
> Registration form. Your
> >business object for userinfo contains username and
> password, but does
> >not contain retyped password, because retyped
> password is not part of
> >business data, it is needed for input verification
> only. How would you
> >test "Adding a new user" use case without
> ActionForm or additional
> >wrapper around your Accout object?
> >
> >
> I'd "functional-test" the web app, and unit-test the
> business logic.
>
> That is, I have standalone unit tests that add a new
> user given the
> username, password, whatever else the business side
> expected, and I
> check the results of the business logic.
>
> I also have client-oriented web-app tests that make
> sure forms contain
> all expected fields and validate properly, then
> submit the form, and
> makes sure that the web-app continues to the
> appropriate place with the
> appropriate content based on the results of the form
> submission.
>
> >This is what I implemented about a year ago: a
> wrapper around business
> >object, which contains business object itself and
> UI-only fields plus
> >error messages relevant to this object only.
> >
> What do you mean the ActionForm contains the error
> messages relevant to
> this object only?
>
> I've been struggling with finding a good way to
> encapsulate errors,
> return messages, etc. from specific pages; so far
> I've been putting them
> in the properties file but I'm not a huge fan of the
> ad-hoc solution
> I've developed. Right now it's too much trouble to
> standalone-test.
>
> Dave
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> user-unsubscribe@struts.apache.org
> For additional commands, e-mail:
> user-help@struts.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Re: Facade in the view
Posted by Dave Newton <ne...@pingsite.com>.
Michael Jouravlev wrote:
>It still is decoupled, only nested ;-) Nesting it in ActionForm you
>keep its state and get it populated from request. You can do the same
>for unit test: keep the state and populate.
>
>
Hmm, yeah, I suppose. I guess in this case I felt that the stuff in the
object in question weren't necessarily being populated from a request.
For instance, I carry might around a user object in the session that
contains some info from the user table, but other stuff that gets added
during web-app travel or is calculated somehow, etc.
Basically non-request, potentially non-db, etc.
>A little bit offtopic: say you have a New User Registration form. Your
>business object for userinfo contains username and password, but does
>not contain retyped password, because retyped password is not part of
>business data, it is needed for input verification only. How would you
>test "Adding a new user" use case without ActionForm or additional
>wrapper around your Accout object?
>
>
I'd "functional-test" the web app, and unit-test the business logic.
That is, I have standalone unit tests that add a new user given the
username, password, whatever else the business side expected, and I
check the results of the business logic.
I also have client-oriented web-app tests that make sure forms contain
all expected fields and validate properly, then submit the form, and
makes sure that the web-app continues to the appropriate place with the
appropriate content based on the results of the form submission.
>This is what I implemented about a year ago: a wrapper around business
>object, which contains business object itself and UI-only fields plus
>error messages relevant to this object only.
>
What do you mean the ActionForm contains the error messages relevant to
this object only?
I've been struggling with finding a good way to encapsulate errors,
return messages, etc. from specific pages; so far I've been putting them
in the properties file but I'm not a huge fan of the ad-hoc solution
I've developed. Right now it's too much trouble to standalone-test.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Re: Facade in the view
Posted by Michael Jouravlev <jm...@gmail.com>.
On 9/20/05, Dave Newton <ne...@pingsite.com> wrote:
> Michael Jouravlev wrote:
>
> >Or... you can set Product object as nested property of an ActionForm,
> >and set ActionForm's scope to "session". The result is the same, but
> >seems more natural to me. You can render Product on JSP page, or
> >populate it from input (Struts will do it for you).
> >
> >
> True.
>
> But then you've tied at least part of your app to Struts, which makes
> standalone unit testing more difficult than (I feel ;) it needs to be!
> With the decoupling you can trivially test business logic that depends
> on state.
It still is decoupled, only nested ;-) Nesting it in ActionForm you
keep its state and get it populated from request. You can do the same
for unit test: keep the state and populate.
A little bit offtopic: say you have a New User Registration form. Your
business object for userinfo contains username and password, but does
not contain retyped password, because retyped password is not part of
business data, it is needed for input verification only. How would you
test "Adding a new user" use case without ActionForm or additional
wrapper around your Accout object? So, Account object still has to be
tied to something else, if not to ActionForm, then to some other
view/model wrapper.
This is what I implemented about a year ago: a wrapper around business
object, which contains business object itself and UI-only fields plus
error messages relevant to this object only. Worked great, so I
basically use ActionForm only as hollow container, as a facilitator to
populate fields with input data, because Struts populates properties
of ActionForm only.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
[OT] Re: Facade in the view
Posted by Dave Newton <ne...@pingsite.com>.
Michael Jouravlev wrote:
>Or... you can set Product object as nested property of an ActionForm,
>and set ActionForm's scope to "session". The result is the same, but
>seems more natural to me. You can render Product on JSP page, or
>populate it from input (Struts will do it for you).
>
>
True.
But then you've tied at least part of your app to Struts, which makes
standalone unit testing more difficult than (I feel ;) it needs to be!
With the decoupling you can trivially test business logic that depends
on state.
<third-grade>
One two three four, I declare a religion war!
</third-grade smiley="true" too-geeky-for-own-good="really-really-true">
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Facade in the view
Posted by Michael Jouravlev <jm...@gmail.com>.
Or... you can set Product object as nested property of an ActionForm,
and set ActionForm's scope to "session". The result is the same, but
seems more natural to me. You can render Product on JSP page, or
populate it from input (Struts will do it for you).
Michael
On 9/20/05, Jadeler <ja...@yahoo.ca> wrote:
> To better maintain all the data, I am opting not
> having alot of session variables but instead maintain
> one object that will contain all data needed and store
> that in a session. For example, instead of having
> session.setAttribute("product", product),
> session.setAttribute("web_preference", webPreference),
> etc. just create an object like this which can then be
> stored in a session:
>
> public class UserContainer{
> private Product product;
> private WebPreference webPreference;
>
> public Product getProduct () {
> return product;
> }
>
> public void setProduct(Product newProduct){
> product= newProduct;
> }
> }
>
> and in the jsp page have something like this
>
> <% UserContainer userContainer = (UserContainer)
> session.getAttribute(Constants.USER_CONTAINER_KEY); %>
>
> Do you guys do something similar or any other
> recommendations?
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Facade in the view
Posted by Dave Newton <ne...@pingsite.com>.
Jadeler wrote:
>To better maintain all the data, I am opting not
>having alot of session variables but instead maintain
>one object that will contain all data needed and store
>that in a session. [...]
>
>Do you guys do something similar or any other recommendations?
>
>
I generally do something similar.
For one reason, I can encapsulate state within a single object when I
can then use for testing.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org