Last modified: 2014-09-04 09:59:26 UTC
Add a way to mark a parameter to be dependent on an other paramter. For example : We have following parameters: "foo1_bar", "foo1_baz", "foo1_quux" ... "fooN_bar", "fooN_baz", "fooN_quux" fooX_bar required fooX_baz to be used as well, it doesn't require fooX_quux to be used, but if fooX_quux is used, then fooX_bar must have been defined as well
See also [[User:קיפודנחש/TemplateParamWizard#Depends on]].
Change 73708 had a related patch set uploaded by AzaToth: Add depends and conflicts parameters https://gerrit.wikimedia.org/r/73708
Note that as for a parameter "going together with" other parameters, this is what a "Set" is for. Though Sets are merely suggestive and allow for overlap, it us a lot easier to work with from a user interface perspective. Though TemplateData is generic and should not be tailored specific for VisualEditor, right now I'd recommend we hold off on this change until we find out and/or verify that this can be properly represented in a user interface without making it too complex.
(In reply to comment #3) > Note that as for a parameter "going together with" other parameters, this is > what a "Set" is for. > > Though Sets are merely suggestive and allow for overlap, it us a lot easier > to > work with from a user interface perspective. Set doesn't make any sense for parameters like "author1, author2, ..., authorN" > > Though TemplateData is generic and should not be tailored specific for > VisualEditor, right now I'd recommend we hold off on this change until we > find "depends" and "conflicts" are pretty much not tailored for VE at all (Though I could agree, sets are). > out and/or verify that this can be properly represented in a user interface > without making it too complex. The most important thing is that common templates can be modeled correctly without ending up with too many false choices, or hiding true choices because they couldn't be modeled correctly.
at en.wp a user has given the example of [[template:for]] where parameter 3 is optional unless parameter 4 is specified, when it becomes mandatory. They expected that VisualEditor would give them a warning about using parameter 4 without parameter 3. Obviously this is not possible until TemplateData can define such relationships.
Change 73708 abandoned by Krinkle: Add depends and conflicts parameters Reason: Closing for now to clear review backlog. Can be re-activated when the feature request is accepted. https://gerrit.wikimedia.org/r/73708
[Moved from bug 60358 discussion.] (In reply to Helder from bug 60358 comment #10) > (In reply to James Forrester from bug 60358 comment #9) > > (In reply to Helder from bug 60358 comment #8) > > > (In reply to James Forrester from bug 60358 comment #6) > > > > (In reply to Ricordisamoa from bug 60358 comment #5) > > > > > or a set of fields may be mutually exclusive (and yet one of them would > > > > > be required). > > > > > > > > That doesn't make sense. "Required" means "the template will die horribly if > > > > you don't include this". It is *not* a "we'd like you to fill this in" – > > > > that's what "suggested" is for. Most templates will have no 'required' > > > > fields. > > > > > > It seems perfectly valid for a template to require that "either A or B be > > > provided" and the user should be able to delete one of them if it is not > > > needed. > > > > This feels like a pretty edge case (and suggests that we should consider > > whether the template should be re-written to be less anti-human); maybe file > > a TemplateData bug to ask for a way to express this relationship? > > This kind of relationship between parameters was requested on bug 50407. Well, as I see it, this bug only asks for param-level relationships – if A also B; if C not D; etc. Should we extend it for shared-param relationships (exactly one of A, B and C are required; D is an alias for E if F is set but is an alias for G if F is not set; …), or should we create a new bug? (BTW, this feels like a potentially ever-expanding system could be created, and we'd probably say this adds too much complexity for the value.)
