You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Galbreath, Mark" <Ga...@tessco.com> on 2002/08/20 18:47:15 UTC

RE: Stupid email filters [WAS: DAO -> DTO business object to view beans]

Heh heh...happens to me all the time:

Your name cannot be "Dick."

Your dog cannot be a "bitch."

Your cat cannot be a "pussy."

A fastener cannot be a "screw."

A lubrication nozzle cannot be a "tit" or a "nipple."

A mule cannot be an "ass."

Something strange cannot be "queer."

A cigarette cannot be a "fag."

A levee cannot be a "dike."

Etc., etc....

And some, like the one returned to you, make no sense at all.  I've found
General Electric's censors to be the most restrictive.  PC v. free speech?
Only in America, man.  As the concierge in "French Kiss" states, "Unlike
some countries, [France] is not a nation of hypocrites."

Mark

-----Original Message-----
From: Andrew Hill [mailto:andrew.david.hill@gridnode.com]
Sent: Tuesday, August 20, 2002 12:07 PM
To: Struts Users Mailing List
Subject: Stupid email filters [WAS: DAO -> DTO business object to view
beans]


Ok whats wrong with this thread?
Seems it offended someones highly touchy content filter.
duh! <tries-to-clap-but-the-hands-miss/>

<stupid/>
Trend SMEX Content Filter has detected sensitive content.

Place = Struts Users Mailing List; ; ; Struts Users Mailing List
Sender = Andrew Hill
Subject = RE: DAO -> DTO business object to view beans
Delivery Time = August 20, 2002 (Tuesday) 11:48:58
Policy = Blocking07292002
Action on this mail = Quarantine message

Warning message from administrator:
Content filter has detected a sensitive e-mail.
</stupid>




-----Original Message-----
From: Andrew Hill [mailto:andrew.david.hill@gridnode.com]
Sent: Tuesday, August 20, 2002 23:56
To: Struts Users Mailing List
Subject: RE: DAO -> DTO business object to view beans


Have to agree.
My ActionForms started out looking very like the objects I use to access the
data from the j2ee side, but the speed at which they diverged over just a
few iterations was quite surprising....

-----Original Message-----
From: James Higginbotham [mailto:jhigginbotham@betweenmarkets.com]
Sent: Tuesday, August 20, 2002 23:11
To: Struts Users Mailing List
Subject: RE: DAO -> DTO business object to view beans


In my past experience, projects tend to start out with the DTOs matching
the BOs 1-to-1 but as a project grows and matures, UI changes will
require a DTO to change in such a way that they don't match the BOs
anymore. So, do the right thing and have both BO and DTO, even if they
are matching. This will give you the buffer zone you need to be able to
change one or the other. If you want to automate the transformation, I
think there is a transformation library in the Struts resources page
(somewhere) that is supposed to help in this mapping. Worst case, take a
look at the apache commons bean utils that Struts uses to help automate
the transformations.

James

