You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Alex Birch <al...@yahoo.co.uk> on 2002/08/20 18:54:54 UTC

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

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>