The current implementation of pattern dependencies runs all patterns every single time a depending pattern is run. This may not be what a pattern writer wants, especially if all we want to do is ensure that a pattern has already been run once.
For example, if I have a pattern creating a bunch of content, there is no reason to create or update the content type again if it was already created in the pattern dependency.
The attached patch implements the following functionality:
Always re-run pattern dependency (re-run, update, or first run) -- this is the current behavior
<pattern>pattern_name</pattern> or <pattern run="re-run">pattern_name</pattern>
Run pattern dependency only on update or first run
<pattern run="update">pattern_name</pattern>
Run pattern dependency only on first run (it hasn't been run before)
<pattern run="first run">pattern_name</pattern>
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | dependency_run-590380.patch | 1.73 KB | andrewlevine |
| dependency_run.patch | 1.54 KB | andrewlevine |
Comments
Comment #1
andrewlevine commentedoops, getting rid of unused variable and making the conditional a little bit clearer
Comment #2
vaish commentedI really like the idea of having this functionality built into patterns. It makes patterns much more flexible. I looked at your patch and I like more first version without empty if statement. What do you think if we stick to approach from original patch and just add nice comment before the if statement? Also, do we even need 're-run' option since that's a default behavior and can be achieved by not specifying run attribute at all?
Thanks
Comment #3
andrewlevine commentedThere is functionally no difference between the first and second patch. The first patch declares a variable which is never used (which is sort of confusing and a borderline bug). I prefer the ability to explicitly define the run attribute even if it is the default (just to be clear), but it's OK if you want to take that out.
Otherwise, there isn't really a difference between the two patches. Let me know if you need anything else from me to get this committed.
Comment #4
vaish commentedHi Andrew,
After discussing this with Sarva today we decided to further expand on your idea and provide an option for users to select this setting within UI at the time of form submission. We also changed default behavior and added few more run options.
Reasoning behind this update was that different use cases require different default behaviors even for the same pattern file. Having this configurable on each form submission makes everything easier. Of course, specifying this within pattern file will still work and it will currently override UI setting (ideally we should make this more flexible).
I just committed initial version and would like to hear how well this fits your requirements and any ideas/patches how to improve it.
Default behavior now is "first run or update" and this is the complete list of options:
first-update => only if disabled or if updated since last run (recommended)
always => always
update => only if updated since last run
first => only if disabled
never => don't run sub-patterns at all
Cheers,
Vaish
Comment #5
andrewlevine commentedHey Vaish, thanks for making these changes. I hope to get around to testing them on our setup shortly
Comment #6
vaish commented