RE: Struts design flaw -- ActionForms are not true domain objects
I greatly appreciated your input.
We should aggree with the fact Struts is not an universal solution.
However it was good enough designed.
I think Struts 2.0 will be further powerful since it will go using
more interfaces instead of concrete classes, as somedoby posted it.
Thanks a lot putting out some Struts's concepts I was missing.
José.
-Original Message-
From: PILGRIM, Peter, FM [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 20, 2003 6:49 PM
To: 'Struts Users Mailing List'
Subject: RE: Struts design flaw -- ActionForms are not true
domain objects
-Original Message-
From: NYIMI Jose (BMB) [mailto:[EMAIL PROTECTED]]
Sent: 17 February 2003 14:37
To: Struts Users Mailing List
Subject: Struts design flaw -- ActionForms are not true
domain objects
Dear Struts Users,
I have just bought this book : Expert one-one-one J2EE
Design and Development by Rod Johnson.
http://www.wrox.com/news/852.htm
I will greatly appreciate to have your opinion about this so
beeing design flaw of Struts described in the above book.
Rod Johnson suggested an alternative framework that takes
strengths of following frameworks : Struts, Maverick and
WebWork, then offer solution to their weaknesses.
Codes are available at :
http://www.wrox.com/dynamic/books/download.aspx?isbn=186100784
1#downloads
Actually I got a copy of this book today myself for review
purposes, winning it in Expresso Framework open source
promotion. I waited to comment on this message until I had my
review copy in front of me. So I will be reading the next
section very carefully.
The Autor wrote the following :
Despite of its popularity, I'm not a big fan of Struts.It's
good enough, but far from an ideal J2EE web application framework:
My instant rebuttal is just that what is a J2EE web
application framework?
To me it seems that J2EE is a moving target. J2EE 1.0 was
about EJB and
now J2EE 1.4 is about web services.
Struts does not aim to be perfect J2EE framework. Like most
bits of open
source it was developed from an itch. Other people, I mean, software
developers caught on to it, why didn't I think about that?. This is
reason for it popularity. What makes Struts great, is the design, and
that is it. Form has definitely followed function.
* The ActionForm approach - central to Struts request
processing model - is poor. Bean binding is primitive,
meaning that only string properties are really useful. This
adds little value over simply querying request parameters.The
idea of copying properties from an action form to business
command is inelegant and there is o support for type checking.
I have to say that I have grown to love
``Commons BeanUtils.copyProperties'' and from
what I gather, the Author is unaware of this handy class.
He also misses the boat. Because ActionForm and the BeanUtils
support nested properties. In other words you can nest a value object
inside your action form and access directly it in a JSP. Ergo you
need not copy properties endlessly.
BigDecimal x = actionForm.getValueObject().getPrincipalAmount();
bean:write name=actionForm
property=valueObject.principalAmount /
or more JSTL c:out
value=${actionForm.valueObject.principalAmount} /
* Struts is too JSP-oriented, although it is possible to
use Struts with other templating technologies.
I heard of people using Velocity.
* Struts is based almost entirely on concrete classes.
This makes it hard to customize Struts's behavior.
I agree a little bit here. I am in the middle of extending or
integrating
Struts with Expresso, but I like the RequestProcessor and Plugin. They
are little god-sends.
* Although things have improved significantly with
version 1.1, the Struts codebase is poor. Not surprisingly,
there have been numerous deprecations in moving to 1.1.
Nonsense. Admittedly the javadoc was a little poor in 1.0, but
there is plently more infos in 1.1
* Struts ActionForms have several particularities that we
must consider. As all ActionForms must extend the Struts
superclass, they all depend on Struts and the Servlet API.
This means that they can not be passed to business objects,
as business objects shouldn't depend on a particular web
application framework or the Servlet API. Secondly, any
request parameters that may contain invalid data (such as
numeric inputs, for which the user might enter non-numeric
data) must be matched by ActionForm properties of type
String. The bean manipulation code behind the scenes will
attempt to convert string request parameters to the
appropriate type, but any exceptions in attempting to set
properties will result in the
org.apache.struts.util.RequestUtils class failing the request
by throwing a ServletException.
The bean manipulation, I think
RE: Struts design flaw -- ActionForms are not true domain objects
-Original Message-
From: NYIMI Jose (BMB) [mailto:[EMAIL PROTECTED]]
Sent: 17 February 2003 14:37
To: Struts Users Mailing List
Subject: Struts design flaw -- ActionForms are not true domain objects
Dear Struts Users,
I have just bought this book : Expert one-one-one J2EE
Design and Development by Rod Johnson.
http://www.wrox.com/news/852.htm
I will greatly appreciate to have your opinion about this so
beeing design flaw of Struts described in the above book.
Rod Johnson suggested an alternative framework that takes
strengths of following frameworks : Struts, Maverick and
WebWork, then offer solution to their weaknesses.
Codes are available at :
http://www.wrox.com/dynamic/books/download.aspx?isbn=186100784
1#downloads
Actually I got a copy of this book today myself for review purposes,
winning it in Expresso Framework open source promotion. I waited
to comment on this message until I had my review copy in front of
me. So I will be reading the next section very carefully.
The Autor wrote the following :
Despite of its popularity, I'm not a big fan of Struts.It's
good enough, but far from an ideal J2EE web application framework:
My instant rebuttal is just that what is a J2EE web application framework?
To me it seems that J2EE is a moving target. J2EE 1.0 was about EJB and
now J2EE 1.4 is about web services.
Struts does not aim to be perfect J2EE framework. Like most bits of open
source it was developed from an itch. Other people, I mean, software
developers caught on to it, why didn't I think about that?. This is
reason for it popularity. What makes Struts great, is the design, and
that is it. Form has definitely followed function.
* The ActionForm approach - central to Struts request
processing model - is poor. Bean binding is primitive,
meaning that only string properties are really useful. This
adds little value over simply querying request parameters.The
idea of copying properties from an action form to business
command is inelegant and there is o support for type checking.
I have to say that I have grown to love
``Commons BeanUtils.copyProperties'' and from
what I gather, the Author is unaware of this handy class.
He also misses the boat. Because ActionForm and the BeanUtils
support nested properties. In other words you can nest a value object
inside your action form and access directly it in a JSP. Ergo you
need not copy properties endlessly.
BigDecimal x = actionForm.getValueObject().getPrincipalAmount();
bean:write name=actionForm
property=valueObject.principalAmount /
or more JSTL c:out
value=${actionForm.valueObject.principalAmount} /
* Struts is too JSP-oriented, although it is possible to
use Struts with other templating technologies.
I heard of people using Velocity.
* Struts is based almost entirely on concrete classes.
This makes it hard to customize Struts's behavior.
I agree a little bit here. I am in the middle of extending or integrating
Struts with Expresso, but I like the RequestProcessor and Plugin. They
are little god-sends.
* Although things have improved significantly with
version 1.1, the Struts codebase is poor. Not surprisingly,
there have been numerous deprecations in moving to 1.1.
Nonsense. Admittedly the javadoc was a little poor in 1.0, but
there is plently more infos in 1.1
* Struts ActionForms have several particularities that we
must consider. As all ActionForms must extend the Struts
superclass, they all depend on Struts and the Servlet API.
This means that they can not be passed to business objects,
as business objects shouldn't depend on a particular web
application framework or the Servlet API. Secondly, any
request parameters that may contain invalid data (such as
numeric inputs, for which the user might enter non-numeric
data) must be matched by ActionForm properties of type
String. The bean manipulation code behind the scenes will
attempt to convert string request parameters to the
appropriate type, but any exceptions in attempting to set
properties will result in the
org.apache.struts.util.RequestUtils class failing the request
by throwing a ServletException.
The bean manipulation, I think this commons bean utils, can
make it hard to find out which attribute in the action form
is causing a problem. It needs to adopt the JSTL standard, of
having the option of allowing unknown to be prefixed and suffixed
with ?. Also when BeanUtils, fails, you dont know from the
exception which class failed or the value that is being converted.
* Thus a Struts ActionForm is not a true domain object.
It's a place to hold user data until it can be validated and
transferred into domain objects such commands. The advantage
of this approach is that invalid data can be re-displayed
easily. The disavantage is that we will need to get this data
into true domain object at some point,
Re: Struts design flaw -- ActionForms are not true domain objects
The author correctly states that ActionForms are not true domain objects. This is intentional. He also correctly points out that Struts uses too many concrete base classes. We will be working to use more interfaces over time. However, Struts is not too JSP oriented. JSP is the most popular Java user interface technology for web applications so it is appropriately supported by Struts taglibs. You can use *any* UI technology you want with Struts. David From: NYIMI Jose (BMB) [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Struts design flaw -- ActionForms are not true domain objects Date: Mon, 17 Feb 2003 15:37:13 +0100 Dear Struts Users, I have just bought this book : Expert one-one-one J2EE Design and Development by Rod Johnson. http://www.wrox.com/news/852.htm I will greatly appreciate to have your opinion about this so beeing design flaw of Struts described in the above book. Rod Johnson suggested an alternative framework that takes strengths of following frameworks : Struts, Maverick and WebWork, then offer solution to their weaknesses. Codes are available at : http://www.wrox.com/dynamic/books/download.aspx?isbn=1861007841#downloads The Autor wrote the following : Despite of its popularity, I'm not a big fan of Struts.It's good enough, but far from an ideal J2EE web application framework: * The ActionForm approach - central to Struts request processing model - is poor. Bean binding is primitive, meaning that only string properties are really useful. This adds little value over simply querying request parameters.The idea of copying properties from an action form to business command is inelegant and there is o support for type checking. * Struts is too JSP-oriented, although it is possible to use Struts with other templating technologies. * Struts is based almost entirely on concrete classes. This makes it hard to customize Struts's behavior. * Although things have improved significantly with version 1.1, the Struts codebase is poor. Not surprisingly, there have been numerous deprecations in moving to 1.1. * Struts ActionForms have several particularities that we must consider. As all ActionForms must extend the Struts superclass, they all depend on Struts and the Servlet API. This means that they can not be passed to business objects, as business objects shouldn't depend on a particular web application framework or the Servlet API. Secondly, any request parameters that may contain invalid data (such as numeric inputs, for which the user might enter non-numeric data) must be matched by ActionForm properties of type String. The bean manipulation code behind the scenes will attempt to convert string request parameters to the appropriate type, but any exceptions in attempting to set properties will result in the org.apache.struts.util.RequestUtils class failing the request by throwing a ServletException. * Thus a Struts ActionForm is not a true domain object. It's a place to hold user data until it can be validated and transferred into domain objects such commands. The advantage of this approach is that invalid data can be re-displayed easily. The disavantage is that we will need to get this data into true domain object at some point, so Struts has only taken us part of the way towards true data binding. * The need to derive ApplicationForms from a single superclass has always seemed to me a design flaw. Not only does it tie commands to the Struts framework and Servlet API, it incorrectly exposes inherited framework properties to update via data binding from request parameters. For example, adding a servlet parameter with a string value will break just about any page generated by 1.0 application (with a failure to set a property of ActionServlet to a string) . Struts 1.1 introduces a workaround for this particular problem, but the root of the problem is the whole ActionForm concept. * The ActionForm class also defines a validate() method. Subclasses may override this method to valid the state of an action form after population from request parameters. Struts also offers alternative approaches to validation. * Struts 1.1 corrects many (but not all) of shortcomings of Struts 1.0, for example by allowing the use of multiple controller servletin application.(The mechanism for this isn't very elegant, however it's clear that it was an afterthought). Other enhancement in Struts 1.1 include the introduction of the org.apache.struts.actions.DispatchAction superclass, allowing several actions to be performed by the same class. This is very useful in cases where many request types call for simple handling; it avoids the proliferation of many trivial action classes. Struts also introduces declative exception handling. Thanks a lot in advance for your inputs. José. DISCLAIMER This e-mail and any attachment thereto may contain information
RE: Struts design flaw -- ActionForms are not true domain objects
-Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 8:55 AM To: [EMAIL PROTECTED] Subject: Re: Struts design flaw -- ActionForms are not true domain objects However, Struts is not too JSP oriented. JSP is the most popular Java user interface technology for web applications so it is appropriately supported by Struts taglibs. You can use *any* UI technology you want with Struts. David Well, that's not quite true, is it? I mean, look at this signature for Action.execute: public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception You can't really use that outside of a servlet container. This is not a knock to Struts; it was never designed to be a general purpose MVC model. But noone is going to write a Swing app using Struts, for example. -= J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
-Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 3:55 PM To: [EMAIL PROTECTED] Subject: Re: Struts design flaw -- ActionForms are not true domain objects The author correctly states that ActionForms are not true domain objects. This is intentional. He also correctly points out that Is there any plan to move ActionForms to true domain objects ? Struts uses too many concrete base classes. We will be working to use more interfaces over time. Any idea on when or version ? José. DISCLAIMER This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation. For further information about Proximus mobile phone services please see our website at http://www.proximus.be or refer to any Proximus agent. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts design flaw -- ActionForms are not true domain objects
James Childers [EMAIL PROTECTED] writes: You can't really use that outside of a servlet container. This is not a knock to Struts; it was never designed to be a general purpose MVC model. But noone is going to write a Swing app using Struts, for example. http://javaboutique.internet.com/tutorials/Swing/ It can be done. cdh -- Chris D. Halverson http://www.halverson.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
i think the argument isn't about it being too servlet-container centric, rather that it is too tightly coupled to JSP as the view technology. -Original Message- From: James Childers [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 9:11 AM To: Struts Users Mailing List Subject: RE: Struts design flaw -- ActionForms are not true domain objects -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 8:55 AM To: [EMAIL PROTECTED] Subject: Re: Struts design flaw -- ActionForms are not true domain objects However, Struts is not too JSP oriented. JSP is the most popular Java user interface technology for web applications so it is appropriately supported by Struts taglibs. You can use *any* UI technology you want with Struts. David Well, that's not quite true, is it? I mean, look at this signature for Action.execute: public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception You can't really use that outside of a servlet container. This is not a knock to Struts; it was never designed to be a general purpose MVC model. But noone is going to write a Swing app using Struts, for example. -= J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
-Original Message- From: Chris Halverson [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 9:16 AM To: Struts Users Mailing List Subject: Re: Struts design flaw -- ActionForms are not true domain objects James Childers [EMAIL PROTECTED] writes: You can't really use that outside of a servlet container. This is not a knock to Struts; it was never designed to be a general purpose MVC model. But noone is going to write a Swing app using Struts, for example. http://javaboutique.internet.com/tutorials/Swing/ It can be done. Quoth the article: So this article is about connecting a Swing client to an existing servlet application. You still need to run Struts within a servlet context, which was my original point. -= J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
There are always ultra-literal people out there :-). Of course I meant any java web UI technology. David From: James Childers [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: Struts design flaw -- ActionForms are not true domain objects Date: Mon, 17 Feb 2003 09:10:48 -0600 -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 8:55 AM To: [EMAIL PROTECTED] Subject: Re: Struts design flaw -- ActionForms are not true domain objects However, Struts is not too JSP oriented. JSP is the most popular Java user interface technology for web applications so it is appropriately supported by Struts taglibs. You can use *any* UI technology you want with Struts. David Well, that's not quite true, is it? I mean, look at this signature for Action.execute: public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception You can't really use that outside of a servlet container. This is not a knock to Struts; it was never designed to be a general purpose MVC model. But noone is going to write a Swing app using Struts, for example. -= J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
Is there any plan to move ActionForms to true domain objects ? No. See past developer and user list discussions on this topic. Struts uses too many concrete base classes. We will be working to use more interfaces over time. Any idea on when or version ? Because introducing interfaces in certain areas would break backwards compatibility, 2.0 would be a good time to do this. David _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
It's not coupled to JSP at all. Struts provides taglibs to use in JSPs but does not dictate that you must use JSP as your view layer. This has been demonstrated by people using Velocity, XML, and Web Services with Struts. David From: John Espey [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: Struts design flaw -- ActionForms are not true domain objects Date: Mon, 17 Feb 2003 09:18:08 -0600 i think the argument isn't about it being too servlet-container centric, rather that it is too tightly coupled to JSP as the view technology. -Original Message- From: James Childers [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 9:11 AM To: Struts Users Mailing List Subject: RE: Struts design flaw -- ActionForms are not true domain objects -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 8:55 AM To: [EMAIL PROTECTED] Subject: Re: Struts design flaw -- ActionForms are not true domain objects However, Struts is not too JSP oriented. JSP is the most popular Java user interface technology for web applications so it is appropriately supported by Struts taglibs. You can use *any* UI technology you want with Struts. David Well, that's not quite true, is it? I mean, look at this signature for Action.execute: public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception You can't really use that outside of a servlet container. This is not a knock to Struts; it was never designed to be a general purpose MVC model. But noone is going to write a Swing app using Struts, for example. -= J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
If you use any flavor of DynaForms, you can pass the user input directly to the business domain as a DynaBean interface which is not directly connected to Struts, but rather to org.apache.commons.beanutils package. You will most likely still have to convert to some sort of DataTransportObject or ValueObject, but the beanutils package also has conversion tools for this. robert -Original Message- From: NYIMI Jose (BMB) [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 10:11 AM To: Struts Users Mailing List Subject: RE: Struts design flaw -- ActionForms are not true domain objects -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 3:55 PM To: [EMAIL PROTECTED] Subject: Re: Struts design flaw -- ActionForms are not true domain objects The author correctly states that ActionForms are not true domain objects. This is intentional. He also correctly points out that Is there any plan to move ActionForms to true domain objects ? Struts uses too many concrete base classes. We will be working to use more interfaces over time. Any idea on when or version ? José. DISCLAIMER This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation. For further information about Proximus mobile phone services please see our website at http://www.proximus.be or refer to any Proximus agent. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
-Original Message- From: Robert Taylor [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 4:35 PM To: Struts Users Mailing List Subject: RE: Struts design flaw -- ActionForms are not true domain objects If you use any flavor of DynaForms, you can pass the user input directly to the business domain as a DynaBean interface which is not directly connected to Struts, but rather to org.apache.commons.beanutils package. You will most likely still have to convert to some sort of DataTransportObject or ValueObject, but the beanutils package also has conversion tools for this. Inelegant solution :) That one of the reason Rod Johnson said : ... so Struts has only taken us part of the way towards true data binding. José. robert -Original Message- From: NYIMI Jose (BMB) [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 10:11 AM To: Struts Users Mailing List Subject: RE: Struts design flaw -- ActionForms are not true domain objects -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 3:55 PM To: [EMAIL PROTECTED] Subject: Re: Struts design flaw -- ActionForms are not true domain objects The author correctly states that ActionForms are not true domain objects. This is intentional. He also correctly points out that Is there any plan to move ActionForms to true domain objects ? Struts uses too many concrete base classes. We will be working to use more interfaces over time. Any idea on when or version ? José. DISCLAIMER This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation. For further information about Proximus mobile phone services please see our website at http://www.proximus.be or refer to any Proximus agent. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
I agree. I wasn't claiming that Struts IS too tightly coupled to JSP, I was pointing out that the argument from the initial post was not that Struts is too servlet centric but that it is too JSP centric, and that the execute() method signature from a subsequent post doesn't really shed any light on that argument. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 9:31 AM To: [EMAIL PROTECTED] Subject: RE: Struts design flaw -- ActionForms are not true domain objects It's not coupled to JSP at all. Struts provides taglibs to use in JSPs but does not dictate that you must use JSP as your view layer. This has been demonstrated by people using Velocity, XML, and Web Services with Struts. David From: John Espey [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: Struts design flaw -- ActionForms are not true domain objects Date: Mon, 17 Feb 2003 09:18:08 -0600 i think the argument isn't about it being too servlet-container centric, rather that it is too tightly coupled to JSP as the view technology. -Original Message- From: James Childers [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 9:11 AM To: Struts Users Mailing List Subject: RE: Struts design flaw -- ActionForms are not true domain objects -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 8:55 AM To: [EMAIL PROTECTED] Subject: Re: Struts design flaw -- ActionForms are not true domain objects However, Struts is not too JSP oriented. JSP is the most popular Java user interface technology for web applications so it is appropriately supported by Struts taglibs. You can use *any* UI technology you want with Struts. David Well, that's not quite true, is it? I mean, look at this signature for Action.execute: public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception You can't really use that outside of a servlet container. This is not a knock to Struts; it was never designed to be a general purpose MVC model. But noone is going to write a Swing app using Struts, for example. -= J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts design flaw -- ActionForms are not true domain objects
NYIMI Jose (BMB) wrote: -Original Message- From: Robert Taylor [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 4:35 PM To: Struts Users Mailing List Subject: RE: Struts design flaw -- ActionForms are not true domain objects If you use any flavor of DynaForms, you can pass the user input directly to the business domain as a DynaBean interface which is not directly connected to Struts, but rather to org.apache.commons.beanutils package. You will most likely still have to convert to some sort of DataTransportObject or ValueObject, but the beanutils package also has conversion tools for this. Inelegant solution :) That one of the reason Rod Johnson said : ... so Struts has only taken us part of the way towards true data binding. José. True data binding is generally inflexible and troublesome. Having come from the VB world many years ago, and its data binding way of doing things, I can say that I can't stand it. Having a middle ground creates more opportunities and power than not having it. I know some who still do data binding in swing apps, and they end up doing lots of hacks to perform things like validation, both simple and complex, and other 'process' type of actions. All of this is easy to do with the way Struts handles things. Taking the data out of a DynaForm once I'm done doing simple validation and maybe some pre-processing, then doing a simple copyProperties call to take the string version of the data and populate a 'real' domain object is to easy for me want to give up. - Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
True data binding is generally inflexible and troublesome. Having come from the VB world many years ago, and its data binding way of doing things, I can say that I can't stand it. Having a middle ground creates more opportunities and power than not having it. I know some who still do data binding in swing apps, and they end up doing lots of hacks to perform things like validation, both simple and complex, and other 'process' type of actions. All of this is easy to do with the way Struts handles things. Taking the data out of a DynaForm once I'm done doing simple validation and maybe some pre-processing, then doing a simple Rod Johnson, recommanded the following : Validation code shouldn't be contained in web-tier controllers or any objects unique to the web tier. This allows the reuse of validation objects for other client types. He continued by : Validation in the web tier has the severe disadvantage of tying validation logic(which may be business logic) to the Servlet API and perhaps also to a web application framework. Unfortunately, Struts tends to push validation in the direction of the web tier, as validation must occur on Struts ActionForm objects, which depend on the Servlet API, and hence *cannot* not be passed into an EJB container and should not be passed to any business object. For example, validation is often accomplished by overrinding the org.apache.struts.action.ActionForm validate method. I consider this (and the fact that ActionForm objects must extends a Struts superclass dependent on the Servlet API) to be a major design flaw. copyProperties call to take the string version of the data and populate a 'real' domain object is to easy for me want to give up. With the framework suggested by Rod Johnson there is no need to make this copy. The design deals with domain object. José. - Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] DISCLAIMER This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation. For further information about Proximus mobile phone services please see our website at http://www.proximus.be or refer to any Proximus agent. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts design flaw -- ActionForms are not true domain objects
NYIMI Jose (BMB) wrote: True data binding is generally inflexible and troublesome. Having come from the VB world many years ago, and its data binding way of doing things, I can say that I can't stand it. Having a middle ground creates more opportunities and power than not having it. I know some who still do data binding in swing apps, and they end up doing lots of hacks to perform things like validation, both simple and complex, and other 'process' type of actions. All of this is easy to do with the way Struts handles things. Taking the data out of a DynaForm once I'm done doing simple validation and maybe some pre-processing, then doing a simple Rod Johnson, recommanded the following : Validation code shouldn't be contained in web-tier controllers or any objects unique to the web tier. This allows the reuse of validation objects for other client types. He continued by : Validation in the web tier has the severe disadvantage of tying validation logic(which may be business logic) to the Servlet API and perhaps also to a web application framework. Unfortunately, Struts tends to push validation in the direction of the web tier, as validation must occur on Struts ActionForm objects, which depend on the Servlet API, and hence *cannot* not be passed into an EJB container and should not be passed to any business object. For example, validation is often accomplished by overrinding the org.apache.struts.action.ActionForm validate method. I consider this (and the fact that ActionForm objects must extends a Struts superclass dependent on the Servlet API) to be a major design flaw. copyProperties call to take the string version of the data and populate a 'real' domain object is to easy for me want to give up. With the framework suggested by Rod Johnson there is no need to make this copy. The design deals with domain object. José. As it has been pointed out a few times on this list, there are different types of validation. The validation in struts is intended for user input validation, not necessarily business logic validation. Input validation being that a number is input instead of a alphanumeric string, or other such 'simple' validation. I agree that business logic validation should happen in the domain objects. Things like cross property validation, cross object validation, verifying a user name/password, etc. etc. The same could be said for db validation. The database is good at validating referential integrity and things like that. Domain objects are good at cross property/object validation and other business rules that aren't necessarily db or input specific. As we tell our clients, validate where it makes sense. Sometimes that means in all three places, sometimes not. - Robert - Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] DISCLAIMER This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation. For further information about Proximus mobile phone services please see our website at http://www.proximus.be or refer to any Proximus agent. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts design flaw -- ActionForms are not true domain objects
On Mon, 17 Feb 2003, Chris Halverson wrote: Date: Mon, 17 Feb 2003 09:16:01 -0600 From: Chris Halverson [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: Struts design flaw -- ActionForms are not true domain objects James Childers [EMAIL PROTECTED] writes: You can't really use that outside of a servlet container. This is not a knock to Struts; it was never designed to be a general purpose MVC model. But noone is going to write a Swing app using Struts, for example. http://javaboutique.internet.com/tutorials/Swing/ It can be done. It can definitely be done -- but having to deal with GUI frameworks (MFC, AWT, Swing, SWT, ...) is so agonizingly painful that it's why I got involved in building applications for the web in the first place :-). Short answer: Struts was never intended to solve any outside of a servlet container problems, so it should hardly be surprising that using it that way is not particularly graceful. cdh Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
Rod Johnson: The idea of copying properties from an action form to business command is inelegant and there is o support for type checking. Was there so far an around solution ? José. DISCLAIMER This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation. For further information about Proximus mobile phone services please see our website at http://www.proximus.be or refer to any Proximus agent. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
Rod Johnson: The idea of copying properties from an action form to business command is inelegant and there is no support for type checking. Was there so far an around solution ? José. DISCLAIMER This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation. For further information about Proximus mobile phone services please see our website at http://www.proximus.be or refer to any Proximus agent. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
Just monitoring this thread. I wanted to put my 2 cents in. Being a big dummy ;-) I was thinking... Looking at each view technology that exists out there (JSP,XML,XHTML,WAP,Swing,SWT etc...). We face the reality of having a base form in which the data is collected and transported. In a markup environment we usually have a request object that houses all of the form input. The request also passes around objects which some may use in a jsp page. Others may use a straight xml/xslt solution which keeps the request a simple query transport but has to generate objects for creating those pages on the fly. Anyways, The point being struts forms that request into usable objects for the business-tier to take advantage of. What is the other option? Do we create Factory classes in our business logic to accomodate every sort of means of basic data transport out there and data conversion that needs to happen? Or do we provide an intermediary stage (like struts ActionServlet,ActionForm,Action) that prepares that data for the biz logic. Personally, I think Struts handles a type of view quite well(web). I'm not using Swing in conjunction with struts. But, if I so desired my business logic classes are freely available to be used in a swing or swt environment. As far as validation... Struts is NOT trying to accomplish all validaiton. Some validation can be handled on the Struts side to allow for better preparation of data and data conversion to the biz logic. Errors that are passed form the biz logic layer can be captured and displayed to the user if need be. So validation can still be handled in the business logic. I could go on and on... but I will end it with a couple comments: 1) Struts handles various issues in an appropriate and thoughtful manner. I only look forward to struts improving. 2) What technology out there is not breaking someones ideal model? The reason why we discard one technology for another is that the shortcomings of one technology become unbearable in comparison to another. I can bet you that there would be sizeable opponents to Rod Johnson's way of doing things as well as there are opponents to the way struts does things. No matter what technology you use you will be disatisfied with it in some aspect or another. If it's too unbearable for you to use Struts. Then there are various other frameworks that might serve your project better. :-) Let's just work on making what we have better. :-D Brandon Goodin Phase Web and Multimedia PO Box 85 Whitefish MT 59937 P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -Original Message- From: NYIMI Jose (BMB) [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 10:10 AM To: Struts Users Mailing List Subject: RE: Struts design flaw -- ActionForms are not true domain objects True data binding is generally inflexible and troublesome. Having come from the VB world many years ago, and its data binding way of doing things, I can say that I can't stand it. Having a middle ground creates more opportunities and power than not having it. I know some who still do data binding in swing apps, and they end up doing lots of hacks to perform things like validation, both simple and complex, and other 'process' type of actions. All of this is easy to do with the way Struts handles things. Taking the data out of a DynaForm once I'm done doing simple validation and maybe some pre-processing, then doing a simple Rod Johnson, recommanded the following : Validation code shouldn't be contained in web-tier controllers or any objects unique to the web tier. This allows the reuse of validation objects for other client types. He continued by : Validation in the web tier has the severe disadvantage of tying validation logic(which may be business logic) to the Servlet API and perhaps also to a web application framework. Unfortunately, Struts tends to push validation in the direction of the web tier, as validation must occur on Struts ActionForm objects, which depend on the Servlet API, and hence *cannot* not be passed into an EJB container and should not be passed to any business object. For example, validation is often accomplished by overrinding the org.apache.struts.action.ActionForm validate method. I consider this (and the fact that ActionForm objects must extends a Struts superclass dependent on the Servlet API) to be a major design flaw. copyProperties call to take the string version of the data and populate a 'real' domain object is to easy for me want to give up. With the framework suggested by Rod Johnson there is no need to make this copy. The design deals with domain object. José. - Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] DISCLAIMER This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual
RE: Struts design flaw -- ActionForms are not true domain objects
Validation code shouldn't be contained in web-tier controllers or any objects unique to the web tier. This allows the reuse of validation objects for other client types. You can perform absolutely no validation in the Struts web tier if you choose. Validate wherever you like; Struts provides a hook into basic UI validation if you want to use it. With the framework suggested by Rod Johnson there is no need to make this copy. The design deals with domain object. If you like other frameworks better than Struts, then use them. ActionForm being a base class instead of an interface is not a significant reason to not use Struts. David _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts design flaw -- ActionForms are not true domain objects
Touche... Of course I have to shamelessly plug our domain layer framework, eQ!(www.browsersoft.com/eQ) :-) One of the goals is to be UI independant, as well as deployment independant (app server, client-server, standalone), but we also provide adapters for Swing and of course Struts. If we had demand for others, we would build them as well. I also agree that Struts isn't perfect, but it is pretty darn strong and it is the most widely accepted. - Robert Ted Husted wrote: I think Rod makes a common mistake in believing Struts is suppose to act as the base of your domain architecture. Struts is a presentation layer controller. Sophisticated applications will also need their own *domain layer* controller. Yes, ActionForms are not domain objects. They are not suppose to domain objects. They are presentation layer objects. They are not intended to be used as domain objects. ActionForm is not an interface *because* we don't want them to be used as domain objects. It's not a design flaw, but a deliberate design decision that's been documented time and again. Sophisticated applications will also use their own set of beans (or the like). Some (and only some) of properties of the domain objects and the ActionForms will overlap, but they are not the same entity. Among other things, ActionForms are Data Transfer Objects. It's important not to confuse a DTO with the DO. This type of decoupling is what MVC is all about. IMHO, what's missing is a decent Domain Layer framework that can hook up with other presentation layer frameworks like Struts or Tapestry or Maverick or WebWorks, or whatever you've brewed in house. But there should not be *one true framework*, but frameworks at each layer that you can mix and match. But I do agree with Rod that the best presentation layer framework has yet to be built. Meanwhile, AFAIK, we haven't even built a decent business layer framework yet. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts design flaw -- ActionForms are not true domain objects
* Thus a Struts ActionForm is not a true domain object. Definitely true -- ActionForm is a view tier object, used (by the framework, not the application) to maintain the server-side state of input fields on an HTML form. Trying to treat it as a domain object is a misuse of Struts, and violates the fundamental design principles that the framework is based on. By the way, this is also why ActionForm is a concrete class and not an interface (which it was in the pre-1.0 days). Too many people didn't understand this crucial concept, and were using it incorrectly (by making their real domain objects implement ActionForm). It was changed to a concrete class to push application developers towards doing the right thing. I'm not in favor of switching it back. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
I think Rod makes a common mistake in believing Struts is suppose to act as the base of your domain architecture. Struts is a presentation layer controller. Sophisticated applications will also need their own *domain layer* controller. [John Cavacas] I have to disagree with that statement after reading the book and being somewhat familiar with the framework and solutions that Rod presents. I believe that Rod never makes that assumption, on the contrary. IMHO, what's missing is a decent Domain Layer framework that can hook up with other presentation layer frameworks like Struts or Tapestry or Maverick or WebWorks, or whatever you've brewed in house. But there should not be *one true framework*, but frameworks at each layer that you can mix and match. [John Cavacas] I don't want to sound that I am preaching for Rod's methods and framework, but the framework he came up with does seem to solve (to an extent) this and other problems. It's worth a look at especially since it has gone open source and there is the beginning of active development on the project. Struts is great for what it does, and Rods Spring Framework also seems great at what it does. There are also flaws in both Struts and Spring. But that's the beauty and simplicity of all of this. If you don't like something, don't use it. Use something else or do your own thing. John This communication is intended for the use of the individual(s) or entity it was addressed to and may contain confidential and/or privileged information. If the reader of this transmission is not the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is prohibited. If you receive this communication in error, please notify the sender immediately and delete this communication from your system(s) to which it was sent and/or replicated to. (c) 2002 Sapiens Americas Corp. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
It's 19h22 in Belgium : time for me to go home :-) Thanks for your input ... Soon ? José. DISCLAIMER This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation. For further information about Proximus mobile phone services please see our website at http://www.proximus.be or refer to any Proximus agent. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts design flaw -- ActionForms are not true domain objects
On Monday, Feb 17, 2003, at 13:04 US/Eastern, John Cavacas wrote: Struts is great for what it does, and Rods Spring Framework also seems great at what it does. There are also flaws in both Struts and Spring. But that's the beauty and simplicity of all of this. If you don't like something, don't use it. Use something else or do your own thing. Yup exactly. Struts is not a do it all framework for everyone. Struts to me is a purely web-based framework which makes very complex web-based application development easier and more maintainable. Plain and simple. It sets a bunch of rules so we don't have to set them ourselves for every project we work on. If you chose Struts to build Swing GUIs you picked the wrong framework, if you want to add Swing GUIs to maintain say application settings for an application that uses Struts, you can still do that, but it's YOUR job to design YOUR side of the framework properly in order to allow your Swing apps to tap into YOUR framework while keeping it oblivious to the Struts side of things (see Business Delegate Pattern). Now does it break this book's opinion of proper design patterns? I'm sure it does, but what GREAT engineers don't break design pattern rules when it benefits the end result of an application or framework? Patters are there to solve issues we have, not to stick us into lala land with shackles and whips telling us that we must do it that way. They're merely there to help us write better OO design, and from where I sit the Struts design is as close to perfect as you can get right now for WEB-based development. just my 2 cents. R -- Robert S. Sfeir Senior Java Engineer National Institutes of Health Center for Information Technology Department of Enterprise Custom Applications [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
Well said, and that's the reason why I like so much to write and use web applications. Marco -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 5:26 PM To: Struts Users Mailing List Subject: Re: Struts design flaw -- ActionForms are not true domain objects On Mon, 17 Feb 2003, Chris Halverson wrote: Date: Mon, 17 Feb 2003 09:16:01 -0600 From: Chris Halverson [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: Struts design flaw -- ActionForms are not true domain objects James Childers [EMAIL PROTECTED] writes: You can't really use that outside of a servlet container. This is not a knock to Struts; it was never designed to be a general purpose MVC model. But noone is going to write a Swing app using Struts, for example. http://javaboutique.internet.com/tutorials/Swing/ It can be done. It can definitely be done -- but having to deal with GUI frameworks (MFC, AWT, Swing, SWT, ...) is so agonizingly painful that it's why I got involved in building applications for the web in the first place :-). Short answer: Struts was never intended to solve any outside of a servlet container problems, so it should hardly be surprising that using it that way is not particularly graceful. cdh Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts design flaw -- ActionForms are not true domain objects
I would say DTO -Original Message- From: NYIMI Jose (BMB) [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 5:35 PM To: Struts Users Mailing List Subject: RE: Struts design flaw -- ActionForms are not true domain objects Rod Johnson: The idea of copying properties from an action form to business command is inelegant and there is o support for type checking. Was there so far an around solution ? José. DISCLAIMER This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation. For further information about Proximus mobile phone services please see our website at http://www.proximus.be or refer to any Proximus agent. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
