search

simphony / simphony-mayavi

The mayavi adapters to the simphony framework
BSD 2-Clause "Simplified" License
0 stars 1 forks source link

[WIP] Implement add_dataset and adjusted show/snapshot signature #162

Closed kitchoi closed 8 years ago

kitchoi commented 8 years ago

Reimplemented #136 for a proposal discussed in #134 and https://publicwiki-01.fraunhofer.de/SimPhoNy-Project/index.php/Extend_show_and_snapshot_proposal

It is agreed that a convenient, matlab-like function for selecting data attributes is desirable; and thus the proposal 1 on the wiki page is implemented here, with the least change in the signatures of show and snapshot

kitchoi commented 8 years ago

Indeed I was thinking of the same!

kitchoi commented 8 years ago

There are two goals here, one is about the signature of show and snapshot, for which at this point the preference is towards adding optional arguments to them for selecting data attributes. And for this there are two implementations which I am not yet convinced one is necessarily superior to another.

(1) This PR, which does the attribution selection in a module level function and show and snapshot calls that function. The pros is that it is more lightweight and easier to maintain.

(2) Implement a instance method (initialise or select) or a class method (create_and_select or from_cuds) in CUDSSource so that there is a user friendly method for creating a Source with data attributed selected. Alternative to this is that the __init__ can be overloaded, but this could potentially break Traits(?). Nevertheless, we will have to implement this for CUDSSource and EngineSource so there would at least be some duplicated docstring.

kitchoi commented 8 years ago

The another goal is refactoring.

kitchoi commented 8 years ago

Forgot to mention the pros for implementing CUDSSource.initialise/select/from_cuds is that it can be used with other mayavi.mlab.pipeline function, therefore would be more powerful than add_dataset (this PR) alone. I will implement theCUDSSource class/instance method as well to compare.

kitchoi commented 8 years ago

This PR is to be compared with  #164.
I propose that one of these two approaches be adopted, could be neither, but not both. At the moment, I preferred #164

kitchoi commented 8 years ago

164 is better. Close this one.