Also, I have sometimes used this pattern for sub-components like the two you
described (instead of assigning a synchronized EO to a class variable).
1. editMember with "member" binding
public Member member() {
return (Member)valueForBinding("member");
}
public void setMember(Member newMember) {
//do nothing
}
2. editAddress component with "address" binding
public Address address() {
return (Address)valueForBinding("address");
}
public void setAddress(Address newAddress) {
//do nothing
}
Tim
UCLA GSE&IS
On Oct 29, 2012, at 8:50 AM, Miguel Torres <w...@toracom.net> wrote:
> Hi Tim,
>
> I will double check the code today, there is something in it that is calling
> the address() method after the awake() method, before the end of the request.
> I think that's the key of my problem.
>
> Thanks.
>
>
> On 26/10/2012, at 21:28, Tim Worman <li...@thetimmy.com> wrote:
>
>> Miguel:
>>
>> I often use lazy synchronization and I haven't typically needed any kind of
>> component initialization to correct problems. Can you give us a code snippet
>> for the lazy synchronization looks for your subcomponents?
>>
>> Tim
>> UCLA GSE&IS
>>
>>
>> On Oct 26, 2012, at 4:16 PM, Miguel Torres <w...@toracom.net> wrote:
>>
>>> Hi List,
>>> I recently begun using lazy synchronization. Chuck Hill solved some doubts
>>> that I had.
>>>
>>> It works fine in cases Component -- > subcomponent.
>>>
>>> But in cases Component --> subcomponent --> subcomponent is not working
>>> properly.
>>>
>>> I have this scenario:
>>>
>>> 1. A memberCatalog component. (A grid with the member's information).
>>> 2. An editMember sub component with a "member" binding.
>>> 3. An editAddress sub component inside editMenber with an "address" binding.
>>>
>>> Sub components 2 and 3 use lazy synchronization.
>>> We have a navigation bar in editMember component with a Next Record button
>>> that calls a function that gets the next member and sets it to the object
>>> connected to the edit form.
>>>
>>> This is the case where lazy synchronization is not working properly:
>>> I have 2 members in my catalog.
>>> I select the first one.
>>>
>>> Both, editMember and editAddress loads properly. I see the correct
>>> information of the member and its address.
>>>
>>> I click on Next Record button and this sequence occurs:
>>>
>>> 1. The request begins. The awake method of editAddress is called and all
>>> objects related to the bindings are set to null.
>>>
>>> 2. The awake method of editMember is called and all objects related to the
>>> bindings are set to null.
>>>
>>> 3. The address() method of editAddress is called several times (I do not
>>> know why) and because the address object was set to null previously, the
>>> address object is pull from the parent component. The problem is that the
>>> address that is set is the address of the actual member not the next member.
>>>
>>> 4. The nextRecord method is called and it gets the new member.
>>>
>>> 5. The request ends.
>>>
>>> 6. The response begins.
>>>
>>> 7. The member() method is called several times and it returns the correct
>>> member because it was set by the nextRecord method previously.
>>>
>>> 8. The address() method is called several times. The problem is that the
>>> address object is not null because of the call of the address() method
>>> (step 3) after the call of the awake method (step 2).
>>>
>>>
>>> I solved it this way:
>>>
>>> Each sub component has an initComponent object of the class Boolean that is
>>> set via bindings.
>>>
>>> Each sub component has an initialize() method that is called by the
>>> appendToResponse method.
>>>
>>> Inside the initialize() method we do task like filling NSArrays connected
>>> to popUpButtons, etc. The basic structure of the method is as follows:
>>>
>>> private void initialize(){
>>> if(initComponent){
>>> //// Do my stuff
>>> initComponent = false; // If the user submits the form but the
>>> record does not change initialize does nothing.
>>> }
>>> }
>>>
>>> The change I made is that inside the initialize method I set to null the
>>> objects related to the bindings. That way every time I go to the next
>>> record I set the initComponent's objects to true and it forces the
>>> subcomponents to reset the objects related to the bindings and next time
>>> the address() method is called it pulls the correct address from the parent
>>> component.
>>>
>>> I am not sure if I am solving a problem that was caused by a bad
>>> implementation of lazy synchronization. I have reviewed serveral times the
>>> documentation and my code and I can't find errors (But maybe I see what I
>>> want to see, I am kind of tired).
>>>
>>> So, I will appreciated any comment.
>>>
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/lists%40thetimmy.com
>>>
>>> This email sent to li...@thetimmy.com
>>
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
