Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Dear Maintainers,
I am thinking of creating some SimpleTest for Storm Contrib. As there has been no stable release so far i intent to keep it very simple.
Just enable disable modules and create/update/delete storm nodes and check if it works fine. I figured out that just to test dependencies it almost takes an hour or more to enable and disable the modules in the correct order and test it. Quite often my mind has wandered away from this mundane routine. This issue can also be a common thread to discuss about anybody else who might be interested in writing test cases.
Am uploading the dependency diagram that comes with Storm. Naturally one should follow the same dependency chain. Otherwise a user would find himself turning on those modules which he never want to use.
This diagram would have to be modified to include extra modules which are not just extensions for storm nodes. Also imho ideally any storm contrib extention those extend storm's node, should not be dependent on extra modules provided by storm contrib.
so the dependencies should be like
Storm Contrib's extra features Depends onStorm Contrib's storm node extentions Depends on Storm
==============================================================================
EDIT:
1> Am downloading gpraphviz ( would take hours thanks to slow internet connection )Am using umlet to draw these diagrams, and would upload the template that would be the intended dependency diagram which we would like to achieve. If the dependency diagram is finalized then i can write testcases for testing the same.
2> This thread is not supposed to be a place to report issues. Its rather a discussion on how the dependency should be designed into storm contrib. For reporting dependecy related issues, please visit and update this issue.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | Storm_Contrib_Dependencies_Level_1_20111028_V01_D34dMan.png | 28.59 KB | d34dman |
| #1 | Storm_Contrib_Dependencies_Level_1_20111028_V01_D34dMan.zip | 1.15 KB | d34dman |
| storm_dependencies.png | 12.95 KB | d34dman |
Comments
Comment #1
d34dman commentedthe zip file contains the uxf file that is created using UMLet. will post Level 2 dependencies tomorrow.
Comment #2
d34dman commentedThe reason why i propose the above dependency flow is:
Right now stormtask_extension is dependent on stormticket_extension.
Say for those who never wanted to use stormticket in their setup but only stormtask.
we are forcing them to enable stormticket_extension as well as stormticket. These could be avoided if we use Dependency inversion properly.
So that those feature which need to be called from module on higher level ( like parent/master ) should necessarily check for module_exists('slave_module_name').
Just a thought... open for discussion. Cause storm_contrib is quite a big collection of modules and i know maintainers are already putting a mammoth effort to roll out a stable release. I truly appreciate their effort.
Comment #3
kfritscheI looked into the code and you are right.
It makes no sense that project and task extensions depends on ticket extension.
I moved two functions around and now it works.
stormproject_extension no longer depends on stormticket_extension
stormtask_extension no longer depends on stormticket_extension
Also the extensions doesn't depend on the "higher" extension (stormticket_extension -> stormtask_extension -> stormproject_extension)
Comment #3.0
kfritscheedited the footnote to include more details on how the nature of task is supposed to be.