[Pmwiki-users] Skins

Steven Leite steven_leite
Sat Feb 21 17:15:30 CST 2004


This is a reply to Pm's invitation for comments about a new template layout.

> I'd really like to invite less confusion, not more.  And as you
> correctly point out, increasing the number of locations to place things
> increases confusion (which is why I've argued for fewer predefined
> directories, not more).

I agree, it seems like as PmWiki's popularity increases, so do the number of
users who complain it's confusing to configure.  I think emphasis is on
*configuration* and *customization* here.

I think each topic needs to be considered seperately.  All I will say about
*configuration* is, I respect that there's a good reason this is not in a
public directory.  I think the config.php file should reside here:

/pmwiki/config/config.php

Addressing the *customization* issue, and ignoring all security and server
issues, because as a user, I don't know about security and server issues,
and I don't care :-)

I think a directory structure like this would be better for templates (and
additional scripts).

/pmwiki/custom/scripts
/pmwiki/custom/templates

Focusing on the templates directory ...

If we take three steps back, and ask the typical user what they expect in a
template you may get some good ideas.  I think it's important not to put any
restrictions on this type of query however, as I feel they are
counter-productive to the generation of further discussion and creative-idea
generation.

Example of idea restrictions:

> I haven't figured out a good way in a template file to
> indicate headers, footers, titles, etc. in order to be able to honor
> the [[noheader]], [[nofooter]], [[notitle]], etc. directives and to be
> able to properly embed variables such as $Title, $Group, $PageUrl, etc.
> please).  Also be sure to include some way of being able to distinguish
> the header, title, sidebars, and footer in the template, so that they
> can be disabled on output.

Restrictions like this should be the programmer's responsibility, not the
user's :-)  Bearing all that in mind, here's what I (an in-experienced
programmer) might expect:

- - - - - - - - - -
MY DREAM TEMPLATE (under construction)
- - - - - - - - - -
I might expect to write my template in [[insert favorite wysiwyg html editor
here]].

I might expect that I should be able to add special output components
such as {{$Title}} or {{$LastModified}} in my template and have them parsed
by PmWiki and replaced with appropriate plain text content.

At a rudimentary level, I might expect to insert {{$WikiContent}} and have
it replaced by the wiki page (plain vanilla version).  I might also expect
to use existing layout scheme.  Perhaps both can co-exist.

I might expect that, in order to identify different parts of the template
(eg.  sidebars, headers, footers, etc), so the [[noheader]], [[nofooter]]
and [[notitle]] directives are honoured,  I might use some form of existing
html comments, for example:

<!--PmWikiFooterStart-->
 ... some html ...
<!--PmWikiFooterEnd-->

<!--PmWikiTitleStart-->
  ... some html describing title
<!--PmWikiTitleEnd-->

I might expect these comments to be optional (in which case, they cannot be
turned off) because some html admins like me might be lazy at first and not
want to spend the extra time to make sure the commented idenifiers are
present, or that they conform precisely to WikiStandards.

- - - - - END OF MY DREAM TEMPLATE - - - - -

> Is there *anyone* out there who thinks the new layout scheme is a
> good way to go?  Based on the amount of negative feedback coming
> across the listserv I'm tempted to just scrap the whole thing

I wouldn't call it negative feedback.  I'd call it an opportunity to
improve.  I wouldn't scrap the current method.  It's a master-piece in it's
own way.  But I definately think exploring new layout possibilities will be
a step in the right direction, especially in light of the following comment:

> It is *extremely important* to the overall success of PmWiki that the
> layouts be easy to customize, and the comments you all are sending are
> very important to me, because what I'm hearing is that this is not
> currently the case.

So yes, if some well thought out discussion ensues, it would be a very good
thing.

It may be worth while if some experienced programmers out there could
highlight a few potential problems (advantages and disadvantages) of
existing patterns in the usage of templates.  I think it's important to look
at what types of layout customizations are possible, different approaches,
etc.

Lastly, I just want to encourage everyone (especially you programmers!) to:

Think outside of the box.

That means, forget about all existing markups, and syntax restrictions and
brainstorm!  Worry about the details later.

-----

SOME QUICK COMMENTS ABOUT POTENTIAL REASONS FOR DIFFICULTIES

>So, help me out here, folks.  I'm thinking the
>difficulties must stem from one or more of:

>  - limitations of CSS as a layout language

Not really.  I've never consider (and still don't) CSS to be a layout
languange.  I use CSS for doing cross-website (global) changes to
font-style, sizes and colors.  I don't use it for anything else.  (Since
using PmWiki, I have learned CSS can be used for much more, but that's
beside the point)

>  - lack of familiarity with CSS-based layouts

Yeah, I guess that might be my problem, but I don't belive CSS-based layouts
are that commonly used yet (by typical html coders), nor do I feel the need
to learn how when I'm perfectly happy with my table layouts.  CSS Layouts
should be optional. (I say css layouts, not styles.  css Styles are a good
thing.)

>  - separation of content generation ($...Fmt variables in .php scripts)

I don't even understand what that means.  I especially don't understand the
$Fmt variables.  I think the $Fmt part confuses me.  Maybe if they were
named more simply.  Are these arrays?  Maybe that's what's confusing me.

>    from external layout (.css) files

Nah, not really a problem.  Anybody that uses css files understands the
difference between inline css and external css.  Location is just a minor
detail.

>  - difficulty in switching from the old 0.5 layout structure to the
>    0.6 one

Nope.  But I prefer simple plain vanilla layout which I can later customize
rather than the new fancy one.  But that's just me.  Many people will prefer
the new one instead.

>  - too many files and directories involved

Not really.  I think less is better, but I also think they should exist
where necessary, I feel the number of directories currently in place is
(arguably) justifiable.

>  - lack of examples

More (simple) examples would be helpful.  I guess more complex ones would be
good too, but I think only programmers would benefit from those ones.  I
really like the config examples in example-config.php.  I also like how
config.php can be used for simple configuration options or entire php code,
and functions in there, although that's a bit of a turn off for people that
don't know php.  Too bad there wasn't an easier way to set options without
having to enter all that fancy php code.  That's the price for complexity
and robustness I guess (If it comes down to making a choice, I'll rather
keep the complexity and robustness rather than lose the flexibility that the
config.php file currently offers).

>  - lack of documentation

Nah .. there's enough documentation.  It's improving day by day too.  Plus,
anybody who's taken the time to ask a question in the mailing list surely
has not regretted it.  Answer's usually come in hours rather than days.

>  - PmWiki just trying to provide too much in a layout structure

Perhaps.  Maybe with more discussion, this can be better assertained.  I
think not, but it depends on the type of layout that the Admin is trying to
accomplish.

Sorry for the long post, but this is a big topic.

I hope everybody will contribute and help in this discussion.

--S








More information about the pmwiki-users mailing list