> -----Original Message-----
> From: Alex Birch [mailto:alex_d_birch@yahoo.co.uk]
> Sent: Tuesday, August 20, 2002 9:18 AM
> To: struts-user@jakarta.apache.org
> Subject: DAO -> DTO business object to view beans
>
>
> Hi,
>
> I am building a medium size struts application (40-60 jsp
> pages) in a team.
>
> my question is to do with mapping business objects to view beans...
>
> By view beans I mean DTO (data transfer objects mentioned by
> Chuck Caveness in chapter 7 his upcoming O'Reilly struts book)
>
> If my understanding is correct, to maintain the abstraction
> between the presentation layer and the business layer,
> business objects should be mapped to DTOs. DTOs are stateless
> and represent a partial view of your model to be represented
> on a single JSP page.
>
> We have adopted this policy quite literally and have designed
> our DTOs totally separate from the BO's (with re-use where possible).
>
> There are many instances however where our BOs are simply DAO
> (data access objects) which do not differ at all from the view beans.
>
> We as a team are arguing whether it is better to break the
> abstraction and use some of our BO's straight for display in
> the view (the BO's aren't persistant so there's no worry
> about accidental state manipulation). You can imagine with 40
> or so JSPs how many view beans there are - and a lot of them
> will be straight theDTO.setProperty(theBO.getProperty())
> which is also inefficient.
>
> Has anyone encountered the same superfluous nature in this
> scenario? The DTO's/viewBeans are not coupled to the
> presentation layer in any way seeing as they're just snapshot
> java beans with no specific struts implementation.
>
> Is there a big no-no that I haven't seen which means I
> shouldn't use the BOs for the view?
>
> thanks for your time in advance
>
> Alex
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts http://uk.my.yahoo.com
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>

--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Stupid email filters [WAS: DAO -> DTO business object to view beans]

Posted by James Mitchell <jm...@telocity.com>.
 Trend SMEX Content Filter has detected sensitive content.

 Place = Struts Users Mailing List; ; ; Struts Users Mailing List
 Sender = Mark Galbreath
 Subject = RE: Stupid email filters     [WAS: DAO -> DTO business object to
view beans]
 Delivery Time = August 20, 2002 (Tuesday) 13:35:22
 Policy = Blocking07292002
 Action on this mail = Quarantine message

 Warning message from administrator:
 Content filter has detected a sensitive e-mail.

 Violating words:
 ... to you, make no sense at all.  I've found ...
                     ^^^^^
 Reason Code:
 14fQLAN

 Reason Description:
 The word "sense" is not allowed in this company.
 Please resend using a different synonym.


This technology is made possible by:
General Electric Automated Filter and Restriction Technology (GEA-FART)



Hehehe;)

James Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the "Open Minded Developer Network"
http://www.open-tools.org/struts-atlanta




