View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001602||Slicer4||Core: Documentation and Wiki||public||2011-12-01 17:51||2014-05-12 11:52|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0001602: "tag" to identify CLI executables|
On Thu, Dec 1, 2011 at 10:30 PM, Andriy Fedorov <firstname.lastname@example.org> wrote:
|Tags||No tags attached.|
related to this, it might be helpful to have "tags" to organize other modules, not only CLIs.
For example, Editor is a "Core" module, but also it is a "Segmentation" module.
I think there are 2 separate issues:
By saying "tag", I wanted to emphasize that each module can have multiple "tags". I like "categories" call -- but this is just a different name, right? Category is fine, I guess "CLI" can be one of the categories in one of the taxonomies for the modules. does it make sense to add "CLI" as a category?
About your suggestions to query class name, this is an option, but keep in mind that users who need to know this may not be programmers. These are people who just want to quickly script pipelines (not necessarily with Nipype). IMHO, as long as we have a documentation, and it is not overwhelming, it should be ok to use any reasonable approach.
Multiple categories is supported in r19133.
A very short term solution would be to manually categorised every module.
Solving 0001522 would help, a central location where information associated with a module could be created. It means, the categories associated with each module could be centralised in one document available on the wiki.
Ultimately, since the category (CLI, Lodable, scripted) is represented by the location of the source within slicer repository .. we could think of extracting this "category" from the path. This could work is we assume that extension will also respect that naming scheme ... not sure if that would be the case. Indeed, the example of simple git repo containing one CLI doesn;t allow to do so.
It means the solution will be a "mix" of the following:
Again .. issue 0001522 is the show stopper :(
To make sure we all talk of the same:
Sounds good. We could introduce an additional xml element named "type" that would be either "CLI, loadable, scripted".
Within mediawiki, it would still be a Category. The same way there is Filtering, etc ...
IMHO, the solution that involves categorization based on parsing of path + categories() call, and differentiating bw extensions is an overcomplication.
I would delegate the task of "categorization" to the module developer, and use just module API to get the list of categories. Yes, we would have to categorize the existing modules, but forward-looking, this is a very manageable solution. Developer is the ultimate expert to assign categories.
To handle "Loadable"/"CLI"/"Scripted" categories/tags, how about having the appropriate superclass adding the proper tag to the list of categories returned, and make it a rule to call superclass categories() in the child?
All CLIs are coming through qSlicerCLIModule.h, scripted through qSlicerScriptedLoadableModule, what do you think?
I was talking about mediawiki categorisation ... not within python or c++.
And as you mentioned, within c++/python the module itself will easily now which type it is because it derive from either qSlicerCLIModule, qSlicerScriptedLoadableModule, etc ...
|2011-12-01 17:51||jcfr||New Issue|
|2011-12-01 17:52||jcfr||Reporter||jcfr => fedorov|
|2011-12-12 07:39||finetjul||Status||new => assigned|
|2011-12-12 07:39||finetjul||Assigned To||=> jcfr|
|2012-01-23 08:52||fedorov||Note Added: 0003519|
|2012-01-23 19:59||finetjul||Note Added: 0003521|
|2012-01-24 17:21||fedorov||Note Added: 0003524|
|2012-01-25 10:37||finetjul||Note Added: 0003526|
|2012-01-25 11:44||jcfr||Category||Documentation => Slicer Wiki|
|2012-01-25 12:23||jcfr||Note Added: 0003535|
|2012-01-25 12:23||jcfr||Relationship added||child of 0001522|
|2012-01-25 12:32||finetjul||Note Added: 0003536|
|2012-01-25 12:41||jcfr||Note Added: 0003538|
|2012-01-25 14:23||fedorov||Note Added: 0003545|
|2012-01-25 14:41||jcfr||Note Added: 0003547|
|2012-02-02 03:22||jcfr||Relationship deleted||child of 0001522|
|2012-02-02 03:22||jcfr||Relationship added||related to 0001522|
|2012-05-15 14:56||jcfr||Category||Slicer Wiki => Documentation & Wiki|
|2012-08-21 11:59||jcfr||Target Version||=> Slicer 4.3.0|
|2013-08-30 20:31||jcfr||Target Version||Slicer 4.3.0 => Slicer 4.4.0|
|2014-05-12 11:52||jcfr||Status||assigned => acknowledged|
|2014-05-12 11:52||jcfr||Target Version||Slicer 4.4.0 =>|
|2014-05-12 18:59||jcfr||Relationship added||related to 0003474|
|2016-06-20 14:15||jcfr||Category||Core: Documentation & Wiki => Core: Documentation and Wiki|