Tags:
skin_consolidation1Add my vote for this tag create new tag
, view all tags
We have a lot of duplicated work going on, not least in the skin development. We need to practice ExplorationThenConsolidation.

I'd just retired FlexibleSkin as it was superceded but I still suspect SeeSkin and FreeSkin duplicate each others functionality. Duplication leads to waste and confusion - better to factor out what is different and just make the infrastructure more flexible.

ConsolidateFunctionalityFromSkins is an initiate to push the Plugin code (e.g. all the scripts created in bin/ ; all the plugins added by skins) into a common piece of SharedCode

-- MartinCleaver - 08 May 2004

Martin, I took the liberty of unretiring the FlexibleSkin. I rely on this skin, and I would rather pick up maintenance than it disappearing. You are right, if this is very similar to FreeSkin, then there would be no need to maintain FlexibleSkin. But unfortunately, there seems to be no documentation available for FreeSkin, and I don't have the time to install it somewhere and try to figure out whether it is or is not worth the change. However, I'd be keen to hear from somebody who already has figured this all out... smile

-- ThomasWeigert - 08 May 2004

Multiple skins are a good thing, I do not see an issue if some skins have similar functionality. I'd rather like to see the Plugin API enhanced with quality patches.

-- PeterThoeny - 08 May 2004

So if two skins are designed to do very similar things this is not a problem? Do we then maintain them both? I'd assert that you'd get better quality if you consolidate whereever possible.

-- MartinCleaver - 09 May 2004

It is often easier for people embarking on new projects to start with a clean page, especially if they are using the project to teach themselves how thing X works. Starting with someone else's stuff is *hard*[*]. Usually it's not quite going in the direction you are interested in and it's more work to change their stuff than to just start fresh. In the long run leveraging existing work is often more efficient in terms of total energy expenditure, but when you're just starting you usually don't know if the run will be long enough to make it worth it.

I'm all for consolidation by the way. I'd rather lightly customise an existing system than build my own. I know, I've tried. It's a lot of work. smile I'm just noting that a variety of skins is inevitable, not objecting to much needed pruning and merging.

-- MattWilkie - 11 May 2004

Well, I am utterly confused as to which CSS based skin I should be installing. FreeSkin is not complete, SeeSkin is no longer supported, there seems to be some sporadic (yet welcome) additions to the underlying template system and PatternSkin is as elusive as it ever was.

It'd be so nice if we could just ditch the TWikiTemplatingSystem and use something standard that another group cares to support. TemplateToolkit appears just as adequate but has a wide range of supporters and is known by many people.

-- MartinCleaver - 15 May 2004

I am afraid it is a lot of work. And I cannot devote all my time to developing pattern skin as I have a job and family competing. Indeed there is a lacune at the moment if you need something out of the box. But development on twiki is community based, and you are always welcome to add. PatternSkin for instance is in the plugins cvs.

-- ArthurClemens - 15 May 2004

And that is exactly my point. If we use a standard templating system then we can concentrate on the features central to twiki instead of losing time on the periphery. By all means we should have a nice skin such as pattern but there is only so much infrastructure we can support without a larger team. It would be much better if we could move pattern onto something like TemplateToolkit.

-- MartinCleaver - 15 May 2004

In the TemplateToolkit topic plus points and minus points are mentioned. Do you think we can overcome the minus points? If so, can you work on a proof of concept?

-- ArthurClemens - 16 May 2004

Perhaps VinodKulkarni would be the best person to do it - he contributed exactly that on 08 Jan 2003 to topic TemplateToolkit. I've mailed him.

-- MartinCleaver - 16 May 2004

In any case, we need to agree on a set of CssClassNames

-- MartinCleaver - 17 May 2004

(Thanks Martin for pulling me in!)

I think TT2 would really help twiki, but not because it is "templating" engine: In that mode, it allows you to have (site wide) header and trailer HTML. But I don't think you can have "pluggable" skins by default by using TT2 as primary templating engine. (But my knowledge could be old.)

What I had done was not actually templating, but to use template toolkit to access data structures defined within twiki environment (by core code as well as plugins). In the TTForms plugin (which is attached to TemplateToolkit), you define an area in a topic get it processed through template toolkit. The 'data structure' was the Poll Data which will be loaded into TT2 instance and available for use in the defined TT region within twiki topic.

And I now feel that this approach will actually help in twiki to achieve very strict modularization and control of the interfaces. Consider %TOPICLIST%: It is a string that gives list of topics as a string. (See TopicListAndWebListVariable.) To control the actual output format, you could use the options using typical macro syntax: %TOPICLIST{... options}%. But this is not a good idea: We instead let it be a (perl) array, and make it available to TT2. And use loops and other TT2 markup to produce whatever HTML or wiki markup you like for the list of topics. For this to work, TT2 should be core part of twiki.

Now, let us assume that we will do all twiki variables through TT2. (Including the macros available from current plugins.) The current TWiki plugins will also make output data available as TT2 variables. (And not produce HTML or wiki markup).

If we seriously produce a middle "data structure layer" this way, it will indeed help create a good and clean front ends. In fact, it will help us have XML layer from the data layer that TT2 will expose.

What all will be part of this data structure layer? Here are some thoughts:

  • Variables such as %TEXT% which are required for skins.
  • All the "Action" URLs such as ones for edit, print, view, preview etc.
  • All macros which invoke plugin use.
So it is quite a bit of work. But fairly incremental.

The process of making the data structures available to TT2 (and hence, visible to skins) should necessarily be plug-in based: Plugins for actions, plugins for macro names, etc. We should make sure we follow best practices from other wikis here.

-- VinodKulkarni - 18 May 2004

Some time ago we looked into the template toolkit. At that time we found that the gain was not worth the hit in performance (in a non mod_perl environment) and big code increase it would bring. It does not fit the KISS principle. Possibly better to improve the TWiki templating system evolutionary.

This discussion should be refactored out.

-- PeterThoeny - 20 May 2004

HTML::Template is quicker and simpler than TT2. And supported. And has extension for expression, if needed.

-- PeterMasiar - 20 May 2004

Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r17 - 2008-09-15 - TWikiJanitor
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.