[Pmwiki-users] Re: Skins - a somewhat radical proposal

John Rankin john.rankin
Sun Nov 14 15:05:52 CST 2004


Apart from a couple of small but important differences, Patrick's
message is pretty much the reply I was going to make to his
message of a couple of days ago.

So, mostly, my response is 'go for it'.

Below are 2 sorts of comments: 'for avoidance of doubt, I assume'
comments (FAD) and 'in my opinion, it would be better to' comments
(IMO)

On Saturday, 13 November 2004 10:59 AM, Patrick R. Michaud <pmichaud at pobox.com> wrote:

>First, I think I've finally convinced myself that the setting of some 
>parameters such as $LinkPageExistsFmt, $LinkPageCreateFmt, $UrlLinkTextFmt, 
>etc., is really to be associated with a -skin- and not with the -action- 
>being performed.  Thus those parameters need to be specified using 
>something that exists in a skin's directory, and the logical way to do 
>such settings is with a .php scripts.  So, skins now get their own
>.php scripts.

FAD an administrator can still set these globally in config.php
but a particular skin may override such settings. And the print skin
does this already.

And they move out of pmwiki.php and into pub/skins/pmwiki/skin.php
>
>Second, we don't want force (novice) skin designers to have to write 
>.php scripts when they aren't needed, so any .php scripts need to be an
>optional component of the skin.

Yes.
>
>Third, basic skin selection should be as simple as saying $Skin='xyzskin'
>in a configuration file, which tells PmWiki to use the skin stored at 
>pub/skins/xyzskin, including the loading of the skin's optional .php script.
>More advanced features should be possible (e.g., being able to use an array
>to select the first available of '$FullName', '$Group', 'xyzskin', and 
>'pmwiki' skins), but the basic setting is what the majority of people
>will use and be exposed to.

IMO one tidy way to do this is to have an array of $Skins. PmWiki does
something like:

    foreach ($Skins as $s) {
        $Skin = $s;
        if (file_exists("pub/skins/$s/skin.php")) 
            include_once("pub/skins/$s/skin.php");
        elseif (file_exists("pub/skins/$s/$s.php"))
            include_once("pub/skins/$s/$s.php");
    }

For example, $Skins = array('xyzskin','$Group'); and by default
$Skins = array('pmwiki'); but such a scheme could be implemented
in several ways.

FAD an administrator could still just write $Skin = 'cocoa'; in
config.php.

>
>And finally, I now agree with John's idea to allow actions to override the
>default skin choice, something like
>$ActionSkin['print']='xyzprint'.

FAD scripts/print.php moves into pub/skins/print/

Yes. I am now using this with publish.php and it makes life a lot simpler.
Before the above foreach, something like:

    if ($ActionSkin['$action']!='') $Skins[] = $ActionSkin['$action'];
>
>Okay, now that I've reached those conclusions, all that is left is to
>figure out how PmWiki gets from a skin name ('xyzskin') to the individual
>template, php, and css files associated with that skin.
>
>One option would be to require that the names of the files match the
>name of the skin, as in 'xyzskin.php', 'xyzskin.tmpl', and 'xyzskin.css'.
>But I'm going to reject that option outright, because it means that
>copying or renaming a skin into a new directory requires making all of
>the filenames match.  
>
>The next logical option is to require the skin and template files to always
>have the same name, i.e., "skin.php" and "skin.tmpl", or "screen.php" and
>"screen.tmpl", etc.  But for some reason I'm inclined to find that a 
>little too restrictive as well.
>
>So--here's the somewhat radical part--what if we just go to the other 
>extreme, and let the php and template files be named *anything* as long 
>as they end in .php or .tmpl.  Thus, with $Skin='xyzskin', PmWiki would 
>just use whatever .php and/or .tmpl files it happens to find in 
>pub/skins/xyzskin.  
>
>Of course, the question then becomes, what if there's more than one?
>For .php files, it could just load all that it finds, but this is
>probably a bit dangerous.  Perhaps the better approach is to keep a
>restriction that a skin's .php file must be named something like 
>"skin.php" or "settings.php" in order to be automatically used.

IMO it should look first for skin.php and then $Skin.php but
load only the first it finds. Look for skin.php first to simplify
the instructions for new administrators:

- copy the 'xyzskin' directory to a new directory, say 'newskin'

- add $Skin = 'newskin'; to config.php

- if newskin/ contains a file called skin.php, you are done setup
  and can go ahead and edit the .tmpl and .css files in newskin/

- if it contains a file called xyzskin.php, rename it to newskin.php
>
>For selecting from several template files in a skin's directory, I'd
>say to first use any template file chosen within skin.php, else 
>use the template file with the same name as $Skin if it exists, else 
>just use the first .tmpl file we happen to find in the skin's directory, 
>whatever it happens to be named.

IMO the order should be a template file set in skin.php (or $Skin.php
if there is no skin.php), skin.tmpl, then $Skin.tmpl, then a file with
a .tmpl extension -- so the order and naming is the same as for the 
.php files (if there is no setting in the .php file).
>
>Alternately, if we get to the end and find more than one .tmpl file
>to choose from, we could issue an error message telling the administrator
>to rename one or eliminate the extraneous ones.

IMO this is unnecessarily restrictive. For example, it's often
useful to have skin.tmpl and testskin.tmpl in the same directory.
One can swap between them just by commenting the line in skin.php
that points to testskin.tmpl. I think there should only be an error
in the following case:
- a .php file doesn't set a template

- neither skin.tmpl not $Skin.tmpl exists

- there are more than 2 .tmpl files in the $Skin/ directory

A case could be made that the .php files work the same way --
look for skin.php then $Skin.php then anyname.php

It would be easier to explain if the rule was the same for
.php and .tmpl files, with the addition that a .php file can
override the .tmpl rule. For me, skin then $Skin is enough,
as the .php can invoke any.tmpl if needed.
>
...


-- 
JR
--
John Rankin





More information about the pmwiki-users mailing list