[Pmwiki-users] PmWiki skinning

Patrick R. Michaud pmichaud
Mon Nov 8 14:56:36 CST 2004


On Tue, Nov 09, 2004 at 09:56:15AM +1300, John Rankin wrote:
> I'm still grappling with a related skins issue.
> Is there a preferred approach in situations where:
> - an action other than 'print' (in my case 'publish') 
>   uses a print.tmpl
> - the script disables the scripts/print.php call
> - other customisations may load after the script and
>   overwrite the template setting, so you get the screen
>   template by mistake, instead of the print one

I don't know that there's a "preferred approach" -- in case it's not
obvious, I'm still struggling with skins as well (and have been struggling
since the earliest days of PmWiki)!  

But here's some stream-of-consciousness thoughts, for what they're worth
(these comments apply to PmWiki 2--let me know if you're looking for a
PmWiki 1 perspective):

> - an action other than 'print' (in my case 'publish') 
>   uses a print.tmpl

In some sense perhaps 'publish' is different from 'print', and therefore
ought to provide a separate $PublishSkinsFmt variable which defaults to 
print.tmpl if publish.tmpl doesn't exist.  

> - the script disables the scripts/print.php call

The publish.php script could explicitly require and include print.php, 
even if an administrator has otherwise disabled the scripts/print.php call.  
Or, publish.php could simply duplicate the settings that print.php normally
makes, so that it still works even if print.php is disabled.

> - other customisations may load after the script and
>   overwrite the template setting, so you get the screen
>   template by mistake, instead of the print one

Well, I don't think it's possible to develop a system whereby we can
anticipate the interactions between all customizations.  But I can see
the problem you're describing, and yes, we should do something about it.

> One approach would be:
> -  provide an array of actions that invoke the code to
>    activate print.tmpl; by default, $PrintActions = array('print');

Possibly, but this feels too "hackish" to me, and IMO skinning system
is already bloated with hacks (and progressively getting worse).  I feel
there must be a cleaner, more generic solution in here somewhere.  
Indeed, when it comes to the skins system I often feel like we're missing 
something obvious, although it may just be that this is an inherently 
complex problem because of the tools (XHTML, CSS, browsers, URLs) that we
are constrained to work with.

Let's see if we can approach this from a slightly different angle.
Essentially what we're wanting is a means of choosing an appropriate
skin based on the site's default skin setting ($PageSkinFmt), the name 
of the current group and/or page, and on the action to be performed.  
Also, there are at least three types of items that can be affected by 
these settings:
    - the template (HTML) file to be used,
    - the associated CSS stylings, and
    - values of key PmWiki variables (e.g., link formats,
      page header/footer formats, etc.).
Since each of these things appear in different files and places, we may not
be able to just say "oh, everything is controlled by this single XYZ file"--
there are likely to be interactions and dependencies between them that cannot
be completely automated.

But we should be able to do better than what we have--I just haven't
come across it yet.  And I think that further variable proliferation 
at this point would be heading in the wrong direction, adding more weight to
a weak foundation.  What we need is a better foundation.

Anyway, I'm still willing to make substantial changes to PmWiki's 
"skin-selection" algorithm, but keeping in mind that PmWikiPhilosophy #5 
(ease of installation and configuration) is a controlling factor.  Whatever 
we come up with must be accessible--in the sense of a short learning 
curve--to new administrators who want to make simple skin changes or 
a new custom skin.  (And remember that what is transparently simple to
one person is often opaquely or unnecessarily complex to others.)  One 
of the comments I hear quite frequently from PmWiki adopters is 
"I don't know a lot about HTML or CSS", and I definitely don't want to 
move away from the needs of that audience/market, so whatever we come
up with has to be transparent, even if it's not the cleanest approach
for administrators who *do* understand HTML and CSS.

Pm



More information about the pmwiki-users mailing list