Feature Proposal: Reduce impact of CGI.pm in Foswiki

Motivation

CGI.pm was removed from the perl code; all HTML rendering features will be removed from CGI.pm soon

Description and Documentation

CGI.pm has got a long past and probably a not so long future anymore. Foswiki uses CGI.pm for two main purposes:

(1) implementation of http calling semantics

(2) rendering of HTML markup

These two need to be reworked. While (2) is actually quite straight forward (1) is not as we need to replace it with something else presumably PSGI/Plack. This however means that a lot of other code built around CGI.pm will have to be rewritten as well. Some of it can be plain thrown away it would be superseeded by PSGI/Plack equivalent features. Which is actually a good thing to do as this reduces the size of homegrown codebase as well.

Moving away from CGI.pm to PSGI/Plack is a value of its own as it would (hopfully) ease deploying and running Foswiki at the same time.

Reducing the impact of CGI.pm foremost means to adress the low hanging fruits in (2) and probably approach (1) as well. But that may need another feature request in its own.

See also Lee Johnson's talk about the future of CGI.pm

TWiki takes a somewhat different approach by adding CGI.pm to the core distribution. That's something I'd like to avoid in any case, last but not least as we just recently removed 3rd party CPAN libraries from the Foswiki distro as they were outdated and redundant.

Impact

This affects not only the core but also a lot of plugins that interact with the Request object using CGI.pm directly (bad habbit anyway), or for HTML rendering. Some of these plugins are high profile plugins as they are used a lot.

Implementation

-- Contributors: MichaelDaum - 30 Mar 2015

Discussion

My question is: How this impacting the 1.2 release process?
E.g. The 1.2 will be released in (says 1-2 months) with most of CGI.pm code-generation and request/respond handling, and before CGI.pm 5.x will come (in 2016) will be released another FW version says 1.3 (major -> PSGI) or 1.2.1 with some CGI.pm rework - or the release 1.2 will be delayed? (My own wish : release the 1.2 as soon as possible, with CGI and after go for 1.3 (PSGI) :))

-- JozefMojzis - 30 Mar 2015

This is PlannedFor 2.2 in genreal. If we can get rid of the html rendering part before, then we will release it as part of the 1.x branch. PSGI is something different I think and more likely to make it worth a Two Dot Oh.

-- MichaelDaum - 30 Mar 2015

I had a pre-existing function in the EditRowPlugin that I have moved up to Render.pm (strictly as an internal API until 1.3, and only to be used with care)

=begin TML

---++ StaticMethod html($tag, $attrs, $content) -> $html

Generates HTML for the given HTML tag name, plus an optional map of attributes
and optional content. Attribute values will be safely encoded for use in HTML.
However TML is *not* escaped.

Can be used to replace many of the CGI::* html generation methods.

Use it like this:

   * Foswiki::Render::html('a', { href => $url, name => 'blah' }, 'jump');
   * Foswiki::Render::html('br');
   * Foswiki::Render::html('p', undef, 'Now is the time');

=cut

-- CrawfordCurrie - 30 Mar 2015

I've started a branch on github that renders html using the Template engine. This was done as a "quick & dirty" to address utf-8 rendering issues which have since been solved in other ways. So the design needs some review and rework before it moves ahead.

• Implements Foswiki::Render::HTML with methods that have limited compatibility with the CGI::xxxxmethods
  • Currently implements HTML::textarea HTML::textfield HTML::checkbox_group and HTML::radio_group
• Adds a new template file: templates/html.tmpl with templates that correspond to the methods, or method components:

Method	template	Purpose
HTML::textarea()	textarea
HTML::textfield()	textfield
HTML::checkbox_group()	cbgroup:table	Renders the table container for the group
HTML::checkbox_group()	cbgroup:row	Renders the row container for the group
HTML::checkbox_group()	cbgroup:checkbox	Renders a single checkbox
HTML::radio_group()	radio:table	Renders the table container for the group
HTML::radio_group()	radio:row	Renders the row container for the group
HTML::radio_group()	radio:button	Renders the a single radio button

There are several issues with this branch: (issues identified by MichaelDaum)

1. CSS is currently passed via the static call. It should be moved into the template for better skin capabilities
2. the way to handle attribute encoding - those that end with an 'e', e.g. in 'value' - thats pretty odd

This work is checked into the HTMLTemplates branch

-- GeorgeClark - 30 Apr 2015

Marking this as an accepted proposal. No concerns raised.

-- GeorgeClark - 18 Jul 2015

Withdrawing the status on this. Even though there were no objections, there were concerns raised in IRC discussions. In particular, the design decisions on where to insert things like classes (code or template). All mentioned above on the 30 April comments.

-- GeorgeClark - 16 Nov 2015

If we want Foswiki to be skinnable in details, we need to use templates for everything. When someone wants implement a SKIN using for example any existing CSS framework (such UIKit, Bootstrap, Foundation etc..), some UI widgets needs to use predefined HTML constructions. For example, in the UI Kit for the nice searchbox need to use:

<form class="uk-search" data-uk-search>
    <input class="uk-search-field" type="search" placeholder="">
</form>

e.g. need to use exactly defined constructions.

Even if we will generate all CSS using the SCSS processor, we still need allow change the markup, for the particular page elements, like: search box, jump-box, attachment-table, attachment-table-row, and so on...

Therefore the ideal Foswiki will use templates for the defined page elements (blocks). The block could be an simple "text-area" HTML tag alone, but preferebly it will be an logically defined part of the page, as: "search-box" "jump-field" and so on.

The user usually wants change the HTML markup for such blocks and not the simple html tag markup, so we don't need a template for the <li> tag, but need a template for the "weblist-element".

Of course, grouping (and dividing) the foswiki into such logical blocks is a big task to be done "all at once". So, probaby the usable workflow will be:

1. change the CGI::some_markup tags to some non CGI perl code. (aka CDot's HTML::some or using the CPAN:HTML::Tiny and so on
2. step-by-step implement and refine the final solution by using the templates for the different "page-blocks".

This allows us throw away the CGI as fast as possible, and gives us time to implement some nice and final solution.

-- JozefMojzis - 22 Feb 2016

And we will still need some non-template based html generation, for some early error messages. (such, fatal errors).

Would be hard send to the user an nice error message: Couldn't open the templates diretory when the error-message want use some template. This is like the: "Keyboard not found. Press any key to continue".

-- JozefMojzis - 22 Feb 2016

Commenting is disabled while not logged in