On 17/03/2004 13:33, "HG" <[EMAIL PROTECTED]> wrote:
> Hi Adam..
>
> Well, I haven't experienced any problems whatsoever with this approach...so
> I guess it is safe.
>
> Sometimes I use BeanUtils to copy attributes but not very often...in my
> opinion DTOs (or Value Objects) and the form bean is two totally different
> concepts..therefore I like to keep them separate and sometimes with
> different attribute names...Just my way of doing it ..might be silly...I
> dunno..:-)
>
(sorry to jump in to the conversation)
I have been doing this but using a xml configuration file, using a Struts
plugin. It falls on something like this:
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE views PUBLIC "-//04Web//DTD Horizon Configuration 1.0//EN"
"http://www.04web.com/dtd/horizon-config_1_0.dtd";>
<views>
<view name="usersView">
<dyna-property property="users" type="java.util.Collection"/>
<dyna-property property="flag" type="java.lang.Boolean"/>
</view>
</views>
(similar to struts-config)
I did this because I found it a bit confusing mixing bean attributes to
retrieve html form data and attributes to deliver the intended presentation.
I use a "view" factory to retrieve the bean definitions and then do
something like:
view.set("property", object); (I extended the DynaBean and implement the
Map interface to achieve this - much simpler and JSTL friendly)
...you could also use BeanUtils for setting the properties.
A simple module aware configuration:
<!-- HORIZON PLUGIN -->
<plug-in className="com.ohforweb.horizon.HorizonPlugin">
<set-property property="config-files"
value="/WEB-INF/horizon-config.xml"/>
<set-property property="parser-validate" value="true"/>
<set-property property="module-aware" value="true"/>
</plug-in>
When I send the request I usually send a "view". If aa prepopulated html
form is to be presented I send a "view" and a form bean.
Voila :)
Pedro Salgado
(http://www.04web.com/)
>
> ----- Original Message -----
> From: "Adam Hardy" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Wednesday, March 17, 2004 2:07 PM
> Subject: Re: action - delegate - facade
>
>
>> Is it safe? I really don't know. You'd have to ask someone else.... or
>> wait until I've got a couple of years experience with the service
>> locator pattern, and I'll let you know ;)
>>
>> but regarding value objects - you use BeanUtils to copy the properties
>> into the form beans?
>>
>>
>>
>> On 03/17/2004 12:34 PM HG wrote:
>>> ehh..Correction to third answer...
>>>
>>> Actually the plugin caches the reference to the EJB Facade and the
> Service
>>> Locator caches the home looked up from JNDI...
>>>
>>> Is this really safe..?? :-)
>>>
>>>
>>> ----- Original Message -----
>>> From: "HG" <[EMAIL PROTECTED]>
>>> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>>> Sent: Wednesday, March 17, 2004 12:31 PM
>>> Subject: Re: action - delegate - facade
>>>
>>>
>>>
>>>> Hi Adam.
>>>>
>>>> Your first question, regarding packaging
>>>> I keep that part simple, so I place all value objects in a model
> package,
>>>> say "com.mycompany.myproduct.model". Both the ejb-jar and the web-jat
>>>> contain these classes.
>>>>
>>>> Your second question, regarding generation value objects
>>>> I use xDoclets facilities to generate value objects. If I need special
>>>> services/attributes in the value objects I subclass the one generated by
>>>> xDoclet and roll my changes.
>>>>
>>>> Your third question, regarding home lookups.
>>>> I use the ServiceLocator pattern from my business delegates(plugins).
> The
>>>> service locator is implemented as a Singleton and contains only Facades.
> I
>>>> have antoher another singleton ServiceLocator for Entities.
>>>> Each plugin caches the home of the "Business Services" it uses (ie. the
>>>> Facades).
>>>>
>>>> Hope to help...otherwise....feel free to ask.
>>>>
>>>> Best regards
>>>>
>>>> Henrik
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Adam Hardy" <[EMAIL PROTECTED]>
>>>> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>>>> Sent: Wednesday, March 17, 2004 11:01 AM
>>>> Subject: Re: action - delegate - facade
>>>>
>>>>
>>>>
>>>>> I am surprised to see that the xpetstore @ sourceforge has a direct
>>>>> interface between Actions and the session beans.
>>>>>
>>>>> The delegate does make sense to me now and I'm going to implement it.
>>>>>
>>>>> One think I've been wondering is about packaging all the classes. Do
> you
>>>>> put the delegate classes and the transfer / value object classes in a
>>>>> seperate jar file from the action classes, and from the EJBs?
>>>>>
>>>>> While on the subject, what do you use for value objects? Form beans or
>>>>> something generated by xdoclet? I've been using an xml schema to
>>>>> generate my value objects so far (not with EJB) via JAXB, but this
> isn't
>>>>> going to work with EJB because the things aren't serializable.
>>>>>
>>>>> Another question (my last!): what is the best way to handle home
>>>>> interfaces in the delegate? Do you cache them? Do you treat them like a
>>>>> logger object or a singleton? Or do you just instantiate them fresh
> each
>>>>> call?
>>>>>
>>>>>
>>>>> Thanks!
>>>>> Adam
>>>>>
>>>>>
>>>>> On 03/17/2004 09:22 AM HG wrote:
>>>>>
>>>>>> Hi Robert and Adam...
>>>>>>
>>>>>> Guess I am paranoid or prepared.. :-)
>>>>>>
>>>>>> I use nearly the approach Robert described, using a Factory for the
>>>>>> delegate....although the purpose is not the same..
>>>>>>
>>>>>> I use the Delegate as the "web tier view" of the business
>>>
>>> logic/services
>>>
>>>> in
>>>>
>>>>>> the system. That becomes important, when different business
>>>
>>> rules/logic
>>>
>>>>>> applies to different modules/plugin.
>>>>>>
>>>>>> In my scenario I call the business delegates for business plugins
>>>>
>>>> because of
>>>>
>>>>>> the dynamic plugable nature. Plugins are hosted by a plugin manager
>>>
>>> (the
>>>
>>>>>> factory), and access the plugin interfaces always goes through the
>>>>
>>>> plugin
>>>>
>>>>>> manager.
>>>>>>
>>>>>> You get an interface to a plugin (ie. web tier view of a business
>>>>
>>>> service),
>>>>
>>>>>> not an implementation...that's important as you state correctly
>>>
>>> Robert.
>>>
>>>>>> The difference is that I don't care if it is a POJO, EJB, whatever I
>>>
>>> am
>>>
>>>>>> talking to "behing the scenes", I care about HOW the business service
>>>
>>> is
>>>
>>>>>> implemented...
>>>>>>
>>>>>> Let me give you an example:
>>>>>>
>>>>>> Way through system is:
>>>>>>
>>>>>> Action->Plugin->Facade->Entity
>>>>>>
>>>>>> Pseudo code for action execute:
>>>>>> AccountManagement plugin =
>>>>>> pluginManager.getPlugin("core.account.management");
>>>>>>
>>>>>> What I get here is an interface (AccountManagement) of a business
>>>>
>>>> service
>>>>
>>>>>> plugin. Behind the interface, one specific implementation of it
>>>
>>> resides.
>>>
>>>>>> WHAT implementation to use is decided by the plugin manager. I my
>>>>
>>>> scenario
>>>>
>>>>>> it is based on a customer, which have a certain business role. But it
>>>>
>>>> can be
>>>>
>>>>>> whatever logic to decide which implementation to use.
>>>>>>
>>>>>> Now I use the the plugin business service interface from my action
>>>>>>
>>>>>> plugin.createAccount("001", "Hans Gruber");
>>>>>>
>>>>>> With this one call a specific implementation of the Management
>>>
>>> interface
>>>
>>>> is
>>>>
>>>>>> called. What happens behind the scenes is not important from the
>>>
>>> actions
>>>
>>>>>> point of view. Maybe different business rules/logic applies for
>>>>
>>>> different
>>>>
>>>>>> implementations of the AccountManagement.
>>>>>>
>>>>>> What actually happens is that the plugin service implementation calls
>>>
>>> a
>>>
>>>>>> facade to fulfil the business action of creating an account.
>>>>>>
>>>>>> This approach is highly flexible...You have the possibility of hosting
>>>>>> different customers (with different needs) under the same application
>>>>>> constrcuted using business plugins building blocks.
>>>>>>
>>>>>> It also (like other business delegates as you stated Robert) promotes
>>>>>> loosely coupling between the web tier and EJB or whatever tier is
>>>>
>>>> behind.
>>>>
>>>>>> With this clean interface it is very very easy to provide an additonal
>>>>
>>>> XML
>>>>
>>>>>> WebServices interface (maybe though Axis) that makes your business
>>>>
>>>> services
>>>>
>>>>>> accessible from other platforms, systems, whatever...
>>>>>>
>>>>>> My few bucks...Anyone has comments...they are welcome...
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Henrik
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "Robert Taylor" <[EMAIL PROTECTED]>
>>>>>> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>>>>>> Sent: Wednesday, March 17, 2004 2:51 AM
>>>>>> Subject: RE: action - delegate - facade
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Adam, IMHO the Business Delegate pattern abstracts the client from
>>>>
>>>> knowing
>>>>
>>>>>>> your business implementation, whether it be EBJ, JDO, POJO, roll your
>>>>
>>>> own.
>>>>
>>>>>> The
>>>>>>
>>>>>>
>>>>>>> client interfaces with the Business Delegate and not its
>>>
>>> implementation.
>>>
>>>>>>> For example, if you have an Action (client) interface with the
>>>
>>> Business
>>>
>>>>>> Delegate
>>>>>>
>>>>>>
>>>>>>> instead of directly with a SessionFacade, then you can change the
>>>>>>
>>>>>> underlying implementation
>>>>>>
>>>>>>
>>>>>>> of the Business Delegate without changing anything in the client.
>>>>>>> If your really paranoid (or prepared), you can use the Abstract
>>>
>>> Factory
>>>
>>>>>> pattern which you could then
>>>>>>
>>>>>>
>>>>>>> initialize/subclass to create the appropriate Business Delegate
>>>>>>
>>>>>> implementations (EJB, JDO, main frame).
>>>>>>
>>>>>>
>>>>>>> Also by using a Business Delegate the client isn't exposed to
>>>>>>
>>>>>> implementation details
>>>>>>
>>>>>>
>>>>>>> such as (if your using EJB) looking up the appropropriate EJB or
>>>>
>>>> handling
>>>>
>>>>>> implementation
>>>>>>
>>>>>>
>>>>>>> specific exceptions. The Business Delegate becomes a high level
>>>>>>
>>>>>> abstraction of the
>>>>>>
>>>>>>
>>>>>>> business rules raising application level exceptions when error occur
>>>
>>> to
>>>
>>>>>> which the client
>>>>>>
>>>>>>
>>>>>>> can respond appropriately.
>>>>>>>
>>>>>>> So, you wouldn't necessarily have to modify the Delegate-Facade
>>>>
>>>> interface.
>>>>
>>>>>> The interface
>>>>>>
>>>>>>
>>>>>>> itself remains unchanged. You have to use a different implementation.
>>>>
>>>> That
>>>>
>>>>>> is where the
>>>>>>
>>>>>>
>>>>>>> factory comes in. I imagine you could do something like the
> following:
>>>>>>>
>>>>>>> Properties props = // get initialization properties
>>>>>>> // to initialize factory to return EJB BD
>>>>>>
>>>>>> implementations
>>>>>>
>>>>>>
>>>>>>> BusinessDelegateFactory bdf = BusinessDelegateFactory.init(props);
>>>>>>>
>>>>>>>
>>>>>>> In your client, suppose AccountBD is your BusinessDelegate interface:
>>>>>>>
>>>>>>> BusinessDelegateFactory bdf = BusinessDelegateFactory.getInstance();
>>>>>>> AccountBD accountBD =
>>>>>>
>>>>>> (AccountBD)bdf.createBusinessDelegate(AccountBD.BD_NAME);
>>>>>>
>>>>>>
>>>>>>> So you just end up "plugging" in new implementations as needed.
>>>>>>>
>>>>>>> Anyhow, that's my interpretation of the some of the forces behind the
>>>>>>
>>>>>> pattern
>>>>>>
>>>>>>
>>>>>>> and an idea on implementing it.
>>>>>>>
>>>>>>> Here's more information:
>>>>>>>
>>>>>>
>>>>>>
>>>
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html
>>>
>>>>>>> http://www.developer.com/java/other/article.php/626001
>>>>>>>
>>>>>>> robert
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Adam Hardy [mailto:[EMAIL PROTECTED]
>>>>>>>> Sent: Tuesday, March 16, 2004 6:26 PM
>>>>>>>> To: Struts Users Mailing List
>>>>>>>> Subject: action - delegate - facade
>>>>>>>>
>>>>>>>>
>>>>>>>> I've just been perusing the archive to check out what people have
>>>
>>> been
>>>
>>>>>>>> saying about struts to EJB interfacing.
>>>>>>>>
>>>>>>>> One thing that occurs to me is that the only reason mentioned for
>>>>
>>>> having
>>>>
>>>>>>>> a business delegate layer between the Actions and the Session Facade
>>>
>>> is
>>>
>>>>>>>> to allow for loose coupling of the struts-dependent code with the
> EJB
>>>>>>>> dependent code.
>>>>>>>>
>>>>>>>> How necessary is that? If you choose to drop EJB and go with, say
>>>>>>>> Hibernate, you would have to modify the interface, whether it is the
>>>>>>>> Action - Facade interface or the Delegate - Facade interface.
>>>>>>>>
>>>>>>>> Or have I missed an important other reason for the existence of the
>>>>>>>> Delegate layer?
>>>>>>>>
>>>>>>>> Adam
>>>>>>>> --
>>>>>>>> struts 1.1 + tomcat 5.0.16 + java 1.4.2
>>>>>>>> Linux 2.4.20 Debian
>>>>>>>>
>>>>>>>>
>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>> 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]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> struts 1.1 + tomcat 5.0.16 + java 1.4.2
>>>>> Linux 2.4.20 Debian
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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]
>>>
>>>
>>
>>
>> --
>> struts 1.1 + tomcat 5.0.16 + java 1.4.2
>> Linux 2.4.20 Debian
>>
>>
>> ---------------------------------------------------------------------
>> 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]
