Issue:Modularize DPL Code

Description:	Break up code into more manageable bits
Extension / Version:	DPL   /   1.6.0
Type / Status:	Change Request   /   open

Problem

See DPL API and No More Globals.

Reply

See DPL API and No More Globals.

Moved From Issue:The include Parameter and Mulitple Template Invocations

The additions you've made [to the transclusion code] are quite nice. You mind if the finished product has them available as stand-alone parser functions? —Sledged (talk) 00:05, 12 December 2007 (CET)

Not at all. I´d be happy to see the results of mudularizing also in terms of easily accesible functional parts from the user´s perspective. As you may have seen I currently do not make significant changes - mostly error corrections. So there would not be much of a conflict if you made greater changes during the next, say, six weeks. Maybe afterwards we could put the sources into a public svn repository, see the discussion on my discussion page.

Especially regarding section transclusion: Unfortunately "section", "chapter" and "paragraph" are not being consistently used in the source code and the doc´s. I recommend the following use:

• A section is a specially labeled portion of wiki text. Sections may be nested and can extend across paragraphs.
• A paragraph is a piece of text which belongs to a headline. A paragraph extends from its heading to the next heading of same level or to the end of the file; so paragraphs can contain headings and other (smaller) paragraphs.
• The word "chapter" is used as a generalization for both concepts.

Regarding the current access to transclusion functionality: the 'title' parameter allows quite a short notation to transclude a chapter, e.g. {{#dpl:title=myDocument|include=mySection}}. The reason is, that "title=" switches off standard output completely. I wonder if a dedicated, separate parser function could offer a shorter syntax.

Gero 08:48, 12 December 2007 (CET)

A separate parser function would still require both parameters. The only way I see the syntax being shorter is if you used ordered arguments instead of assigned arguments: {{#trans:myDocument|mySection}}. Also, if you don't need the call to do anything else that dpl does, it might be better for performance reasons.

Terms: the context of the term "paragraph" might be a bit confusing for readers. We could just call them what they are: "labeled section" and "headed section."

Speaking of shorter syntax, after going through the transclusion code, I think you've almost made the original mechanism for labeling sections obsolete. The "section" tags could easily be replaced with a reflexive template or parser function call.

<section begin=chapter1 />this is a chapter<section end=chapter1 />

could be replaced with

{{rflxv|label=chapter1|this is a chapter}}

where Template:rflxv (reflexive) just spits out the {{{1}}} parameter and ignores all others. Overlapping chapters like the following

<section begin=chapter1 />this is <section begin=overlap1 />two chapters<section end=chapter1 /> overlapping each other<section end=overlap1 />

could be repaced with

{{rflxv|label=chapter1|this is {{rflxv|label=overlap1|two chapters}}}}{{rflxv|label=overlap1| overlapping each other}}

You'd just have to get the transclusion code to recognize "label." —Sledged (talk) 00:15, 19 December 2007 (CET)

---

I agree on the naming. So it´s 'section' in general, 'labeled section' and 'headed section' in particular.

The idea of a simple pass through template might work. But the user would have to be careful if arg1 contained a '='. I predict that some users will not be aware of the problems a '=' within a 'normal' numbered argument will cause.

Also I am not quite sure what happens if the argument of the reflection template contains headings (like '== text =='); there are some limitations to the TOC generation which have to do with templates ...

Anyway, one should create a complex test sample which contains all potentially problematic situations and then demonstrate the pro&con.

As you may have seen I started an initiative to offer modular pieces to the DPL user (dplmatrix being the first sample). How do you think about that? Gero 09:03, 19 December 2007 (CET)

Yes, forgot about the complications of the equal sign. Now that I think about it, theoretically, the text that the user wants transclude could start with "label=". Parser function instead of a template is probably the solution for that. In fact, since all parser function arguments are ordered ones, there'd be no need for named parameters with a parser function call:

{{#sec:chapter1|this is a chapter}}

The trick would be to (a) make sure dpl recognizes the difference between parser function calls and template calls, and (b) treat all parser function parameters and ordered ones instead of named ones. Hard to say at this point whether or not it would have to specifically look for the {{#sec:}} call or not. —Sledged (talk) 21:02, 19 December 2007 (CET)

---

Slow going on the modularization, but here's a small change within the DPL2Include class. Here's a summary of the changes:

• Numbered headed sections, named headed sections, and regex headed sections have been split up.
• The text is run through MediaWiki's sanitizer class to strip out he HTML comments. (They we being included with matching.)
• Number sections now take any integer value, whereas before it only took 0, −1, and positive integers. Where −1 gets the last section, −2 now retrieves the second to last section, −3 gets the third to last section, and so on.

—Sledged (talk) 00:38, 25 December 2007 (CET)

Update

Still slow going, but making headway. —Sledged (talk) 22:45, 9 September 2008 (UTC)

Nice to hear! I plan to make some minor improvements and bug fixes within the next 4 weeks or so. Would you be able to inttegrate those into your version?

Gero 08:48, 10 September 2008 (UTC)