On Mon, Oct 5, 2009 at 4:49 AM, Hans <[email protected]> wrote:
>
> I am trying to create a user friendly release of my Triad skin some
> may know from Pmwiki.
>
> But I am struggling with integration issues, particular with the site
> page's new format, and with action=skin.
> Both seem to be built entirely with the default skin in mind.
That is true. Though it shouldn't be too hard to rename the zones on a
different skin to match more closely. Still the action.skin doesn't
really deal with zones, just some settings and text. And a left-right
menu option. Which is pretty cool. And the action.zones page is
generated dynamically.
I'm just now wondering if we shouldn't rewrite that to return a simple
list of csv names of the existing zones, and pipe it through the list
function to generate the display. That would allow more flexibility in
using those zones in other situations--like generating search output.
And again, simplify the code...
> The site page shows a fixed set of zone pages, which may well be
> totally irrelevant to the skin one uses.
> so that section of the page is useless and misleading.
Yes, that is true. If we go with my suggestion above, we could do
something like:
[(search type={skin},{(zones)})]
The second being a function returning all the zones. The first a
system var. This would return all the
side.triad, and even side pages in the site--directly related to that
specific skin.
We might also want to consider re-titling it skin pages or
something... I even wonder if it wouldn't be better to have a skin
page, or add this search to the action.skin...
> The other parts are listings and do show the relevant skin pages, but
> the listing shows too much information, too many links IMO. The
> previous format showing only the page links without parent links in
> front was much easier to read.
Possibly but the idea was to have virtually all the pages either
listed on site or site.pages. And using the built in anchors, you can
get where you want pretty fast. Faster than having to take an extra
click or two to load a secondary page. For new users, it also gives
them a bit of an overview of where things are. For more experienced
users, like myself, I never use this page. I almost always go straight
to the page I want by name. So I have no big burden one way or the
other, except to try and remember the new users who are still
scrambling around.
> The zone issue is a difficult one, and I remember taking about this
> before, as zones use top level page names like 'top', 'header',
> 'foot', 'bottom', 'side'.
>
> The advice for skin publication was to use subpages for the skin, like
> 'header.myskin', 'top.myskin',...
> Any extra zones can be added the same way.
> But none of this would show on the default 'site' page, not much help
> for an admin who just installed a new skin.
I'm perfectly willing to make the changes above to the zones function
so we can do what is suggested above. That way you get just the pages
used in the current skin.
> One radical solution could be to demote all zone pages and put them as
> subpages to a top level 'zones' page (group).
> Then they can be automatically listed like 'site', 'code' etc pages on 'site'.
> This would need 'skin' pages to be rewritten to use the new zones like
> [[zones.top]], [[zones.header]]
This may have been a better design decision. And very easy to
implement. And we could still do it. However 1) it would break most
existing sites, unless we allowed both somehow. And 2) I'm not sure it
is quite as intuitive to a new user. Though the learning curve would
not be that hard, esp with the zones action available to them. This is
the reason however this suggestion has been rejected in the past.
That, and using type= seemed just as effective an alternative.
> The other issue is with action=skin, which leads to a form page to
> conveniently alter some of the default skin settings.
> But this targets 'code.snippets' entirely, and misses a
> 'code.snippets.myskin' page.
> Oooops, i just realise that when i create a page 'action.skin.myskin'
> then action=skin will go to that rather than 'action.skin'.
> So I can bundle a custom page for action=skin. Good.
Yes, that would probably be the best way. I wish every skin had it's
own easy interface page like this customized to it's needs.
> Am i right in thinking that any variable set in 'code.snippets' is
> available, unless it is set in 'code.snippets.myskin', so the latter
> value will be taken, if it exists, otherwise the former?
You should verify, but my understanding is correct. And this is so
only if a data var or system var is not set on the specific page.
Which could make for interesting possibilities. Such as page specific
titles and keywords in metatags Though these are not hierarchical, we
might be able to figure out some way to do this in snippets.
title:blog: My Blog...
title:forum: My Forum...
You can do this already via php:
if ($pageArray[1] == 'blog') $BOLTvar['$color'] = 'red';
if ($pageArray[1] == 'forum') $BOLTvar['$color'] = 'blue';
Cheers,
Dan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/boltwire?hl=en
-~----------~----~----~----~------~----~------~--~---
