AlternativeViewProposal
Functionality in skins, and recipe bundles
Ready for discussion. Thank you.
Problem:
There's a lot of potential complexity in pmwiki if you consider all recipes available, as well as presently unavailable, but potentially useful recipes.
What is presented here is not a suggestion for the pmwiki core, but rather suggestions for implementing functionality in the view-based skins, and for creating recipe bundles.
The premise is that everyone, and even the same person doing different tasks, will have different needs and all we can do is somehow provide functionality from which we all can pick and choose.
Concept:
The idea is the same as for the Cookbook:ModesConcept:
(However, this page describes a slightly different approach. It is not an incompatible one, but since I have a clear idea of how I'd like to go about it, I decided against editing the Cookbook:ModesConcept page. I hope we'll be able to integrate the two efforts, or at least support each other :)
Rather than having the skin designers or admins decide what the views should look like, let them simply make suggestions in the default layout they distribute, then admins and authors can change (augment, reduce, reorder and relocate) that to something they find more comfortable from task to task:
- allow admins and maybe advanced authors to make changes to the various views as painlessly as possible
- allow admins to choose what views/functionality they like
- use as much as possible the already available PmWiki functionality rather than creating new functions
Features list:
I would like to be able to have:
- display view (AFAICT most people agree with this one)
- various add-on functions for the author view (calendar, calculator, schedule bar, To-Do list...)
- blog view
- an export bar (with saved options for sets of page compilation and typesetting rules) for:
- plain text
- HTML
- different edit views and edit addons (section edit by itself won't allow me to move text among sections, so I'll have both section edit -when I get to it or when it becomes available- and page edit)
- view/toolbars for editing:
- schedules/To-Do lists
- tables
- drawings
- equations
- help (would include the EditQuickReference? that's currently ignored- at least by the people on my test wiki)
- for more suggestions for pmwiki recipes, see this or this
- an admin view (if not several), with specialized bars for easier navigation to admin pages and other nooks where the authors should not poke their noses (including the pages used to maintain/edit the toolbars and views)
- we already have print view (it could either unclutter the action= processing and be switched to view=, or view= values could be added to action=)
...plus several of the things already mentioned on Cookbook:ModesConcept
There are many other places where views would come in handy, and more may surface as we work through this, but you're right, it's not something the average author/admin would need. And Pm is right, it's a headache for basic admins to maintain templates for such a thing.
How would that display:
Functional Modules -Modules for short- (rendered either as table cells or divs) would be loaded around the page content: top, bottom, left, right, stacked when there are several of them needed on the same side (- which as a best practice should not happen; we want to make the interface simpler, not more complex, but it should still be available in case some author/admin likes to have lots of functionality constantly on).
Modules could also be fitted inside page content by using directives or other markup (as is currently the case)
The switch from view to view will be done with links or buttons in the interface (no URL-editing, thankyouverymuch :)
Application:
The recipe (adding a view variable to GET and SESSION or extending the processing of action=) is IMCO not very difficult. What's tough to do are the templates - layout, as always is a tough cookie. But PmWiki makes it better manageable with its quick testing cycle.
So there are two ways to do this:
- put lots of conditional HTML and pmwiki code in the templates
- The downside of this (as opposed to the page editing a la Site.EditForm) would be that the maintainer doesn't 'eat his own marmalade' (or whatever product :) and will be stuck editing templates for the slightest change.
- put lots of conditional includes in the templates
- This fixes the above problem, but has a bigger security risk (if someone declares themselves as a different Author, they can mess around with the other person's interface). However, this proposal concentrates on this option. Again two options:
- make the modules locations fixed and just switch them on/off as Gemini already does
- add some extra variables after the view= (or action=) one to set location and other module options
... or combinations thereof. It's really up to the skin designer.
Toolbars and other 'function list' modules can be maintained as list-based pages, as we have them for the PageTopMenu in Gemini... Then admins or even advanced authors would be able to customize their working environment. Say
[[Site.PageTopMenu-Radu]]
or better yet,
[[Profiles.Radu-PageTopMenu]]
Issues:
- What about all the stuff added by cookbook recipes?
- Once we talk about functional skins we are already integrating functionality (recipes) into the skins. So the view-based skins will integrate existing recipes. Yes, it could get a bit hairy with updating/upgrading recipes, but at least it's done in a central location (by the skin designer), and the skin users (basic admins) will have less of a headache trying to update several recipes and also fit them with their favorite skin.
- Will all skins have to be coded to accept all of it in order to have views at all?
- Naw! Skins which do not support views will continue as they are: eye candy.
However, I've been saying that skins are already a bit of both worlds, since several of them provide different feel as well as different looks. And admins (at least I :) choose skins for their functionality more than for their looks.
Anyway, looks can be changed in view-based skins by providing alternative css files.