[pmwiki-devel] how to access MatchCount from pagelist

[Peter Bowers]

On Fri, Feb 13, 2009 at 4:52 PM, Patrick R. Michaud <pmichaud at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pmichaud.com/pipermail/pmwiki-devel/attachments/20090214/32811db9/attachment.html