<div class="gmail_quote">On Fri, Feb 13, 2009 at 4:52 PM, Patrick R. Michaud <span dir="ltr"><<a href="mailto:pmichaud@pobox.com">pmichaud@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Fri, Feb 13, 2009 at 10:07:49AM +0100, Peter Bowers wrote:<br>
> Right now pagelist is constructed somewhat as a chain link.<br>
> FmtPageList calls $fmtfn (usually FPLTemplate()) which calls<br>
> makepagelist(). No ifs, ands, or buts -- one calls the other<br>
> which calls the last one. As a result there's very<br>
> little possibility of any interaction in the process there...<br>
<br>
</div>False. One can easily change $fmtfn to call whatever sequence<br>
you prefer -- indeed, that's why it exists.</blockquote><div><br>Yes, and this is what I was referring to in the beginning of this thread wrt copying FPLTemplate and making changes to it. That's certainly a possibility. It has the unfortunate side effect of "bloating" a recipe with a significant amount of code which is simply copy/pasted from existing core functions [besides the disadvantage that when/if core features are added or bugs fixed it would be nice to not have to duplicate those changes in a redundant piece of code -- replace this sentence with all the usual arguments for avoiding duplicated code). That's what I'm trying to get at -- if I want to use the *existing* FPLTemplate() as a developer (which I want to do because it is a great function which takes the messy and complicated job of virtually a report generator and does it all very nicely) then the way the code is structured becomes a barrier to the re-use of this code. So much of pmwiki has been designed with this type of re-use in mind (and the $fmtfn flexibility does provide a "hook" here) and I'm just suggesting that the same sort of approach be considered here...<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
> If it were structured like this (function names intended for<br>
> self-documentation, not for actual use):<br>
><br>
> function DoAPageList()<br>
> {<br>
> PageListOptionSetup();<br>
> $matchlist = MakeListOfPages($selection_options);<br>
> FormatPageList($matchlist, $formatting_options);<br>
> }<br>
<br>
</div>The reason why FPLTemplate() does the call to MakePageList()<br>
is that we want it to be possible for the template to supply<br>
default options to the pagelist (via the (:template default ... :)<br>
markup). Thus the MakePageList() call has to occur _after_<br>
we start processing the template.<br>
<br>
> Basically what I'm suggesting [...] is<br>
<div class="Ih2E3d">> to separate the functionality of a pagelist. (a) Part of it is setting up<br>
> defaults and options. Another part (b) is getting the appropriate list of<br>
> pages. The last part (c) is actually formatting said list.<br>
<br>
</div>Since the formatter has/wants the ability to influence the<br>
"get the appropriate list of pages" part, it's not quite as<br>
straightforward as this.<br>
<br>
I suppose it would be possible for us to parse the template<br>
page twice, or to try to otherwise breakup FPLTemplate into<br>
separate stages for "getting options" and "generating the list",<br>
but when I mentally try to code it that way I get a bad feeling<br>
about the result.</blockquote><div><br>And you're the one with the big picture on the project. From my limited perspective it seems like the double-parse would be a small price to pay for significantly enhanced flexibility from a recipe developer's perspective. But the fact that I didn't even know (:template default ...:) existed points up the fact that I don't know what other pieces may be stepped on in that process... (i.e., whatever it is that is giving you the bad feeling is probably something I don't have a clue about and thus I feel just fine, thank you very much... :-) ) I guess all I'm saying is there would be significant value to it if the restructure were technically feasible without causing other problems elsewhere...<br>
<br>[All previous caveats about tightly optimized code and etc. still valid]<br><br>-Peter<br></div></div>