On May 27, 2011, at 2:21 PM, David García Garzón wrote: > On Thursday 26 May 2011 22:33:34 Xavier Serra Román wrote: >> On May 26, 2011, at 10:13 PM, David García Garzón wrote: >>> Forwarded to the list, sorry, the original message from Xavi was in >>> catalan. >>> >>> A Dijous 26 Maig 2011 18:22:17, Xavier Serra Román va escriure: >>>> Ei David! >>>> l'altre dia vam parlar del camí a seguir amb el configuration i vas dir >>>> Add, Removes... Amb això vols dir per exemple: >>>> proxy["new_attribute"] = 'newvalue' ? >>>> Fins ara sempre consideravem això com a AttributeError. I en cas >>>> afirmatiu, com es fa? He vist el AddAttr_ de la interfície de >>>> DynamicType però pren dos valors enters i és protected >>>> >>>> Bye! >>> >>> We should concentrate first in being able to do the same things that we >>> support right now with dummy: Plain type checked attributes but no >>> optionality (the add/remove thing you asked) and no composite >>> attributes. Looking at the source i still miss some features for the >>> clam config proxy: >>> - Errors on accessing wrong attribs should match the ones raised by dummy >>> - implement __setitem__ to set the config value. >>> - Error on type missmatch al __setitem__ >>> - keys() >>> >>> Once this is done, comparing dummy and clam tests they should be quite >>> uniform. We can postpone optional and composite attributes implementation >>> while going forward to something that it is usable yet, that is, being >>> able to inspect the configuration of an actual processing inside a >>> network and reconfiguring it. So lets consider how to implement >>> Clam_NetworkProxy::processingConfig, first to get the actual >>> configuration, then to modify it (how to apply the configuration which >>> was a tricky issue). >> >> Been thinking about that. What do you think of creating a function inside >> Clam_NetworkProxy that returns a ConfigurationProxy (something like the >> factory method we have inside Clam_ConfigurationProxy) and then pass that >> method to the Configuration python object? It should look something like >> this (in the Processing.py __init__): >> self.__dict__["_config"] = Configuration.Configuration( >> proxy.processingConfigProxy(processingType) ) > > It is not about the type, it is about the processing itself. you want the > processingConfigProxy to have access to the actual configuration values. So > the current interface should work. Just that what > proxy.processingConfig(name) > should return is now a proxy (either dummy or clam), not a dict. > >
I have some questions then. In clam proxy processingConfig should ask the processing for its config object and get the values from there right? How can I do that? I found no GetConfig() method in <CLAM/Network.hxx> or <CLAM/Processing.hxx> And the other question, how can I make processingConfig (clam proxy again) return a Clam_ConfigurationProxy? So far in all my attempts all I got was a class named Clam_ConfigurationProxy but without any of its methods implemented (just an empty Clam_ConfigurationProxy) Bye! _______________________________________________ clam-devel mailing list clam-devel@lists.clam-project.org http://lists.clam-project.org/listinfo.cgi/clam-devel-clam-project.org
