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)