Difference between revisions of "Issue:Modularize DPL Code"
From FollowTheScore
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 09: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.
- 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)
- 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:
- 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)