[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