[Pmwiki-users] PmWiki skinning
John Rankin
john.rankin
Mon Nov 8 18:21:52 CST 2004
On Tuesday, 9 November 2004 10:56 AM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
...
>
>> - 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.
Another variable doesn't feel quite right to me.
...
>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.
I think it's too easy to over-complicate, rather than it being
inherently complex. In my head, the question is very simple:
given a choice of skins, which do I use in the current context?
Important subsidiary questions are:
how do I install and use a new skin?
how do I create a skin that others can easily install and use?
>
>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.
Um, I have a case where what I really want to do is use the same
skin for all pages on a specified trail, plus the trail page.
Instead, I use a group suffix and exclude pages like RecentChanges.
Then any pages in groups ending is the designated suffix get the
skin. This is ugly.
>...
>
>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.
Here are some thoughts.
1. what precisely is a skin?
It's a directory that contains at least one of the following
files
screen.tmpl
print.tmpl
skinx.tmpl
somefile.tmpl
skinx.css
skinx.php
where 'skinx' is the name of the directory
So I think one thing we need is an easy way to tell PmWiki to
load pub/skins/skinx/skinx.php, if it exists.
For example, to explore this I created an array
$Skins = array('publish','presentation');
foreach($Skins as $s) {
SDV($SkinEnabled[$s],1)
if ($SkinEnabled[$s] && file_exists("pub/skins/$s/$s.php"))
include_once("pub/skins/$s/$s.php");
}
This makes it fairly straightforward to add a new skin or disable
an existing one.
2. action-specific skin settings
I'm not sure that the $PrintSkinFmt is a good idea...
What if $PageSkinFmt gets set through the normal path of
default > config > group > page then once all local
customisations are complete, PmWiki looks to see if
$ActionSkin[$action] is set and if so, this overrides
the $PageSkinFmt setting.
By default, $ActionSkin['print'] = 'print';
For example, if the publish skin is enabled, then
pub/skins/publish/publish.php would contain the
following:
$ActionSkin['print'] = 'publish';
$ActionSkin['publish'] = 'publish';
And PmWiki would look for pub/skins/publish/publish.tmpl
This would let someone create $ActionSkin['edit'] for
example, if they felt moved to do so.
So now there is no longer the problem of publish
colliding with a different browse (screen) or
print skin.
3. do I need to know HTML and css?
This approach pretty much hides the complexity, I think.
The instructions for installing a new skin can become:
put the skinx/ directory into pub/skins/
add $Skins[] = 'skinx'; to local/config.php
This needs some refinement, but perhaps it will stimulate someone
to have a better idea.
Just my 5? worth...
--
JR
--
John Rankin
More information about the pmwiki-users
mailing list