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

[Joachim Durchholz]

Bronwyn Boltwood wrote:

> 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?

I wrote "action list #1 and action list #2", but what I really meant was 
"action list #1 and action list #2 and action list #3 and so on".

That's the kind of flexibility that we programmer types always imply. 
When programming, there is usually no real difference between providing 
for two of a kind or for an arbitrary number of them, so we tend to do 
the arbitrary number thing even if it's not needed.

>>>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?

Good enough :-)

Familiar enough to curse the combination of the unforgivingness of CSS 
vs. browser bugs. It's a hellish combination...

 > 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.

Right.

 >  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...

I can understand that.

Note that I don't want skin authors to require an extended skill set. 
Also, placement and looks of action lists should remain with skin authors.

What should be moved into configuration (IMHO) is the raw functionality. 
I.e. the decision what links should be visible, the targets that they go 
to, whether the targets will open in new windows or not, and maybe other 
settings (there may be more though I don't recall any details right now).

The nice thing about moving this to PHP is that other PHP extensions get 
traction on the action list. If there's a standardised way of writing 
down action lists, the recipes that do user logins and similar things 
can do things like greying out irrelevant and hiding unavailable links.

> Well, here are some of the things I think you'd need to deal with, then:
> - a complete list of all actions from everything

Recipes that set up actions would implicitly create that list.

> - a place for the admin to say which ones should be enabled, disabled,
> or require authorization

There are two stages here:
1) Deciding the status of each link (available, unavailable, hidden - 
not sure if additional statuses make sense).
2) Deciding how each status should be displayed.

(1) is the domain of the authorisation mechanism or other recipe that 
influences the action lists (say, a recipe that hides the current 
action). So the actions' statuses are configured through these recipes.

(2) is the domain of the skin. Unless the skin doesn't provide for extra 
hooks in configuration, there is nothing admin-configurable here (unless 
the admin also wears his personal skin writer hat).

I.e. in general the admin has no need to configure anything specific to 
actions, it's done in the context of other things that he installs and 
configures (recipes, skins).

> - 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)

My current thinking is to have markup for .tmpl files that allows the 
following:

1) Mark a section as "this is an action list". The contents is processed 
normally, except for the place marked as "action entries go here". The 
entire section is suppressed if PmWiki finds that this action list is empty.

2) Describe the looks of each kind of action (available, unavailable, 
...). Uses a describe-by-example technique, i.e. skin designers write 
markup for some dummy action.

3) Describe what should go between two actions of the same list. (Comma, 
&middot;, <br>, or whatever.) In most cases, this would be just a short 
string of HTML, or nothing at all.

Generally, if an action is "hidden", it's not included in the action 
list right from the beginning, so no spurious blanks can be generated.

>>> 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.

That's all "under the hood".

>> 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...

Well, with an intention of making something that's worth the effort 
afterwards. This is a bit too large to do it for fun and for fun only.

> If you do know PHP,

I do. Not at the sophistication level of Pm, but I manage - and I've
been picking up Pm's idioms pretty quickly (I like quite a lot in his
programming style *g* - and it's at the core of what makes PmWiki so
flexible).

> I have another little project for you, should you care to accept it.
> ;)

Um... I've got two projects sitting at the end of my list right now 
(decoupling action lists and skins is already one of them).
OTOH if it's interesting I will consider it anyway. Money would help (if 
available - it's definitely not a requirement).

Regards,
Jo