Commit graph

7 commits

Author SHA1 Message Date
Thiemo Kreuz 74e3dd3f4b Fix strange dialog title when using subst:
When I type e.g. "subst:example" as the template name, we made this
work as the user would expect: the template named "Example" is found
and it's TemplateData documentation used. But the dialog title shows
"Subst:example". Note the uppercase "S". It means this string is
parsed as a title, including the "subst:". This is confusing. Just
show the template name.

Change-Id: I9817786991a8379cf48b0a664aef1413abddee2d
2021-10-08 16:00:29 +02:00
Thiemo Kreuz 06cf00f4c6 Rename and document select/focus events in template dialog
I tried hard to come up with the best possible names. Some of the
criteria I used:
* Longer and more unique is better. This makes it much easier to
  e.g. search for the event name.
* The term "part" should only be used for top-level parts. While
  template parameters have a unique id, they are not a subclass
  of …TransclusionPartModel and therefor not "parts".
* BookletLayout manages "pages" via "page names".
  * The page names of top-level parts are identical with the part
    id, see ve.ui.MWTemplateDialog.getPageFromPart.
  * The page names of parameters are identical with the parameter
    model id, see ve.ui.MWTemplateDialog.onAddParameter.

Some code knows parameter ids, but not what pages are. Other code
knows page names, but not what parameters are. The transition
currently happens in the …OutlineContainerWidget. We might want
to move this point up to the …TemplateDialog. But I would argue
this is good enough for now and can be changed later, if needed.

Bug: T285323
Change-Id: Iab2805b3203988db400b67c8d00e48905fdc53dc
2021-09-01 16:23:59 +00:00
Thiemo Kreuz 926913cad6 Add/simplify assertions in transclusion outline related code
Bug: T289560
Change-Id: Ia76e13582a182c8184b3e8642c5c03bf3d674a24
2021-08-30 14:58:50 +00:00
Thiemo Kreuz 115441b5d8 Add rather complex QUnit tests for transclusion outline code
These are more integration tests than actual "unit" tests. What
the tested code does depends a lot on e.g. how the model and
spec classes behave, and even on some events. Which is good. We
want to cover all of this with tests. The only question is: Is
there a good way to make these tests easier to read, while they
still cover the same code?

Bug: T289560
Change-Id: I8c681f161c272d143a07ca4d0080b4089b48bcb6
2021-08-28 12:34:36 +00:00
Thiemo Kreuz 1f19d85ea8 More test cases for more complex template dialog functionality
Contains:
* Full test coverage (I believe) for the filter functionality in
  …OutlineTemplateWidget.

Also some TODOs for missing tests I believe are critical.

Bug: T289560
Change-Id: I2ac5add8e189d501d3558bbd4854cb92155bcb96
2021-08-28 14:02:57 +02:00
Thiemo Kreuz 352e7795ca More meaningful assertions for all outline part widgets
Bug: T289560
Change-Id: I81f882d6e6793198371ff9ff3e1e5bbbec98e0d9
2021-08-24 13:17:16 +02:00
Thiemo Kreuz f6953d4096 Add basic QUnit tests for all transclusion outline classes
This is just the smallest possible boilerplate to get the first
trivial test running. More test cases will be added in the
following patches.

Bug: T289560
Change-Id: I3a4e49a7b9761db00b211e933386bad71d4f0942
2021-08-24 11:31:14 +02:00