On Fri, Feb 13, 2009 at 4:52 PM, Patrick R. Michaud <pmich...@pobox.com>wrote:
> On Fri, Feb 13, 2009 at 10:07:49AM +0100, Peter Bowers wrote:
> > Right now pagelist is constructed somewhat as a chain link.
> > FmtPageList calls $fmtfn (usually FPLTemplate()) which calls
> > makepagelist(). No ifs, ands, or buts -- one calls the other
> > which calls the last one. As a result there's very
> > little possibility of any interaction in the process there...
>
> False. One can easily change $fmtfn to call whatever sequence
> you prefer -- indeed, that's why it exists.
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...
>
> > If it were structured like this (function names intended for
> > self-documentation, not for actual use):
> >
> > function DoAPageList()
> > {
> > PageListOptionSetup();
> > $matchlist = MakeListOfPages($selection_options);
> > FormatPageList($matchlist, $formatting_options);
> > }
>
> The reason why FPLTemplate() does the call to MakePageList()
> is that we want it to be possible for the template to supply
> default options to the pagelist (via the (:template default ... :)
> markup). Thus the MakePageList() call has to occur _after_
> we start processing the template.
>
> > Basically what I'm suggesting [...] is
> > to separate the functionality of a pagelist. (a) Part of it is setting
> up
> > defaults and options. Another part (b) is getting the appropriate list
> of
> > pages. The last part (c) is actually formatting said list.
>
> Since the formatter has/wants the ability to influence the
> "get the appropriate list of pages" part, it's not quite as
> straightforward as this.
>
> I suppose it would be possible for us to parse the template
> page twice, or to try to otherwise breakup FPLTemplate into
> separate stages for "getting options" and "generating the list",
> but when I mentally try to code it that way I get a bad feeling
> about the result.
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...
[All previous caveats about tightly optimized code and etc. still valid]
-Peter
_______________________________________________
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
