You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Vincent <v-...@ifrance.com> on 2005/07/08 01:15:29 UTC
Using struts forms as Value Objects: your opinion?
Hi,
I'm currently designing and developping an enterprise J2EE application
based on Struts.
In this application there's a layer of Data Access Object which abstract
the underlying persistent storage.
For populating my struts' *Form I've imagined first a transfert between
forms and DAO based on Value Object, associated with helper classes for
translating from one type to another.
And I realized that struts Form can be in some situations quite good
transfert objects, and by doing so we economize development of both
helper classes and VO classes.
What do you thing about using forms as VO? Do you think it's a dirty
solution? Forms are often mirrors of the database's table.
Thank you for your opinion.
Vincent.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: read init parameters in action
Posted by Borislav Sabev <b....@eventsoft.de>.
Sure, here it is:
1. this snippet you have to add to your stuts-config.xml
<plug-in
className="com.mycompany.myproduct.servlet.InitPlugin"></plug-in>
2. this is the plugin-code:
public class InitPlugin implements org.apache.struts.action.PlugIn {
public void destroy() {
try {
HibernateUtil.destroySessionFactory();
} catch (Exception e) {
log.error(e.getMessage());
e.printStackTrace();
}
}
public void init(ActionServlet arg0, ModuleConfig arg1) throws
ServletException {
try {
HibernateUtil.initSessionFactory();
Locale locale = Locale.getDefault();
DateLocaleConverter converter = new DateLocaleConverter(
locale, FormatUtils.getDatePattern(), false);
converter.setLenient(true);
ConvertUtils.register(converter, Date.class);
ImagesManager.setImagesStoragePath(arg0);
} catch (Exception e) {
log.error(e.getMessage());
e.printStackTrace();
}
}
}
Cheers
Borislav
Tony Smith wrote:
>Thanks. Could you show me how to write such plug-in?
>
>
>
>--- Borislav Sabev <b....@eventsoft.de> wrote:
>
>
>
>>I think there are 2 cases:
>>1. you need a param that is available to the Servlet
>>and is not uniquie
>>to any particular Action
>> for eample in my application users can uppload
>>images, so after the
>>upload I store them in a subfolder in the
>>application. here is how I do it:
>> a. this snippet I add in web.xml in
>><servlet> tag
>> <init-param>
>>
>><param-name>imagesstorage</param-name>
>>
>><param-value>store_images</param-value>
>> </init-param>
>> b. here is the code to get the param
>>in one of the
>>actions (in fact I do this in one plugin because
>>this path is constant
>>all the time, so I read it only on startup)
>> StringBuilder path = new
>>StringBuilder();
>>
>>
>>
>>
>path.append(servlet.getServletConfig().getServletContext().getRealPath("/"));
>
>
>>
>>
>>
>>
>path.append(servlet.getServletConfig().getInitParameter("imagesstorage"));
>
>
>>2. every separate Action needs some initial
>>parameter.
>> In this case why do you need to put as an init
>>param? it's enough
>>just to have static field in the Action class ...
>>
>>I hope this is usefull for you.
>>
>>Borislav
>>
>>
>>
>>
>>
>>>For traditional servlets, you can set init
>>>
>>>
>>parameters
>>
>>
>>>in the web.xml and read it in a static init method
>>>
>>>
>>in
>>
>>
>>>servlet class. Can I have similar things for
>>>
>>>
>>action?
>>
>>
>>>If I need some of these init parameter for my web
>>>
>>>
>>app,
>>
>>
>>>what is the best way to do it with struts?
>>>
>>>Thansk,
>>>
>>>
>>>
Re: read init parameters in action
Posted by Tony Smith <qu...@yahoo.com>.
Thanks. Could you show me how to write such plug-in?
--- Borislav Sabev <b....@eventsoft.de> wrote:
> I think there are 2 cases:
> 1. you need a param that is available to the Servlet
> and is not uniquie
> to any particular Action
> for eample in my application users can uppload
> images, so after the
> upload I store them in a subfolder in the
> application. here is how I do it:
> a. this snippet I add in web.xml in
> <servlet> tag
> <init-param>
>
> <param-name>imagesstorage</param-name>
>
> <param-value>store_images</param-value>
> </init-param>
> b. here is the code to get the param
> in one of the
> actions (in fact I do this in one plugin because
> this path is constant
> all the time, so I read it only on startup)
> StringBuilder path = new
> StringBuilder();
>
>
path.append(servlet.getServletConfig().getServletContext().getRealPath("/"));
>
>
path.append(servlet.getServletConfig().getInitParameter("imagesstorage"));
>
>
> 2. every separate Action needs some initial
> parameter.
> In this case why do you need to put as an init
> param? it's enough
> just to have static field in the Action class ...
>
> I hope this is usefull for you.
>
> Borislav
>
>
>
> >For traditional servlets, you can set init
> parameters
> >in the web.xml and read it in a static init method
> in
> >servlet class. Can I have similar things for
> action?
> >If I need some of these init parameter for my web
> app,
> >what is the best way to do it with struts?
> >
> >Thansk,
> >
> >
> >
> >__________________________________________________
> >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
> >
> >
> >
> >
> >
>
>
> --
>
> Mit freundlichen Grüßen
>
> Borislav Sabev
>
> eventsoft GmbH
> Max-Planck-Str. 3
> 85716 Unterschleißheim
> Tel: 089 - 35 89 03 21
> Fax: 089 - 35 89 03 70
>
> b.sabev@eventsoft.de
> www.eventsoft.de
>
>
> >
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> user-unsubscribe@struts.apache.org
> For additional commands, e-mail:
user-help@struts.apache.org
____________________________________________________
Sell on Yahoo! Auctions no fees. Bid on great items.
http://auctions.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: read init parameters in action
Posted by Borislav Sabev <b....@eventsoft.de>.
I think there are 2 cases:
1. you need a param that is available to the Servlet and is not uniquie
to any particular Action
for eample in my application users can uppload images, so after the
upload I store them in a subfolder in the application. here is how I do it:
a. this snippet I add in web.xml in <servlet> tag
<init-param>
<param-name>imagesstorage</param-name>
<param-value>store_images</param-value>
</init-param>
b. here is the code to get the param in one of the
actions (in fact I do this in one plugin because this path is constant
all the time, so I read it only on startup)
StringBuilder path = new StringBuilder();
path.append(servlet.getServletConfig().getServletContext().getRealPath("/"));
path.append(servlet.getServletConfig().getInitParameter("imagesstorage"));
2. every separate Action needs some initial parameter.
In this case why do you need to put as an init param? it's enough
just to have static field in the Action class ...
I hope this is usefull for you.
Borislav
>For traditional servlets, you can set init parameters
>in the web.xml and read it in a static init method in
>servlet class. Can I have similar things for action?
>If I need some of these init parameter for my web app,
>what is the best way to do it with struts?
>
>Thansk,
>
>
>
>__________________________________________________
>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
>
>
>
>
>
--
Mit freundlichen Grüßen
Borislav Sabev
eventsoft GmbH
Max-Planck-Str. 3
85716 Unterschleißheim
Tel: 089 - 35 89 03 21
Fax: 089 - 35 89 03 70
b.sabev@eventsoft.de
www.eventsoft.de
read init parameters in action
Posted by Tony Smith <qu...@yahoo.com>.
For traditional servlets, you can set init parameters
in the web.xml and read it in a static init method in
servlet class. Can I have similar things for action?
If I need some of these init parameter for my web app,
what is the best way to do it with struts?
Thansk,
__________________________________________________
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
access entries in MessageResources.properties from java code
Posted by Tony Smith <qu...@yahoo.com>.
How can I access entries in
"MessageResources.properties" inside Action or Form
code?
Thanks,
--- Rick Reumann <st...@reumann.net> wrote:
> Hubert Rabago wrote the following on 7/8/2005 12:24
> AM:
> > There are several
> > reasons why you shouldn't use VOs as your form
> beans and vice versa
> > (as other msgs in this thread explain).
>
> Actually in this thread so far I haven't heard
> anyone explain why they
> are a 'bad' idea. The only way I see it being 'sort
> of' bad would be if...
>
> 1) You insist upon using the validation framework by
> having validation
> take place by setting validation="true" in your
> struts-config mappings.
> (I like to call validation manually in my Actions so
> this isn't really a
> problem - it's like an extra line or two of code).
>
> 2) Sometimes you have some odd non-VO type
> properties that you want to
> send to your Action. If you insist these needed to
> be captured by some
> kind of bean/ActionForm than yea I guess that's a
> minor problem... but
> what's the big deal about using an occasional
> request.getParameter("")
> or since you are using Struts you still 'have' to
> use an ActionForm just
> add the VO as a property and you can still a few
> other misc fields if
> you so desire.
>
> ActionForm == "The Black Sheep of Struts" :)
>
> --
> Rick
>
>
---------------------------------------------------------------------
> 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: Using struts forms as Value Objects: your opinion?
Posted by Rick Reumann <st...@reumann.net>.
Hubert Rabago wrote the following on 7/8/2005 12:24 AM:
> There are several
> reasons why you shouldn't use VOs as your form beans and vice versa
> (as other msgs in this thread explain).
Actually in this thread so far I haven't heard anyone explain why they
are a 'bad' idea. The only way I see it being 'sort of' bad would be if...
1) You insist upon using the validation framework by having validation
take place by setting validation="true" in your struts-config mappings.
(I like to call validation manually in my Actions so this isn't really a
problem - it's like an extra line or two of code).
2) Sometimes you have some odd non-VO type properties that you want to
send to your Action. If you insist these needed to be captured by some
kind of bean/ActionForm than yea I guess that's a minor problem... but
what's the big deal about using an occasional request.getParameter("")
or since you are using Struts you still 'have' to use an ActionForm just
add the VO as a property and you can still a few other misc fields if
you so desire.
ActionForm == "The Black Sheep of Struts" :)
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Using struts forms as Value Objects: your opinion?
Posted by Hubert Rabago <hr...@gmail.com>.
Vincent,
Before you go this route, check out FormDef plugin first.
http://formdef.dev.java.net
It will register Struts forms based on your VOs. There are several
reasons why you shouldn't use VOs as your form beans and vice versa
(as other msgs in this thread explain). FormDef would allow you the
development savings you mention and also has functionality to
translate from one to the other.
Hubert
On 7/7/05, Vincent <v-...@ifrance.com> wrote:
> Hi,
>
> I'm currently designing and developping an enterprise J2EE application
> based on Struts.
> In this application there's a layer of Data Access Object which abstract
> the underlying persistent storage.
> For populating my struts' *Form I've imagined first a transfert between
> forms and DAO based on Value Object, associated with helper classes for
> translating from one type to another.
> And I realized that struts Form can be in some situations quite good
> transfert objects, and by doing so we economize development of both
> helper classes and VO classes.
>
> What do you thing about using forms as VO? Do you think it's a dirty
> solution? Forms are often mirrors of the database's table.
>
> Thank you for your opinion.
>
> Vincent.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Using struts forms as Value Objects: your opinion?
Posted by Larry Meadors <la...@gmail.com>.
I usually build my ActionForm classes with the VO on it as a property.
The String properties can be just refered to as bean.property on the jsp.
Any non-string properties I map to the bean in the action form, with
the translation - so if there is a date, for instance, the property on
the action form might be someDate, and in it's setter, i store the
string, parse it using a dateformat object, and store it into the bean
if it is a valid format. If the format is bad, i keep the string for
display back to the user.
That way, by the time the action gets the form the bean has all the
properties and the types are correct.
Larry
On 7/7/05, Vincent <v-...@ifrance.com> wrote:
> Hi,
>
> I'm currently designing and developping an enterprise J2EE application
> based on Struts.
> In this application there's a layer of Data Access Object which abstract
> the underlying persistent storage.
> For populating my struts' *Form I've imagined first a transfert between
> forms and DAO based on Value Object, associated with helper classes for
> translating from one type to another.
> And I realized that struts Form can be in some situations quite good
> transfert objects, and by doing so we economize development of both
> helper classes and VO classes.
>
> What do you thing about using forms as VO? Do you think it's a dirty
> solution? Forms are often mirrors of the database's table.
>
> Thank you for your opinion.
>
> Vincent.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Using struts forms as Value Objects: your opinion?
Posted by Ted Husted <te...@gmail.com>.
On 7/8/05, Laurie Harper <la...@holoweb.net> wrote:
> Personally I prefer to keep form beans and value objects seperate, for two
> key reasons:
+1 == me too.
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] olipmic rings metaphor
Posted by Borislav Sabev <b....@eventsoft.de>.
Martin Gainty wrote:
> Boris-
> I see Security as implemented by RingBearer Frodo in Lord of the Rings
> The caretaker of the ring travels thru all domains and access to the
> other dimension (portal which contains final results) regardless of
> any domain he travels thru
> Begreife?
> Martin-
Since I'm not a big fan of Frodo and company, I like the Ted's methaphor
of torch much understandable (at least for me) :-)
Anyway the idea behind is the same.
BTW, i often use ThreadLocals to save such objects that have to make a
round trip through all the layers - but this is not a universal approcah.
Regards
Borislav (or Boris)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] olipmic rings metaphor
Posted by Martin Gainty <mg...@hotmail.com>.
Boris-
I see Security as implemented by RingBearer Frodo in Lord of the Rings
The caretaker of the ring travels thru all domains and access to the other
dimension (portal which contains final results) regardless of any domain he
travels thru
Begreife?
Martin-
----- Original Message -----
From: "Borislav Sabev" <b....@eventsoft.de>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Wednesday, July 13, 2005 12:54 PM
Subject: [OT] olipmic rings metaphor
> Ted Husted wrote:
>
>>In my own work, I tend to think of an enterprise-grade application as
>>a set of overlapping rings, like the Olympics logo.
>>
>>* http://www.olympic.org/
>>
>>In the Blue ring live the view members, like custom tags or UI
>>components, and the HTTP request and response objects. This is the
>>layer where our appliction interacts with the rest of the world.
>>
>>Some of the Blue ring members also interact with the presentation
>>controller components that live in the Gold ring, like the Struts
>>Actions, ActionForms, and JSF backing beans. This is the layer that
>>"interprets user gestures" to decide which view to display next, and
>>may also convert or format data as needed.
>>
>>In turn, Gold ring components interact with your own business objects,
>>which live in the Black ring. The business compnents could also be
>>chains of commands, representing services, rather than conventional
>>object representing domain entities. This layer often acts as a
>>"liaison" between the view-centric Blue and Gold rings, and the
>>data-centric Green and Red rings.
>>
>>To be useful, most business objects need to access persistent data.
>>Rather than talk to the native database API, most of us use data
>>access objects, that live in the Green ring. Here we find components
>>like iBATIS or Hibernate, JDO, or just plain JDBC. This layer links
>>specific business methods to general-purpose persistence methods.
>>
>>Finally, in the Red ring, we find our dragon -- the physical database.
>>In some applications, the database is a deep crimson that represents
>>our solution to the domain's problems. Other times, the domain logic
>>lives in the black ring, and the red ring is a pale pink shoebox.
>>
>>In some applications, the rings are separated by framework or package
>>lines, like Struts and iBATIS. In other applications, the rings may
>>exist as separate classes in the same package, or even different
>>methods on the same class. But, eventually, in my experience, any
>>long-lived, well-factored application will find itself using all five
>>rings, or all five separations of concern, in one way or the other.
>>
>>Of course, in a conventional MVC application, the Black and Blue rings
>>intersect, forming a triad, and the Green and Red rings are not
>>described. Though, I expect, the other rings did still exist, but were
>>simply hidden behind the event horizon of MVC's Black ring.
>>
>>-Ted.
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>>
> Hi Ted,
>
> How do you classify Security and Authorization issues in this metaphor?
>
> In my current project I have troubles since code that is related somehow
> to Authorization is spread over all "rings. Still it's difficult to me
> to have a clear understanding how to implement in a nice, consistent
> way. I'll appreciate any suggestions or recommendations about this
> problem.
>
> Regards
> Borislav
>
>
--------------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] olipmic rings metaphor - LDAP?
Posted by Larry Meadors <la...@gmail.com>.
LDAP is commonly used for security systems (for example: M$ Active
Directory and Novell's NDS are both LDAP implementations), and so
using them for applications (instead of a database) lets you leverage
existing security settings so you do not have to duplicate them.
Larry
On 7/15/05, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> Frank W. Zammetti on 14/07/05 17:39, wrote:
> We have completely externalized security from all our applications and
> > have built a fairly robust Security Framework, on top of J2EE security and
> > LDAP. Further, we are now taking customization and adding it in.
> >
> > Currently, once a user is authenticated and authorized, it is only THEN
> > that the application code begins. The application can make simple queries
> > to get basic user info (name, group, whatever attributes are stored in
> > LDAP), but things like "what can this particular user do within this
> > particular app" is still within each app. This is what we are
> > generalizing and moving out to the framework now. We have some good ideas
> > about doing this, and keeping it generic enough to work across-the-board,
> > but I suppose we'll know if we succeeded in a few months.
>
>
> Going slightly OT but the thread's OT anyway, why does LDAP exist or why
> does it get used so much? What advantages does it have over a database,
> which all applications have anyway? Why add another technology to the mix?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] olipmic rings metaphor - LDAP?
Posted by Laurie Harper <la...@holoweb.net>.
Frank W. Zammetti wrote:
> Not sure I have an answer for that :) My guess would be because of the
> first letter in the acronynm: Lightweight. Otherwise, your question seems
> reasonable to me.
Yep, the 'lightweight' is certainly a key factor. LDAP is optimized toward
high read volume, low write volume applications so directories can
genereally serve queries faster than RDBMSs at the expense of slower
updates. In practice, though, LDAP is non-transactional and a poor
substitute for a database if you need to do more than provide a repository
for user profile information.
LDAP directories are typically used for identity management solutions, for
centralizing user profile data and for 'white pages' type contact databases.
L.
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/~laurie/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] olipmic rings metaphor - LDAP?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Not sure I have an answer for that :) My guess would be because of the
first letter in the acronynm: Lightweight. Otherwise, your question seems
reasonable to me.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Fri, July 15, 2005 6:41 am, Adam Hardy said:
> Frank W. Zammetti on 14/07/05 17:39, wrote:
> We have completely externalized security from all our applications and
>> have built a fairly robust Security Framework, on top of J2EE security
>> and
>> LDAP. Further, we are now taking customization and adding it in.
>>
>> Currently, once a user is authenticated and authorized, it is only THEN
>> that the application code begins. The application can make simple
>> queries
>> to get basic user info (name, group, whatever attributes are stored in
>> LDAP), but things like "what can this particular user do within this
>> particular app" is still within each app. This is what we are
>> generalizing and moving out to the framework now. We have some good
>> ideas
>> about doing this, and keeping it generic enough to work
>> across-the-board,
>> but I suppose we'll know if we succeeded in a few months.
>
>
> Going slightly OT but the thread's OT anyway, why does LDAP exist or why
> does it get used so much? What advantages does it have over a database,
> which all applications have anyway? Why add another technology to the mix?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] olipmic rings metaphor - LDAP?
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Frank W. Zammetti on 14/07/05 17:39, wrote:
We have completely externalized security from all our applications and
> have built a fairly robust Security Framework, on top of J2EE security and
> LDAP. Further, we are now taking customization and adding it in.
>
> Currently, once a user is authenticated and authorized, it is only THEN
> that the application code begins. The application can make simple queries
> to get basic user info (name, group, whatever attributes are stored in
> LDAP), but things like "what can this particular user do within this
> particular app" is still within each app. This is what we are
> generalizing and moving out to the framework now. We have some good ideas
> about doing this, and keeping it generic enough to work across-the-board,
> but I suppose we'll know if we succeeded in a few months.
Going slightly OT but the thread's OT anyway, why does LDAP exist or why
does it get used so much? What advantages does it have over a database,
which all applications have anyway? Why add another technology to the mix?
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] olipmic rings metaphor
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
As far as security and authorization goes, where I work we very much view
it as, I suppose, a ring around the Olympic rings... perhaps a 100m track?
:)
We have completely externalized security from all our applications and
have built a fairly robust Security Framework, on top of J2EE security and
LDAP. Further, we are now taking customization and adding it in.
Currently, once a user is authenticated and authorized, it is only THEN
that the application code begins. The application can make simple queries
to get basic user info (name, group, whatever attributes are stored in
LDAP), but things like "what can this particular user do within this
particular app" is still within each app. This is what we are
generalizing and moving out to the framework now. We have some good ideas
about doing this, and keeping it generic enough to work across-the-board,
but I suppose we'll know if we succeeded in a few months.
I think validation gets into a whole other problem domain. We haven't
come up with that answer yet, Olympic analogy or not :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Wed, July 13, 2005 3:20 pm, Ted Husted said:
> On 7/13/05, Borislav Sabev <b....@eventsoft.de> wrote:
>> How do you classify Security and Authorization issues in this metaphor?
>>
>> In my current project I have troubles since code that is related somehow
>> to Authorization is spread over all "rings. Still it's difficult to me
>> to have a clear understanding how to implement in a nice, consistent
>> way. I'll appreciate any suggestions or recommendations about this
>> problem.
>
> The classic Layers pattern describes a systems layer that runs along
> all the layers, so that it is adjacent to each one.
>
> Many Struts applications run into this problem not only with
> authorization but with validation. We often want to have some
> validation on the client-side, to enhance the user experience and to
> reduce load on the server, but, we can't do all the validation
> client-side, because there are things that only the server can know.
> (Like if the credentials tendered are valid.)
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] olipmic rings metaphor
Posted by Ted Husted <te...@gmail.com>.
On 7/13/05, Borislav Sabev <b....@eventsoft.de> wrote:
> How do you classify Security and Authorization issues in this metaphor?
>
> In my current project I have troubles since code that is related somehow
> to Authorization is spread over all "rings. Still it's difficult to me
> to have a clear understanding how to implement in a nice, consistent
> way. I'll appreciate any suggestions or recommendations about this problem.
The classic Layers pattern describes a systems layer that runs along
all the layers, so that it is adjacent to each one.
Many Struts applications run into this problem not only with
authorization but with validation. We often want to have some
validation on the client-side, to enhance the user experience and to
reduce load on the server, but, we can't do all the validation
client-side, because there are things that only the server can know.
(Like if the credentials tendered are valid.)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] olipmic rings metaphor
Posted by Leon Rosenberg <st...@anotheria.net>.
> -----Ursprüngliche Nachricht-----
> Von: Borislav Sabev [mailto:b.sabev@eventsoft.de]
> Gesendet: Mittwoch, 13. Juli 2005 18:54
> An: Struts Users Mailing List
> Betreff: [OT] olipmic rings metaphor
>
> How do you classify Security and Authorization issues in this
> metaphor?
>
> In my current project I have troubles since code that is
> related somehow to Authorization is spread over all "rings.
> Still it's difficult to me to have a clear understanding how
> to implement in a nice, consistent way. I'll appreciate any
> suggestions or recommendations about this problem.
>
I think each layer has its own security and authorization sublayers (a layer
itself can be composed of multiple layers) in the corba world better known
as interruptors. But each layer should only make decision based on the
knowledge which the layer itself posseses.
So the presentation layer decides whether a user is allowed to execute a
specific use case by checking user's permissions and roles.
The business layer decides whether the specific method can be called from
specific caller (a host for example), and the persistence layer decides
which process/host can access the database. If you think about what you want
to protect from whom, and act accordingly.
I think it makes little sense to have a per-user check in the business
layer, since access controls are best in front of something not behind it or
within. But its just an opinion.
Regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
[OT] olipmic rings metaphor
Posted by Borislav Sabev <b....@eventsoft.de>.
Ted Husted wrote:
>In my own work, I tend to think of an enterprise-grade application as
>a set of overlapping rings, like the Olympics logo.
>
>* http://www.olympic.org/
>
>In the Blue ring live the view members, like custom tags or UI
>components, and the HTTP request and response objects. This is the
>layer where our appliction interacts with the rest of the world.
>
>Some of the Blue ring members also interact with the presentation
>controller components that live in the Gold ring, like the Struts
>Actions, ActionForms, and JSF backing beans. This is the layer that
>"interprets user gestures" to decide which view to display next, and
>may also convert or format data as needed.
>
>In turn, Gold ring components interact with your own business objects,
>which live in the Black ring. The business compnents could also be
>chains of commands, representing services, rather than conventional
>object representing domain entities. This layer often acts as a
>"liaison" between the view-centric Blue and Gold rings, and the
>data-centric Green and Red rings.
>
>To be useful, most business objects need to access persistent data.
>Rather than talk to the native database API, most of us use data
>access objects, that live in the Green ring. Here we find components
>like iBATIS or Hibernate, JDO, or just plain JDBC. This layer links
>specific business methods to general-purpose persistence methods.
>
>Finally, in the Red ring, we find our dragon -- the physical database.
>In some applications, the database is a deep crimson that represents
>our solution to the domain's problems. Other times, the domain logic
>lives in the black ring, and the red ring is a pale pink shoebox.
>
>In some applications, the rings are separated by framework or package
>lines, like Struts and iBATIS. In other applications, the rings may
>exist as separate classes in the same package, or even different
>methods on the same class. But, eventually, in my experience, any
>long-lived, well-factored application will find itself using all five
>rings, or all five separations of concern, in one way or the other.
>
>Of course, in a conventional MVC application, the Black and Blue rings
>intersect, forming a triad, and the Green and Red rings are not
>described. Though, I expect, the other rings did still exist, but were
>simply hidden behind the event horizon of MVC's Black ring.
>
>-Ted.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
Hi Ted,
How do you classify Security and Authorization issues in this metaphor?
In my current project I have troubles since code that is related somehow
to Authorization is spread over all "rings. Still it's difficult to me
to have a clear understanding how to implement in a nice, consistent
way. I'll appreciate any suggestions or recommendations about this problem.
Regards
Borislav
Re: Using struts forms as Value Objects: your opinion?
Posted by Ted Husted <te...@gmail.com>.
There's probably something to that, Leon.
Of course, there's nothing new here, except maybe the metaphor. Using
the layers pattern in enteprise applications is well known. I believe
Bushman describes it in POSA. Here's another online treatment:
* http://www.stevenblack.com/PTN-Layers.asp
-Ted.
On 7/11/05, Leon Rosenberg <st...@anotheria.net> wrote:
> Some time ago I tried to postulate an enterprise application as a
> row of mvc patterns each using the previous one as the model, and everyone
> laughed at me :-)
>
> Now this is the same, with a nicer metaphor :-)
>
> Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Using struts forms as Value Objects: your opinion?
Posted by Craig McClanahan <cr...@gmail.com>.
On 7/11/05, Laurie Harper <la...@holoweb.net> wrote:
>
> Most of my validation is handled by the Validator framework right now
> which, admitedly, ties things to Struts to some extent (though there's no
> reason I couldn't pull Validator 'down' a level and use it under some other
> presentation technology if it didn't provide an equivalent.
>
Indeed, making this possible was a primary reason for separating
validator out of Struts and moving it to Jakarta Commons in the first
place. This has enabled lots of folks to use Commons Validator for
enforcing rules in the business tier (as opposed to the view tier) --
to say nothing of allowing Shale to leverage the client side
validation capabilities without depending on Struts 1.x code.
> L.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Using struts forms as Value Objects: your opinion?
Posted by Laurie Harper <la...@holoweb.net>.
Michael Jouravlev wrote:
> On 7/7/05, Laurie Harper <la...@holoweb.net> wrote:
> Is not it easier to have one nested VO/BO with string properties, than
> to copy properties back and forth from action form to VO? I use web
> framework only to expose my real objects to the outer world.
If you don't mind your VOs/BOs being untyped then sure, I guess it's
easier. Personally I'd rather use strongly typed interfaces as far as possible.
>>2) value objects should use typed interfaces to ensure marshaling to and
>>from presentation format (string types) is pushed as far up the application
>>stack as possible. This also enables other, potentially type-aware,
>>presentation / client tiers to be built on top of the same value objects
>>(e.g. for a web-services interface).
>
> I think I do not agree with this one. Let's take it as a design
> requirement that application that we build is a webapp. It potentially
> can have different interfaces. This would mean, that:
> * input data is stingified because of HTTP
> * Struts is not the only front end
Just because the transport protocol is HTTP doesn't mean you're only
dealing with string data though. If I add a web services layer, I'll want
ot talk in terms of domain types. If I want to add some other RPC mechanism
the same will be true.
> Therefore, it is much easier to create BO/VO with dual string/typed
> interface or with string interface only. It would do validation and
> conversion to native datatype internally instead of doing it in
> validate() method. I believen that this is more flexible approach.
> What are you going to do with your validation code, if you are told to
> move from Struts to WebWork or Tapestry?
I don't see the difference between having dual string/typed properites and
having the same thing split between two classes, other than making the one
class more confusing and error prone to use.
Most of my validation is handled by the Validator framework right now
which, admitedly, ties things to Struts to some extent (though there's no
reason I couldn't pull Validator 'down' a level and use it under some other
presentation technology if it didn't provide an equivalent.
L.
> On 7/8/05, Craig McClanahan <cr...@gmail.com> wrote:
>
>>Form beans are part of the *view* tier, not the model ... their
>>purpose in life is to represent the server side state of the HTML
>>elements on a form, even if that state is invalid (i.e. not currently
>>passing all the validations). That way, you can reproduce what the
>>user typed so he or she can fix it, rather than presenting them with a
>>completely blank screen. (This is why you generally use string fields
>>in a form bean).
>
>
> This is one way to look at things. Another way is to use VO/BO for
> input/output directly. When I use existing data, I load it into BO and
> display it. When I modify it, I update BO using its string properties.
> If I decide to cancel updates, I siply remove the BO from memory, no
> database changes needed. If I create a new object, I create a new BO
> and fill it in. Until I persist it, it hangs in the session. If I
> decide to cancel, then I remove it, and database would not even know
> that I was about to insert an object.
>
>
>>In a component oriented framework like JSF or Tapestry, you don't need
>>to worry about keeping track of this state information ... the
>>components do it for you.
>
>
> JSF still differentiates "real" object (whatever it might be, a real
> business object or a VO) from visual component data, which I don't
> like. From my point of view, it is much easier to have an object with
> an ID, to view/edit it, or to delete it. Therefore, I do not need
> viewstate for UI components. I only need to store my object somewhere
> like in session while I work with it. I want my widgets and my view to
> be as dumb as possible. All data and state that I need is in real
> objects, I do not need artificial viewstate to duplicate it.
>
> I can understand why JSF or ASP.NET went this route with UI objects
> and viewstate: to abstract from the model/business layer. They do not
> want to establish a firm contract with business/persistence layer.
> They do not want to require a certain BO lifecycle or the datatype
> limitations. But I as a developer find this inconvenient. Web
> frameworks designers focus on their framework, while I as an
> application designer, focus on business data, business process and
> business state.
>
> Take ActiveX. There is a contract, there are interfaces, methods and
> datatypes defined. Just build an object according to the protocol, and
> you will be able to have design-time interface, runtime interface,
> everything. Web frameworks do not want to have strict contracts with
> data layer probabaly to be more flexible. I would take contract over
> flexibily anytime. Presuming that this is a flexible contract ;-)
>
> Michael.
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/~laurie/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Using struts forms as Value Objects: your opinion?
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/11/05, Michael Jouravlev <jm...@gmail.com> wrote:
> JSF still differentiates "real" object (whatever it might be, a real
> business object or a VO) from visual component data, which I don't
> like. From my point of view, it is much easier to have an object with
> an ID, to view/edit it, or to delete it. Therefore, I do not need
> viewstate for UI components. I only need to store my object somewhere
> like in session while I work with it. I want my widgets and my view to
> be as dumb as possible. All data and state that I need is in real
> objects, I do not need artificial viewstate to duplicate it.
Before anyone corrects me, I want to say that I went a little
overboard ;) There are selection lists, treeviews and other objects
which do not have direct representation in the domain model. These
objects should be maintained by web framework.
I was talking primarily about input/output panels and about item
lists. Well, item list may be also considered as pure view object,
consisting of business objects... Whatever. In this case I was talking
about input/output panels only ;-)
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Using struts forms as Value Objects: your opinion?
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/7/05, Laurie Harper <la...@holoweb.net> wrote:
> Personally I prefer to keep form beans and value objects seperate, for two
> key reasons:
>
> 1) form beans generally should consist of String data to facilitate
> round-tripping of invalid inputs. I like to constrain them to a clearly
> defined role of marshaling data 'into' and 'out of' the presentation layer,
> i.e. across the boundary between presentation and application.
Is not it easier to have one nested VO/BO with string properties, than
to copy properties back and forth from action form to VO? I use web
framework only to expose my real objects to the outer world.
> 2) value objects should use typed interfaces to ensure marshaling to and
> from presentation format (string types) is pushed as far up the application
> stack as possible. This also enables other, potentially type-aware,
> presentation / client tiers to be built on top of the same value objects
> (e.g. for a web-services interface).
I think I do not agree with this one. Let's take it as a design
requirement that application that we build is a webapp. It potentially
can have different interfaces. This would mean, that:
* input data is stingified because of HTTP
* Struts is not the only front end
Therefore, it is much easier to create BO/VO with dual string/typed
interface or with string interface only. It would do validation and
conversion to native datatype internally instead of doing it in
validate() method. I believen that this is more flexible approach.
What are you going to do with your validation code, if you are told to
move from Struts to WebWork or Tapestry?
On 7/8/05, Craig McClanahan <cr...@gmail.com> wrote:
> Form beans are part of the *view* tier, not the model ... their
> purpose in life is to represent the server side state of the HTML
> elements on a form, even if that state is invalid (i.e. not currently
> passing all the validations). That way, you can reproduce what the
> user typed so he or she can fix it, rather than presenting them with a
> completely blank screen. (This is why you generally use string fields
> in a form bean).
This is one way to look at things. Another way is to use VO/BO for
input/output directly. When I use existing data, I load it into BO and
display it. When I modify it, I update BO using its string properties.
If I decide to cancel updates, I siply remove the BO from memory, no
database changes needed. If I create a new object, I create a new BO
and fill it in. Until I persist it, it hangs in the session. If I
decide to cancel, then I remove it, and database would not even know
that I was about to insert an object.
> In a component oriented framework like JSF or Tapestry, you don't need
> to worry about keeping track of this state information ... the
> components do it for you.
JSF still differentiates "real" object (whatever it might be, a real
business object or a VO) from visual component data, which I don't
like. From my point of view, it is much easier to have an object with
an ID, to view/edit it, or to delete it. Therefore, I do not need
viewstate for UI components. I only need to store my object somewhere
like in session while I work with it. I want my widgets and my view to
be as dumb as possible. All data and state that I need is in real
objects, I do not need artificial viewstate to duplicate it.
I can understand why JSF or ASP.NET went this route with UI objects
and viewstate: to abstract from the model/business layer. They do not
want to establish a firm contract with business/persistence layer.
They do not want to require a certain BO lifecycle or the datatype
limitations. But I as a developer find this inconvenient. Web
frameworks designers focus on their framework, while I as an
application designer, focus on business data, business process and
business state.
Take ActiveX. There is a contract, there are interfaces, methods and
datatypes defined. Just build an object according to the protocol, and
you will be able to have design-time interface, runtime interface,
everything. Web frameworks do not want to have strict contracts with
data layer probabaly to be more flexible. I would take contract over
flexibily anytime. Presuming that this is a flexible contract ;-)
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Using struts forms as Value Objects: your opinion?
Posted by Leon Rosenberg <st...@anotheria.net>.
Some time ago I tried to postulate an enterprise application as a
row of mvc patterns each using the previous one as the model, and everyone
laughed at me :-)
Now this is the same, with a nicer metaphor :-)
Leon
> -----Ursprüngliche Nachricht-----
> Von: news [mailto:news@sea.gmane.org] Im Auftrag von Laurie Harper
> Gesendet: Montag, 11. Juli 2005 18:31
> An: user@struts.apache.org
> Betreff: Re: Using struts forms as Value Objects: your opinion?
>
> Ted Husted wrote:
> > In my own work, I tend to think of an enterprise-grade
> application as
> > a set of overlapping rings, like the Olympics logo.
> >
> > * http://www.olympic.org/
> >
> > In the Blue ring...
>
> Nice analogy! :-)
>
> --
> Laurie, Open Source advocate, Java geek and novice blogger:
> http://www.holoweb.net/~laurie/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Using struts forms as Value Objects: your opinion?
Posted by Laurie Harper <la...@holoweb.net>.
Ted Husted wrote:
> In my own work, I tend to think of an enterprise-grade application as
> a set of overlapping rings, like the Olympics logo.
>
> * http://www.olympic.org/
>
> In the Blue ring...
Nice analogy! :-)
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/~laurie/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Using struts forms as Value Objects: your opinion?
Posted by Ted Husted <te...@gmail.com>.
On 7/8/05, Craig McClanahan <cr...@gmail.com> wrote:
> +1 as well, and this matches the historical reason that form beans
> were invented in the first place.
>
> Form beans are part of the *view* tier, not the model ... their
> purpose in life is to represent the server side state of the HTML
> elements on a form, even if that state is invalid (i.e. not currently
> passing all the validations). That way, you can reproduce what the
> user typed so he or she can fix it, rather than presenting them with a
> completely blank screen. (This is why you generally use string fields
> in a form bean).
>
> In a component oriented framework like JSF or Tapestry, you don't need
> to worry about keeping track of this state information ... the
> components do it for you. But in Struts it is the application
> developer's responsibility to understand the correct design patterns
> -- and this is one of the most fundamental principles of how Struts
> was designed.
Yes, compared to component-based frameworks, one feature ActionForms
provide is to act as an input buffer. Component controls have a
built-in string field, but since the Struts tags are not designed as
components, we need the ActionForms to provide the missing buffer.
Of course, ActionForms also provide for input validation, so they are
also more than a simple component buffer. One of the things that
confuse people about ActionForms is that they have a complex life
cycle, and serve different roles at different times.
Of course, there are many ways to reduce the ActionForm maintenance
burden. One strategy is to use a coarsely-grained ActionForm that
represents several (or all) of the input fields in your application,
and then subclass the base form to provide for different validations
(if needed). Another technique is to use a flavor of DynaActionForm.
In my own work, I tend to think of an enterprise-grade application as
a set of overlapping rings, like the Olympics logo.
* http://www.olympic.org/
In the Blue ring live the view members, like custom tags or UI
components, and the HTTP request and response objects. This is the
layer where our appliction interacts with the rest of the world.
Some of the Blue ring members also interact with the presentation
controller components that live in the Gold ring, like the Struts
Actions, ActionForms, and JSF backing beans. This is the layer that
"interprets user gestures" to decide which view to display next, and
may also convert or format data as needed.
In turn, Gold ring components interact with your own business objects,
which live in the Black ring. The business compnents could also be
chains of commands, representing services, rather than conventional
object representing domain entities. This layer often acts as a
"liaison" between the view-centric Blue and Gold rings, and the
data-centric Green and Red rings.
To be useful, most business objects need to access persistent data.
Rather than talk to the native database API, most of us use data
access objects, that live in the Green ring. Here we find components
like iBATIS or Hibernate, JDO, or just plain JDBC. This layer links
specific business methods to general-purpose persistence methods.
Finally, in the Red ring, we find our dragon -- the physical database.
In some applications, the database is a deep crimson that represents
our solution to the domain's problems. Other times, the domain logic
lives in the black ring, and the red ring is a pale pink shoebox.
In some applications, the rings are separated by framework or package
lines, like Struts and iBATIS. In other applications, the rings may
exist as separate classes in the same package, or even different
methods on the same class. But, eventually, in my experience, any
long-lived, well-factored application will find itself using all five
rings, or all five separations of concern, in one way or the other.
Of course, in a conventional MVC application, the Black and Blue rings
intersect, forming a triad, and the Green and Red rings are not
described. Though, I expect, the other rings did still exist, but were
simply hidden behind the event horizon of MVC's Black ring.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Using struts forms as Value Objects: your opinion?
Posted by Craig McClanahan <cr...@gmail.com>.
On 7/7/05, Laurie Harper <la...@holoweb.net> wrote:
> Vincent wrote:
> >
> > What do you thing about using forms as VO? Do you think it's a dirty
> > solution? Forms are often mirrors of the database's table.
>
> Personally I prefer to keep form beans and value objects seperate, for two
> key reasons:
>
+1 as well, and this matches the historical reason that form beans
were invented in the first place.
Form beans are part of the *view* tier, not the model ... their
purpose in life is to represent the server side state of the HTML
elements on a form, even if that state is invalid (i.e. not currently
passing all the validations). That way, you can reproduce what the
user typed so he or she can fix it, rather than presenting them with a
completely blank screen. (This is why you generally use string fields
in a form bean).
In a component oriented framework like JSF or Tapestry, you don't need
to worry about keeping track of this state information ... the
components do it for you. But in Struts it is the application
developer's responsibility to understand the correct design patterns
-- and this is one of the most fundamental principles of how Struts
was designed.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Using struts forms as Value Objects: your opinion?
Posted by Daniel Perry <d....@netcase.co.uk>.
> 1) form beans generally should consist of String data to facilitate
> round-tripping of invalid inputs. I like to constrain them to a clearly
> defined role of marshaling data 'into' and 'out of' the
> presentation layer,
> i.e. across the boundary between presentation and application.
This i would agree with. Fields in BO/VOs have various types. ActionForms
should only get/set strings.
>
> 2) value objects should use typed interfaces to ensure marshaling to and
> from presentation format (string types) is pushed as far up the
> application
> stack as possible. This also enables other, potentially type-aware,
> presentation / client tiers to be built on top of the same value objects
> (e.g. for a web-services interface).
>
> To address Micheal's question (why not just make value objects
> and business
> objects the same thing?), I'd point out that it can be valuable to
> distinguish between business rules and application logic. I find my
> business objects often have functionality I don't want called
> directly from
> the presentatin layer, particularly when using a mediation layer between
> the two.
>
> Essentially, though, it comes down to the complexity of the
> problem vs. the
> complexity of the solution. The more complex the application, the more it
> makes sense to partition responsibilities. For very simple
> applications it
> makes sense to collapse layers together.
I tend to merge BO,VO,and DAO all into one bean. I made a self-persistable
base bean (using OJB), and then just add fields with getters/setters. All
works nicely. Add any simple logic into the beans. Stick complex logic in
managers/helpers/services. I tend to pass these beans straight up to jsps
for pure displaying of stuff, but then use actionforms to edit/submit data.
A big timesaver can be to write a constructor for an action form that
accepts a BO and fills itself from that.
Daniel.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Using struts forms as Value Objects: your opinion?
Posted by Laurie Harper <la...@holoweb.net>.
Vincent wrote:
> I'm currently designing and developping an enterprise J2EE application
> based on Struts.
> In this application there's a layer of Data Access Object which abstract
> the underlying persistent storage.
> For populating my struts' *Form I've imagined first a transfert between
> forms and DAO based on Value Object, associated with helper classes for
> translating from one type to another.
> And I realized that struts Form can be in some situations quite good
> transfert objects, and by doing so we economize development of both
> helper classes and VO classes.
>
> What do you thing about using forms as VO? Do you think it's a dirty
> solution? Forms are often mirrors of the database's table.
Personally I prefer to keep form beans and value objects seperate, for two
key reasons:
1) form beans generally should consist of String data to facilitate
round-tripping of invalid inputs. I like to constrain them to a clearly
defined role of marshaling data 'into' and 'out of' the presentation layer,
i.e. across the boundary between presentation and application.
2) value objects should use typed interfaces to ensure marshaling to and
from presentation format (string types) is pushed as far up the application
stack as possible. This also enables other, potentially type-aware,
presentation / client tiers to be built on top of the same value objects
(e.g. for a web-services interface).
To address Micheal's question (why not just make value objects and business
objects the same thing?), I'd point out that it can be valuable to
distinguish between business rules and application logic. I find my
business objects often have functionality I don't want called directly from
the presentatin layer, particularly when using a mediation layer between
the two.
Essentially, though, it comes down to the complexity of the problem vs. the
complexity of the solution. The more complex the application, the more it
makes sense to partition responsibilities. For very simple applications it
makes sense to collapse layers together.
L.
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/~laurie/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Using struts forms as Value Objects: your opinion?
Posted by Leon Rosenberg <st...@anotheria.net>.
You said it would be an enterprise j2ee application, right?
So there is a chance it would be distributed once?
In this case using ActionForms as VO is an absolute NO GO !
Besides, if you want a clear architectural separation of layers its a NO GO
also!
The VO Objects are parts of your business logic interface (I hope you have
one) and ActionForm have nothing to do with business logic
or, even worse, DAOs.
A typical enterprise architecture is 3 layered:
Presentation with Actions / ActionForms / jsps
Business with business interfaces and VOs or DTOs (name it as you like it)
Persistence with DAOs
And, from practical experience, your Forms may seem to be mirrors of the
database at the beginning, but this will change as soon as your application
start to live (Think about collections for drop-downs for example).
Regards
Leon
> -----Ursprüngliche Nachricht-----
> Von: news [mailto:news@sea.gmane.org] Im Auftrag von Vincent
> Gesendet: Freitag, 8. Juli 2005 01:15
> An: user@struts.apache.org
> Betreff: Using struts forms as Value Objects: your opinion?
>
> Hi,
>
> I'm currently designing and developping an enterprise J2EE
> application based on Struts.
> In this application there's a layer of Data Access Object
> which abstract the underlying persistent storage.
> For populating my struts' *Form I've imagined first a
> transfert between forms and DAO based on Value Object,
> associated with helper classes for translating from one type
> to another.
> And I realized that struts Form can be in some situations
> quite good transfert objects, and by doing so we economize
> development of both helper classes and VO classes.
>
> What do you thing about using forms as VO? Do you think it's
> a dirty solution? Forms are often mirrors of the database's table.
>
> Thank you for your opinion.
>
> Vincent.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org