since that will
allow you to clean domains from the DOM as well.
OK. But when you said:
Honestly domains should not be saved in the normal state as well,
since we never load them back.
They never get loaded back, so their presence won't have a negative
effect. Besides, if they're not used then there's no reason to have them
in the state machinery at all. If that's the case we shouldn't let them
influence the design of a new feature. Perhaps domains should just be
eliminated from state.
Although practically speaking generating the full dom and cleaning won't
have a noticeable impact on performance for configuration since they are
small sets of properties, it just it feels iky. But if that's what you
want I'm game :)
Burlen
Utkarsh Ayachit wrote:
Burlen,
Further thinking about this, I think filtering the DOM before saving
out the configuration (rather than changing SaveState() signature to
take optional list of properties) maybe even better, since that will
allow you to clean domains from the DOM as well.
Utkarsh
On Fri, Feb 26, 2010 at 4:15 PM, burlen <[email protected]> wrote:
Hi Utkarsh,
Just to summarize our off list conversation in case any one else is
following this thread:
We'll not use my new serialization code but rather the current public
methods vtkSMProxy::LoadSate/SaveState . We'll add an additional optional
argument to the method signatures so that the properties to be saved or
loaded can be filtered (eg filter camera related properties in
vtkSMRenderViewProxy when saving camera configuration).
I'll send the fix as soon as I can.
Thanks again
Burlen
Utkarsh Ayachit wrote:
Hi Burlen,
The functionality is indeed great. The only hesitation I have is with
burdening server manager code with another serialization code. My
comments are inlined.
One substantial difference is that connection id is central in the state
implementation. however not only is it not needed for configuration but
it
cannot be used with configuration. So for configuration the lack of a
connection id is a central feature.
Not necessarily true. If you look at vtkSMProxy. It has a method
LoadState() which simply takes in the XMLElement to simply load the
given state on the proxy. If you look at vtkSMDeserializer (the base
class for state loaders), by providing a right locator to locate the
proxy that the state XML is asking for, the connection id doesn't even
come in the picture. Further more, you can easily provide a totally
separate state loader class for the configuration without having to
add any thing to the properties, proxies
Another distinction is that the state of domains aren't needed by
configuration.
Honestly domains should not be saved in the normal state as well,
since we never load them back.
But I agree with you that your configuration files are much easier to
edit and read. An alternative solution would be keep that code
isolated i.e. we don't really need to add the Save/Load methods to
vtkSMProxy, vtkSMProperty etc. for the configuration, you can always
simply get/set the property values in your serializer/loader classes.
What do you think?
Utkarsh
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
