[pmwiki-users] Feature request: Action lists in skins

Bronwyn Boltwood arndis at gmail.com
Tue Apr 19 12:15:21 CDT 2005


On 4/18/05, Joachim Durchholz <jo at durchholz.org> wrote:
> Bronwyn Boltwood wrote:
> > On 4/17/05, Joachim Durchholz <jo at durchholz.org> wrote:
> >
> >> Hmm... how about giving skin designers a way to say "action list #1
> >> goes *here*, action list #2 goes *here*", and letting skin
> >> designers recommend which kinds of actions should go to what action
> >> list? That would allow wiki admins to easily experiment with
> >> different action groupings, for example.
> >
> > You'd have to give a better example for me to judge properly, but you
> >  might be making it more complex and less flexible.
> 
> I hope not!

Consider: one of my changes is to have two action lists, and you
apparently think this is a good change.  But, maybe someone else's
needs will dictate a design with three lists, or some other non-two
number.  A system that says, "Thou shalt have two action lists"
doesn't permit such designs.  There's more than one way to do it,
right?

> > Creating a system that does the right thing for the admin, but is
> > still easy to modify, is a big job, and I'm not sure we'd come up
> > with anything vastly better than we already have.
> 
> I consider decoupling skins from action lists a vast improvement.
> Actually I think that skins are currently doing a lot of things that
> should be done elsewhere - the work itself is good, but I'd like to be
> able to mix-and-match good design ideas with good functionality ideas.
> Some skins look great but are too brittle for use, and some skins look
> drab but are great "under the hood".

Jo, just how well do you know HTML and CSS?  If not, then you probably
don't know just how delicate some of the inner workings are,
especially after compensating for browser bugs.  Pukka, for example,
is not nearly so flexible as I wanted it to be.
	- I wanted a series of "switch" sheets for the layout: move the
sidebar to the right, 30%/70% columns, 15em/30em columns, and so on. 
I couldn't do it because the code to accomplish these things
interlocked too much.  I ended up with a set of core layout
stylesheets.
	- I wanted to lay out the same HTML with both absolute positioning
and floats.  I couldn't get both methods to work properly from the
same code.  The required change was small -- just moving the footer
div -- but necessary.

When selecting a skin, pick something that's well-designed under the
hood, because the layout is the hard part; the beautification is the
easy part.  Read over the skin files and keep a reference like the
Complete CSS Guide (at westciv.com) at hand, and you can put together
some new decorations in an hour or so.

Why not try listing some of the good ideas that you'd like to carry
over from one skin to another?  Maybe we can do, case-by-case, what
would be too hard as a general system.

> I'd like to be able to judge a skin by its appearance. If that means
> "dumbing down" what a skin usually does, then so be it - all that great
> functionality that some skins (yours prominently, I might add *g*) offer
> could be done in other ways.

Thank you.  But, depending on how that extra functionality would be
abstracted out, then I might not be able to contribute.  I only know
HTML and CSS, not PHP or any other programming language.  So I'm not
sure what I think about this idea in general...
 
> That's highly sophisticated. Yet markup authors don't have much trouble
> with that construction: they are happy that writing a new markup doesn't
> interact with other markups or the wiki machinery in general, they
> simply write a regular expression describing the syntax for their new
> markup, and some code that generates HTML from it. The sophistication is
> hidden within the Markup() function, which takes just a few parameters
> and "does the right things" under the hood.
> 
> I'm trying to achieve something similar for action lists.

Well, here are some of the things I think you'd need to deal with, then:
- a complete list of all actions from everything
- a place for the admin to say which ones should be enabled, disabled,
or require authorization
- a *flexible* method for skin designers to insert actions into their
templates, so that they can choose how to group and order actions if
they so choose.
- a way for disabled actions to appropriately remove the markup
surrounding them from the output, so that it doesn't create mysterious
whitespace or other problems
- hooks for styling actions according to status (available,
unavailable, active, and so on)
 
> > But, if Pm could tell me how to add classes or ids to elements
> > through the wiki markup, then I think I'd prefer to store the action
> > lists and so on in wikipages, because most admins will understand how
> > to edit those,
> 
> Wiki admins are also able to write simple PHP code: assignments to
> configuration strings ($EnablePathInfo = 1), and calls to functions
> (XLPage("de");).

Agreed.  It's the rest of the system that I'm concerned about.
 
> The black art here is to get the subdivision between function and form
> right. To design it in a way that constrains neither skin writers nor
> wiki administrators (nor recipe writers who write actions, I might add).
> It's an interesting problem, which is why I'm still behind it ;-)
> (that's not very different from your interest in skin design, I think -
> we both are interested in seeing how far we can take an idea, and how
> near to our ideals we can take it).

Ah, you wish to play with it.  This is making more sense now...

If you do know PHP, I have another little project for you, should you
care to accept it. ;)

Bronwyn




More information about the pmwiki-users mailing list