tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Piterman <rpiter...@gmx.net>
Subject Re: [jira] Created: (TAPESTRY-733) Tapestry should call listeners (such as PageBeginRenderListener) in some predefined order
Date Tue, 01 Nov 2005 22:01:32 GMT
I am sure your problem can be solved using the "lazy initialization" method.

As far as I understand this there are two approaches there:

1) the "take an object and edit it" approach.

2) the "take an object *source* (binding) and edit it" approach.

Tapestry form components use the second - they read an write to sources 
(properties) instead of manipulating the values.

You probably want to take that same second approach ( am I right here? )
you want your component to get the clients' address *source* and if its 
empty set it.

what about this:

<parameter name="address" property="addressParameter"/>

now in the component code you don't use the parameter directly but 
abother method:

public Address getAddress() {
   Address a = getAddressParameter();
   if (a == null) {
     a = createNewAddress();
     IBinding binding = getBinding("address"); // am not certain its the
                                               // right syntax here
     binding.setValue(a);
   }
   return a;
}

now this way, the first component which accesses the clients address 
will initialize it and set it back to the client.

all following components will use the same one.

???
Cheers,
Ron




ציטוט Leonardo Quijano Vincenzi:
> Ron Piterman wrote:
> 
>> There are two things there:
>> The way the components pass the objects is fine - now you have to make 
>> sure, for example, that address is not null. Hope I got that right.
> 
> Exactly
> 
>>
>> If you decide this logic belongs to the UI...
>> placing it in pageBeginRender is a bad idea - Its hard to explain why...
>> I use pageBeginRender to initialize rendering cycle, but not business 
>> or domain logic.
>>
>> What I would do is make proxy methods:
>>
>> on the page:
>>
>> public Address getAddress() {
>>   Address a = getClient().getAddress();
>>   if (a == null) {
>>     a = new Address();
>>     getClient().setAddress(a);
>>   }
>>   return a;
>> }
> 
> Then I'd have to init my whole graph on the page. That's exactly what 
> I'm trying to avoid. I'm working on a system for an insurance seller. 
> So, suppose I have something like this:
> 
> Insurance Policy
> + --- Client
>        + --- Phones
>                 + ---- Phone
>                 + ---- Phone
>                 + ---- Phone
>                 + ---- Phone
>        + --- Address
> + --- HomeInsurance
>        + --- Conditions
>        + --- BuildingAddress
> 
> ...
> 
> etc...
> 
> Note that my Address object is reused on Client (as his home address) 
> and BuildingAddress (as the building he's insuring, not necessarily his 
> home). Putting all that on one page is some monolithic code I'm trying 
> to avoid. It's better to let each FormXXX to define its own default values.
> 
> Now, if we are concerned about web objects doing business 
> initialization, I could always put an object Factory. So, instead of:
> 
> address = new Address();
> 
> I'd use:
> 
> address = getAddressFactory().buildAddress();
> 
> But that's the same whether I put it on my page or on the component.
> Am I explaining myself?
> 
> The bottom line: what I'm trying to avoid is precisely initialization on 
> the page. I'd like to have re-usable components that init themselves 
> (with a 'new XXX()' or a factory method, I don't care), that I can put 
> on a library and reuse on other systems / modules.
> 
> *Now, we are going a bit into a layer division discussion. What if my 
> sub-components are not business objects, but some web model I'm using? 
> (I can't think of an example right now, but there surely must be one). 
> The point is that object composition gets a little clunky if I can't 
> reliably initialize sub-components based on its parent values.
> 
> -- 
> 
> Ing. Leonardo Quijano Vincenzi
> Director Técnico
> DTQ Software


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Mime
View raw message