Re: Manual syncing question
Re: Manual syncing question
- Subject: Re: Manual syncing question
- From: Chuck Hill <email@hidden>
- Date: Mon, 18 Sep 2006 10:35:00 -0700
Hi Miguel,
On Sep 16, 2006, at 4:51 AM, Miguel Arroz wrote:
I agree with your opinion about manual sync, that's why I'm
trying to use it now. The stateless... well... one step at a time! :)
What confuses me is the problem I stated, ie, if I call user()
like 20 times in a row, WO will fetch the object 20 times.
It should not fetch it, just get the value from the parent. If the
parent is fetching it each time that method is call, then that is a
different problem.
The point to keep in mind is that manual synchronization is more
work, not less work, than the automatic one. In exchange for the
more work you get more control and potentially better performance.
Isn't there a takeValuesForBindings replacement for manual synch
components? Something like "gentleman, if you know you will need
some bindings a lot of times and want to fetch them in one place,
please get them now!".
Either awake() or in each phase, as needed. Stateless components
make this easier with the reset() method. You could try overriding
public void pullValuesFromParent(). I don't recall if that gets
called or not when not synchronizing. I know that if called, it does
nothing if the component is not synchronizing.
It usually makes more sense to set them to null once, usually in
appendToResponse before calling super, and then pulling the values on
demand if null.
The suggestion of implementing a reset() method and calling it on
the takeValuesForBindings, invokeAction and so might work, but
seems a little... durty. Specially because it violates the golden
rule on Practical WO book!
I have never needed to do this, so I suspect that you are still
planning on pulling them too often.
Chuck
On 2006/09/16, at 05:44, Kieran Kelleher wrote:
Miguel,
You may write a little more code (doing the lazy initialization of
bindings ) however overall it is more efficient and predictable
behaviour. With auto sync, the bindings are sync'ed 6 (SIX!) times
during R-R. With your lazy pulling of bindings, they are only
pulled ON DEMAND and only those referenced are pulled..... so
*some* are pulled maybe 3 or less times per R-R and very few are
pushed maybe once or twice per R-R. Rarely are any pushed for
typical subcomp usage unless you do a setValueForBinding for some
specific cases. So there is a lot less pushing and pulling. Plus,
all those bindings that are NOT required by your subcomponent with
all its conditionals, etc are not touched. The bottom line is LESS
work being done in the WO framework and MORE PREDICTABLE state of
the values you are working with in code .... less magic sometimes
means more robust and predictable code.
Additionally going manual sync brings you halfway to the panacea
of stateless components which result in less memory footprint due
to reuse of components and less expensive class instantiation.
Stateless brings its own behaviour which means you sometimes have
to worry about maintaining state across the R-R cycle. This can be
done using ERXThreadStorage or some other mechanism. But if you
are dealing with and values which are stored in the root stateful
page component and whose references are pulled with bindings, then
you don;t have to worry about their state across resets since the
state is kept in the top parent WOComponent.
For stateless the "reset()" is mandatory but can be a PITA to
remember to "maintain" the iVars to reset if you are fiddling with
a component during its development. For this I wrote a generic
reset pattern that resets iVars that are a specific kind. Details
here.
http://homepage.mac.com/kelleherk/iblog/C1133025376/E1146937278/
index.html
Also,
http://homepage.mac.com/kelleherk/iblog/C1133025376/E1896801830/
index.html
Hope That Helps, Kieran
On Sep 14, 2006, at 8:19 PM, Miguel Arroz wrote:
Hi!
I'm trying to follow the advice I received on WWDC from
experienced people to avoid using components that auto-synch
their values (ie, the normal way WO works). I was open to this
suggestion because I was having some problems that were clearly
related to auto-syncing.
So, I'm trying to make some subcomponents that do not use auto-
sync. It works great for some stuff (like binding actions,
yahoo!) but there are some other stuff that I guess I'm not doing
right.
Imagine I have on the top component an object, say, an User. I
want to bind the User object to a subcomponent inside the top
component. The subcomponent does not auto-sync.
So, I override the synchronizesVariablesWithBindings method on
the subcomponent, and I create a method, called user:
public User user() {
return (User)valueForBinding(USER_BINDING_NAME);
}
Well, but this is stupid. I'm actually doing a lot more work
(with valueForBinding) than what was done on auto-synch. Every
time I access the user, WO goes and grabs the binding. This is a
waste of cycles and does not solve one of the problems that lead
me to try to write non-auto-synching componentes - to control
exactly when is the stuff synced.
I thought about using the subcomponent constructor, but I
tested, and when I regenerate the page with another user (imagine
I click on a "Next" link that shows me another user, but the
parent component it's the same - the method binded to the link
returns null) WO apparently re-uses the subcomponent too, so no
constructor is called.
So... basically... how do you solve this?
<Waiting for a one line reply with a really obvious answer that
I totally missed>
Yours
Miguel Arroz
"The world lies in the hands of evil
And we pray it would last" -- Apocalyptica, Life Burns!
Miguel Arroz
http://www.ipragma.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
@mac.com
This email sent to email@hidden
"GUERRA E' PAZ
LIBERDADE E' ESCRAVIDAO
IGNORANCIA E' FORCA" -- 1984
Miguel Arroz
http://www.ipragma.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden