Tags:
skin1Remove my vote on this tag create new tag
, view all tags
Refactored from TemplateToolkit

Continuing to build and support TWiki's templating system still makes strategic sense.
Do you agree or disagree? Please select one of the radio buttons below and click the button.
I 1 - Strongly disagree   2 - Disagree   3 - am Neutral   4 - Agree   5 - Strongly Agree  


1 FrancoBagnoli 24 Dec 2005  
5 ThomasWeigert 20 Mar 2005  
5 CarlinhosCecconi 06 Mar 2005  
4 SergeStinckwich 13 Oct 2004
5 AntonAylward 13 Oct 2004
3 CrawfordCurrie 12 Oct 2004
5 PeterThoeny 11 Oct 2004
2 VinodKulkarni 11 Oct 2004
3 DavidMonaghan 09 Oct 2004
1 MartinCleaver 02 Oct 2004

We do not need to consider an external templating system
Do you agree or disagree? Please select one of the radio buttons below and click the button.
I 1 - Strongly disagree   2 - Disagree   3 - am Neutral   4 - Agree   5 - Strongly Agree  


1 MeredithLesly 08 Apr 2006  
1 FrancoBagnoli 24 Dec 2005   5 AntonAylward 13 Oct 2004
1 CrawfordCurrie 12 Oct 2004
2 PeterThoeny 11 Oct 2004
2 VinodKulkarni 11 Oct 2004
2 DavidMonaghan 09 Oct 2004
1 MartinCleaver 02 Oct 2004


What about using HTML::Template system? It's simple, lean (100KB), and if needed, has expression sub-module.

HTML::Template by Sam Tregar: home -- article a2 -- tutorial t2 -- CPAN doc -- H::T with expressions

Was is considered?

-- PeterMasiar - 03 Jan 2003

I am attaching a sample plugin that uses Template toolkit:

What does it do? As of now, it reads a table (in a particular format) from any topic, and makes the rows available from within Template environment. You then have all the power of template toolkit to do things like looping through the array etc.

I am trying to provide a mechanism to allow structured data capabilities from within the twiki environment. The key requirements are to allow use of lists, trees and tables as data structures, and auto-generate reports etc. from such structures. The mechanism deviates from usual TWiki route of spreading forms information in too many topics.

  • Define the data (in some format; say XML) in a single topic
  • Let standard plugins support editing that data through forms, and other means.
  • And a good handle on reporting is a must.
  • Database integration is must. Either real-time, or synchronize-at-night etc.