> -----Original Message-----
> From: Galbreath, Mark [mailto:Galbreath@tessco.com]
> Sent: Tuesday, August 20, 2002 12:47 PM
> To: 'Struts Users Mailing List'
> Subject: RE: Stupid email filters [WAS: DAO -> DTO business object to
> view beans]
>
>
> Heh heh...happens to me all the time:
>
> Your name cannot be "Dick."
>
> Your dog cannot be a "bitch."
>
> Your cat cannot be a "pussy."
>
> A fastener cannot be a "screw."
>
> A lubrication nozzle cannot be a "tit" or a "nipple."
>
> A mule cannot be an "ass."
>
> Something strange cannot be "queer."
>
> A cigarette cannot be a "fag."
>
> A levee cannot be a "dike."
>
> Etc., etc....
>
> And some, like the one returned to you, make no sense at all.  I've found
> General Electric's censors to be the most restrictive.  PC v. free speech?
> Only in America, man.  As the concierge in "French Kiss" states, "Unlike
> some countries, [France] is not a nation of hypocrites."
>
> Mark
>
> -----Original Message-----
> From: Andrew Hill [mailto:andrew.david.hill@gridnode.com]
> Sent: Tuesday, August 20, 2002 12:07 PM
> To: Struts Users Mailing List
> Subject: Stupid email filters [WAS: DAO -> DTO business object to view
> beans]
>
>
> Ok whats wrong with this thread?
> Seems it offended someones highly touchy content filter.
> duh! <tries-to-clap-but-the-hands-miss/>
>
> <stupid/>
> Trend SMEX Content Filter has detected sensitive content.
>
> Place = Struts Users Mailing List; ; ; Struts Users Mailing List
> Sender = Andrew Hill
> Subject = RE: DAO -> DTO business object to view beans
> Delivery Time = August 20, 2002 (Tuesday) 11:48:58
> Policy = Blocking07292002
> Action on this mail = Quarantine message
>
> Warning message from administrator:
> Content filter has detected a sensitive e-mail.
> </stupid>
>
>
>
>
> -----Original Message-----
> From: Andrew Hill [mailto:andrew.david.hill@gridnode.com]
> Sent: Tuesday, August 20, 2002 23:56
> To: Struts Users Mailing List
> Subject: RE: DAO -> DTO business object to view beans
>
>
> Have to agree.
> My ActionForms started out looking very like the objects I use to
> access the
> data from the j2ee side, but the speed at which they diverged over just a
> few iterations was quite surprising....
>
> -----Original Message-----
> From: James Higginbotham [mailto:jhigginbotham@betweenmarkets.com]
> Sent: Tuesday, August 20, 2002 23:11
> To: Struts Users Mailing List
> Subject: RE: DAO -> DTO business object to view beans
>
>
> In my past experience, projects tend to start out with the DTOs matching
> the BOs 1-to-1 but as a project grows and matures, UI changes will
> require a DTO to change in such a way that they don't match the BOs
> anymore. So, do the right thing and have both BO and DTO, even if they
> are matching. This will give you the buffer zone you need to be able to
> change one or the other. If you want to automate the transformation, I
> think there is a transformation library in the Struts resources page
> (somewhere) that is supposed to help in this mapping. Worst case, take a
> look at the apache commons bean utils that Struts uses to help automate
> the transformations.
>
> James
>
> > -----Original Message-----
> > From: Alex Birch [mailto:alex_d_birch@yahoo.co.uk]
> > Sent: Tuesday, August 20, 2002 9:18 AM
> > To: struts-user@jakarta.apache.org
> > Subject: DAO -> DTO business object to view beans
> >
> >
> > Hi,
> >
> > I am building a medium size struts application (40-60 jsp
> > pages) in a team.
> >
> > my question is to do with mapping business objects to view beans...
> >
> > By view beans I mean DTO (data transfer objects mentioned by
> > Chuck Caveness in chapter 7 his upcoming O'Reilly struts book)
> >
> > If my understanding is correct, to maintain the abstraction
> > between the presentation layer and the business layer,
> > business objects should be mapped to DTOs. DTOs are stateless
> > and represent a partial view of your model to be represented
> > on a single JSP page.
> >
> > We have adopted this policy quite literally and have designed
> > our DTOs totally separate from the BO's (with re-use where possible).
> >
> > There are many instances however where our BOs are simply DAO
> > (data access objects) which do not differ at all from the view beans.
> >
> > We as a team are arguing whether it is better to break the
> > abstraction and use some of our BO's straight for display in
> > the view (the BO's aren't persistant so there's no worry
> > about accidental state manipulation). You can imagine with 40
> > or so JSPs how many view beans there are - and a lot of them
> > will be straight theDTO.setProperty(theBO.getProperty())
> > which is also inefficient.
> >
> > Has anyone encountered the same superfluous nature in this
> > scenario? The DTO's/viewBeans are not coupled to the
> > presentation layer in any way seeing as they're just snapshot
> > java beans with no specific struts implementation.
> >
> > Is there a big no-no that I haven't seen which means I
> > shouldn't use the BOs for the view?
> >
> > thanks for your time in advance
> >
> > Alex
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Everything you'll ever need on one web page
> > from News and Sport to Email and Music Charts http://uk.my.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:struts-user-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
> >
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Stupid email filters [WAS: DAO -> DTO business object to view beans]

Posted by Alex Birch <al...@yahoo.co.uk>.
I get a bad filter message for every post I send to struts-user!

I hope it's not my name "birch" which looks like 'bitch'!?!! what about Birch trees?

sorry all to make you receive annoying filters

Alex

 --- "Galbreath, Mark" <Ga...@tessco.com> wrote: > Heh heh...happens to me all the time:
> 
> Your name cannot be "Dick."
> 
> Your dog cannot be a "bitch."
> 
> Your cat cannot be a "pussy."
> 
> A fastener cannot be a "screw."
> 
> A lubrication nozzle cannot be a "tit" or a "nipple."
> 
> A mule cannot be an "ass."
> 
> Something strange cannot be "queer."
> 
> A cigarette cannot be a "fag."
> 
> A levee cannot be a "dike."
> 
> Etc., etc....
> 
> And some, like the one returned to you, make no sense at all.  I've found
> General Electric's censors to be the most restrictive.  PC v. free speech?
> Only in America, man.  As the concierge in "French Kiss" states, "Unlike
> some countries, [France] is not a nation of hypocrites."
> 
> Mark
> 
> -----Original Message-----
> From: Andrew Hill [mailto:andrew.david.hill@gridnode.com]
> Sent: Tuesday, August 20, 2002 12:07 PM
> To: Struts Users Mailing List
> Subject: Stupid email filters [WAS: DAO -> DTO business object to view
> beans]
> 
> 
> Ok whats wrong with this thread?
> Seems it offended someones highly touchy content filter.
> duh! <tries-to-clap-but-the-hands-miss/>
> 
> <stupid/>
> Trend SMEX Content Filter has detected sensitive content.
> 
> Place = Struts Users Mailing List; ; ; Struts Users Mailing List
> Sender = Andrew Hill
> Subject = RE: DAO -> DTO business object to view beans
> Delivery Time = August 20, 2002 (Tuesday) 11:48:58
> Policy = Blocking07292002
> Action on this mail = Quarantine message
> 
> Warning message from administrator:
> Content filter has detected a sensitive e-mail.
> </stupid>
> 
> 
> 
> 
> -----Original Message-----
> From: Andrew Hill [mailto:andrew.david.hill@gridnode.com]
> Sent: Tuesday, August 20, 2002 23:56
> To: Struts Users Mailing List
> Subject: RE: DAO -> DTO business object to view beans
> 
> 
> Have to agree.
> My ActionForms started out looking very like the objects I use to access the
> data from the j2ee side, but the speed at which they diverged over just a
> few iterations was quite surprising....
> 
> -----Original Message-----
> From: James Higginbotham [mailto:jhigginbotham@betweenmarkets.com]
> Sent: Tuesday, August 20, 2002 23:11
> To: Struts Users Mailing List
> Subject: RE: DAO -> DTO business object to view beans
> 
> 
> In my past experience, projects tend to start out with the DTOs matching
> the BOs 1-to-1 but as a project grows and matures, UI changes will
> require a DTO to change in such a way that they don't match the BOs
> anymore. So, do the right thing and have both BO and DTO, even if they
> are matching. This will give you the buffer zone you need to be able to
> change one or the other. If you want to automate the transformation, I
> think there is a transformation library in the Struts resources page
> (somewhere) that is supposed to help in this mapping. Worst case, take a
> look at the apache commons bean utils that Struts uses to help automate
> the transformations.
> 
> James
> 
> > -----Original Message-----
> > From: Alex Birch [mailto:alex_d_birch@yahoo.co.uk]
> > Sent: Tuesday, August 20, 2002 9:18 AM
> > To: struts-user@jakarta.apache.org
> > Subject: DAO -> DTO business object to view beans
> >
> >
> > Hi,
> >
> > I am building a medium size struts application (40-60 jsp
> > pages) in a team.
> >
> > my question is to do with mapping business objects to view beans...
> >
> > By view beans I mean DTO (data transfer objects mentioned by
> > Chuck Caveness in chapter 7 his upcoming O'Reilly struts book)
> >
> > If my understanding is correct, to maintain the abstraction
> > between the presentation layer and the business layer,
> > business objects should be mapped to DTOs. DTOs are stateless
> > and represent a partial view of your model to be represented
> > on a single JSP page.
> >
> > We have adopted this policy quite literally and have designed
> > our DTOs totally separate from the BO's (with re-use where possible).
> >
> > There are many instances however where our BOs are simply DAO
> > (data access objects) which do not differ at all from the view beans.
> >
> > We as a team are arguing whether it is better to break the
> > abstraction and use some of our BO's straight for display in
> > the view (the BO's aren't persistant so there's no worry
> > about accidental state manipulation). You can imagine with 40
> > or so JSPs how many view beans there are - and a lot of them
> > will be straight theDTO.setProperty(theBO.getProperty())
> > which is also inefficient.
> >
> > Has anyone encountered the same superfluous nature in this
> > scenario? The DTO's/viewBeans are not coupled to the
> > presentation layer in any way seeing as they're just snapshot
> > java beans with no specific struts implementation.
> >
> > Is there a big no-no that I haven't seen which means I
> > shouldn't use the BOs for the view?
> >
> > thanks for your time in advance
> >
> > Alex
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Everything you'll ever need on one web page
> > from News and Sport to Email and Music Charts http://uk.my.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:struts-user-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
> >
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>  

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>