Difference between revisions of "Issue:Modularize DPL Code"

From FollowTheScore
Jump to: navigation, search
Line 38: Line 38:
 
:::<pre>{{rflxv|label=chapter1|this is {{rflxv|label=overlap1|two chapters}}}}{{rflxv|label=overlap1| overlapping each other}}</pre>
 
:::<pre>{{rflxv|label=chapter1|this is {{rflxv|label=overlap1|two chapters}}}}{{rflxv|label=overlap1| overlapping each other}}</pre>
 
:::You'd just have to get the transclusion code to recognize "label." —[[User:Sledged|Sledged]] ([[User talk:Sledged|talk]]) 00:15, 19 December 2007 (CET)
 
:::You'd just have to get the transclusion code to recognize "label." —[[User:Sledged|Sledged]] ([[User talk: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? [[User:Gero|Gero]] 09:03, 19 December 2007 (CET)

Revision as of 10:03, 19 December 2007

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)