We have currently deployed a solution that uses PollPlugin that allows form input for the users. It creates a simple table (and as such, can't be used for serious deployment). But as a special case, we carefully used the plugin for form based data collection. No. of users was large (200 to 300). Speed was limitation; twiki could only serve about 3-5 requests per sec. We have used mod_perl, but still trying to find out why this should be so slow.

As enhancement to PollPlugin (see my comments in PollPluginDev), I recently added reporting capabilities which uses homegrown variable syntax within a format string. Using the same, it was possible to support form-fill with most recent values from user. I also provided functions such as sum() and counts() that allow you to do spreads of data, sums and so on.

It was soon clear that we shouldn't be inventing the wheel again. So I tried to explore Template Toolkit. The result is a plugin with similar capabilities. But we need to carefully see whether it is a CPU and memory intensive, and creates more problems than it solves. Good points:

  • Has good press, known to be popular.
  • Has a lot of flexibility
  • Has series of plugins and they can directly enhance TWiki's value.
  • Possibly, security and related issues are already taken care of.

So, we should give a very serious thought to this. The plugin that I have attached helps to explore the capabilities.

-- VinodKulkarni - 08 Jan 2003

There's a good comparison of Perl templating systems available, covering TemplateToolkit, CPAN:Apache::ASP, CPAN:HTML::Template and others. Some have additional features such as caching, which would greatly help TWiki performance for viewing pages (as shown by CacheAddOn). This Perlmonks node also has some good discussion and links to useful articles.

Quite a few of these systems seem to work best with ModPerl - since this is not always available, even on intranet servers, it would be useful to have a templating system that works well even on CGI based setups, which means it should be lightweight when loading/compiling, and not depend on ModPerl for caching.

-- RichardDonkin - 07 Jun 2003

TT2 can be compiled, see from TT performance:

  • The Template Toolkit uses Perl's superior regular expression facility to tokenise the text and a fast LALR(1) [ 19 ] parser based on the Parse::Yapp module [ 20 ] to compile templates into an intermediate form. The compiled templates are optimised for fast processing and are cached for subsequent use.
  • This improves the run-time effeciency to the point of competing with hand-written content generation sub-routines, but with all the inherent flexibility that the Template Toolkit provides. This also permits "compiled" templates to be written to disk in the latter form for subsequent cache persistance and significantly faster re-parsing. The current stable release version, 1.04, uses a slightly inferior (for these purposes) approach based on evaluating a sequence of opcodes. This is approximately 30-40% slower than the above technique but still represents a relatively fast and efficient solution. Version 2.00 should be available by the time of the Perl Conference.

But of course we are hackers and prefer to reinvent the wheel, I mean templating system. Or do we?

-- PeterMasiar - 11 Jun 2003

The article Richard linked to has a small section on CGI performance (which is the default twiki mode). It indicates that the Template Toolkit is not a good fit without mod_perl, "Your best performance bet with CGI is to use one of the simpler tools, like CGI::FastTemplate or Text::Template."

-- MattWilkie - 11 Jun 2003

This is not just a case of re-inventing the wheel. There are good reasons listed above for not going for the template toolkit, much of TWiki is a kind of templating system itself.

-- JohnTalintyre - 11 Jun 2003

I just recently fell in love with TemplateToolkit and TWiki, so naturally I want to have the benefits of both in one app.

Anyone else still watching this?

-- DavidMonaghan - 12 Sep 2004

On one hand, toolkits such as TemplateToolkit, ClearSilverTemplateLanguage etc. are focused on accessing data from standard data sources such as databases (and wrap some static content such as headers and footers), and there is a lot of flexibility in how this information can be cast into very flexible views.

For example, $mytopic.table[3][2].name can be made to refer to third table present in "MyTopic" and reference name column of 2nd row. And you require for loops, if-then-else statements and other standard template language features.

Twiki as templating mechanism excels in user-facing functions such as online-edits, attachments, tables, a good framework for access control and so on. It is a well-integrated framework, and not just a template library. But its usage is increasingly towards (1) Application platform and (2) Portal and Publishing framework. For example, it is much more simpler to define a news item as special topics in each web (different owners) and pool then on to the main organization page (see TWikiNewsPortal). The way it is done today is to use SEARCH and INCLUDE, but it is only grep-based, and not solid i.e. anyone can disturb it with some meta characters such as "|" .

The approach that I would like to suggest is:

  • Identify a special markup within a topic as data sources. Use whatever format, but convert them into internal program structures. They can also use plugins to talk to databases and define the data.
  • Identify special markups as views. (Datasources would also have default views, unless we disable them explicitly)
  • And some more special markup as edit controls for named data-source markups.

For example, in EDITTABLE, the data markup would be the the table with "|" bars. Its default view is what we see in output today. A new view might allow us to specify for loop and use $table.column approach to reference the elements. (INCLUDE and SEARCH on data sources would have to behave differently.) Most variables in TWikiVariables would be available in this standardized data model.

PageType has seeds of this idea - even though it only identifies HTML type. FormQueryPlugin is also taking this approach. But I feel that we should first standardize the markup and key concepts.

In any case, evolution is best approach that open source softwares should take, so we shouldn't deviate from our existing approach. But it is nice if any new work gets aligned with an approach such as this.

-- VinodKulkarni - 13 Sep 2004

To continue to support a templating system is to fail to take advantage of the efforts of others.

As Richard pointed out "Some have additional features such as caching, which would greatly help TWiki performance for viewing pages". This aligns with Dakar.

-- MartinCleaver - 02 Oct 2004

I'm not going to vote on this topic, because it's like voting for world peace. My question is, who is going to put their fingers where their tongue is and actually code up the required changes to TWiki to use an alternate templating system? If you do that, then I will vote on whether that code should be part of the mainstream or not. Right now, this is just vapourware, as far as TWiki is concerned.

-- CrawfordCurrie - 09 Oct 2004

I am glad you are exercising your free will, Crawford. I continue to invite others to do the same.

At present consideration of TT does not stand as a legitimate experiment, lessening the chance of further experimentations. Vinod has had code attached to this topic for about 18 months, yet outright rejection of consideration of the TT as an idea shuts off the community from experimenting with it.

When I spoke with the CGI::Wiki people they said that TT is fast during execution but is slow to initialise. This makes it good for PersistedInterpreter environments but not so for plain CGI. This is important, a result gleamed from experimentation. What impact this would have for TWiki will depend on the external factors such as of how readily available ModPerl and SpeedyCGI become in hosted environments.

-- MartinCleaver - 09 Oct 2004

Okay, okay, sorry, it's been a long week. I don't mean to pooh-pooh your poll, it's a really good idea to continue to encourage people to think about these things and get involved. I'm just getting a bit swamped by the mass of good ideas resting in state in twiki.org that no-one (except JotSpot, that is) has picked up and run with. Too much to code, too little time....

-- CrawfordCurrie - 09 Oct 2004

And too few people to do it....

-- RafaelAlvarez - 11 Oct 2004

I am not going to vote on this because there are two questions with two different answers:

  • Continuing to build and support TWiki's templating system still makes strategic sense --> strongly agree
  • We do not need to consider an external templating system --> disagree, there might be a light weight templating system that complements the functionality of TWiki.

-- PeterThoeny - 12 Oct 2004

I am glad the restatement into questions has elicited your thoughts. I appreciate that you feel they are separate questions so I've accordingly split the poll, carried forward existing answers and added responses. I hope everyone finds this fair.

-- MartinCleaver - 12 Oct 2004

There are a number of quite seaprate questions, more than PeterT mentions in his 12th October posting. Lets not forget that TT and TT2 are big. Does what we get justify the size? Not just "is it good stuff" but how does that compare with what we've got?

PeterMeisar quite rightly mentioned HTML:Template. But again, what does it offer over what we have?

Let look at the existing TWiki Templating system and think in terms of pro and con.

PRO CON
It works Its difficult to read
It works in terms of macros, so you can specify a baseline "look and feel" easily Macros are hard to read and to visualise what the page would look like
Adding a new type of view is - almost - unnecessary and when it is its easy A new view means new HTML page and getting all the look and feel to match
Starting a new skin is easy. Just do a "skinname.twiki.tmpl" Starting a new skin means doing over all your HTML files and making them have all the same look and feel
It is different to existing systems We can't just take templates from elsewhere, attracting people requires them to be convinced that they have to learn a new system

You disagree - then argue. I've been through this before. I came to almost the same conclusion as PeterThoeny's design that we see in TWiki. The 'almost' was that each skin still had the "macros" but had other meta information since the render engine was similar to instiki in that it could render different mark-up languages, direct HTML, or PDF. The skin had to tell the render engine what it could handle. (and of course the topic metadata had to tell the render engine what it was.)

We should whatever is BestForTheJob

-- AntonAylward - 13 Oct 2004 (some tidying by MartinCleaver)

I think Anton hits the nail on the head. No, I don't think the size of a 3rd party TT is justified. I made the same points on IRC last night. However reading about TT and others (and talking to ColasNahaboo about it) made me realise we are missing a trick by not having a strategy for compiling templates to code.

-- CrawfordCurrie - 13 Oct 2004

Added a table entry about not being able to steal use design templates from elsewhere.

-- MartinCleaver - 13 Oct 2004

Let us look more closely at features (related to template engines) and whether we can comment on it. The focus of wiki usage can be one of:

  • Enterprise Collaboration: Users create/edit content, caching, performance, templating, access controls (primarily unstructured data)
  • Ad-Hoc processes and Applications: Be able to create and manage workflows, and data management related to this (such as querying tables) - primarily structured data, and things like getting form-fills done from users, aggregation and good reporting mechanism. Should compete with Excel in long run.
  • Personal wiki: (Probably Not that relevant)

Usage Focus Feature TWiki template TT ClearSilver
Applications Create and manage structured data (without using external databases) Tables Good (Independent namespace for variables) Better (Independent namespace)
Applications Views on data model: Clean syntax (loops, conditionals, referencing hierarchical data) No uniform model Uniform Uniform - and very clean
Applications Views: Caching Available Not available Not available
Applications Fine grain access control (e.g. show only specific rows in table) No clean syntax (require plugins) Available - Use conditionals Use conditionals
Applications Conditional "next topic" navigation (via actions in forms) - required for workflow OK (needs to improve) ? Not Applicable (?)
Collaboration Template creation and instantiation Good Not a clean model Not available
Collaboration/Applications Page types (multiple rendering options) Not a core capability ? Not available

My requests stem from focus on ad-hoc applications space is creating need for integrating an external templating engine. They complement, rather than replace, the TWiki Templating engine.

>Added a table entry about not being able to steal use design templates from elsewhere.

>ahem< Please see CopyCatSkin which was written up in a single afternoon as a proof of concept (only does view mode). CCS was used as a starting point by http://nats-www.informatik.uni-hamburg.de/

(not that I necessarily disagree with the premise of this topic. I've spent a lot of time inside the twiki template system and I don't like it much. But then I've not used a template system I do like outside of Dreamweaver. I just needed to counter the assertion made.)

-- MattWilkie - 14 Oct 2004

As you know the TWiki templating system scores because it is simple. There are really only two constructs within it. Lapsing into cpp for a bit, we have:

#define X
#include X.Z
And for most of what TWiki does, that's enough. At one point or another I have considered all of the following:
What Why
conditionals Moronic browser support in clever skins i.e. only use CSS if the browser can support it.
parameters to templates readability; support cleaner template definition
parameters to includes Consolidate template include, normal include and MacrosPlugin into one set of code
loops To support attachment tables. At the moment this has to be done in code. Lack of loops also means forms struggle to render arbitrary length tables
compileable templates performance; templates compiled to perl code can be executed in double-quick time
All of these would be "nice" for other reasons as well as those I list above. Each time I have considered one of these I've gone back and looked at the available template toolkits, which would be the obvious route to implementing any or all of them.

Each time I have backed down, for the following reasons:

  1. Individually, each of these features is straightforward to implement in the TWiki templates system
  2. Re-engineering (and re-documenting) the existing templates strikes me as a much larger job than coding these features
  3. IMHO successful incorporation of a 3rd party template engine would involve re-architecting the core.
  4. In some ways I actually appreciate the simplicity of the TWiki templating system. It's very stupidity means things (templates) have to be kept simple, which makes them more accessible for non-techies.

What I am saying is that I don't see the killer application for a 3rd party templating system. It's a huge leap to take, I'm not sure it's in the right direction, and even when you land you find that Tiki got there first (with PHP, which for some reason no-one has mentioned).

BTW I haven't implemented any of the list above because of the TWiki development model, not because I don't think they are a good idea. But they are all on the list.

-- CrawfordCurrie - 14 Oct 2004

If you implement these features, you will have lightweight templating framework like HTML::Template. Of course it will be better - this wheel is invented (and maintained and bugs fixed) here.

-- PeterMasiar - 14 Oct 2004

The last entry on the con list should be two I think.

TWiki needs to be tweak-able is my main thought process. I just wan't to be able to take any piece of the site / application and edit it. The style, the layout, and the application code itself. This may be going to far, but that is what I am looking for. Now does TWiki need an external templating system to accomplish this goal? Not entirely. I think though that if this were ones goal, you would not want to have your template format be something which was not easily editable using a text edit box (though I think the option to use an external editor is a must as well.)

-- DavidMonaghan - 05 Nov 2004

Checkout PatternSkinUsingTT2Templates for an experimental setup for exploring this topic in further detail.

-- VinodKulkarni - 20 Mar 2005

My complaint about the current templates is that they are not systematically or partially overloadable at a user installation. Here are my two use cases:

  • I would like to add a "register for notification" button to all views (independent of what skin is being used) without having to go into every template/view.*.tmpl file and understand and change it.
    • To make this a little harder (the formulation here could be achieved by just moving the topicactions into a configurable topic (as we do now with web left bar etc. in PatternSkin) let's assume this button should be just below the text area to the right of the page.
  • I would like to add a comment entry box (from CommentPlugin) for selected topics, not in the text area, but as part of the template, so users cannot accidentally delete it). The full version of this use case is a per topic style that may modify part of the view template (I do this today with MultiEditPlugin to impose a layout on a topic beyond the template and edit only through the controls from MultiEditPlugin, but this is not the desired solution?)
These use cases are for the view template only, but similar cases could be concocted for the edit templates or preview templates also.

-- ThomasWeigert - 20 Mar 2005

These use cases are largely independent of the template system used, I think. They are more a function of the architecture of the templates themselves. There is a problem with TWiki in that the code knows far too much about the structure of the templates, and I would aso accept that performance of the current TWiki system discourages "over flexible" templates.

-- CrawfordCurrie - 20 Mar 2005

Right. I was not arguing for moving to a different templating system, as I stated in my survey entry above. However, there are things I would like to improve with respect to our templating system....

-- ThomasWeigert - 20 Mar 2005

ConsolidateFunctionalityFromSkins RationalisedTWikiSkins

I still think that using a 3rd party templating system is a viable route.

-- MartinCleaver - 08 Apr 2006

It would be great if it is indeed a viable route. It would certainly invite people who had used such a system to create a skin for TWiki.

-- MeredithLesly - 08 Apr 2006

hmm... I hate to mention this, but we need to keep in mind backward compatibility. We don't want those that have invested in custom skin to redefine their whole look & feel implementation just because they upgraded. And at the risk of sounding repetitive: We need pluggable implementations. In this case, pluggable template system, so old sites may use the "traditional" templating mechanism, and those who want to live in the future can use any of the new templating mechanism.

-- RafaelAlvarez - 08 Apr 2006

Note CgiApplicationFramework includes a framework for pluggable template systems. We could roll TWiki templates next to Template Toolkit and please both communities.

Additionally you don't need to take all of CgiApplicationFramework - you just pick the bits you want.

-- MartinCleaver - 08 Apr 2006

And... PatternSkinUsingTT2Templates has the basis for a conversion.

-- MartinCleaver - 08 Apr 2006

I would really like to have them pluggable at TWiki level, not at the framework level. I think that CPAN dependencies must be optional, as we already have too many complains on "TWiki is complex to install"

-- RafaelAlvarez - 08 Apr 2006

I disagree. We need a greater ApplicationServer framework to have a set of mechanisms for coordinating with non-TWiki led initiatives.

-- MartinCleaver - 08 Apr 2006

That may put us in a disjunctive point: We can have a powerful yet easy to install TWiki, or we can have a powerful yet maintainable only by skilled admin ApplicationServer.

On that point, MartinCleaver commented on TWikiIRC that the solution may be to ship all the required perl modules in CpanContrib so they can be distributed for easier installation.

-- RafaelAlvarez - 09 Apr 2006

Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r18 - 2008-08-24 - 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.