On Mon, 21 May 2001, Andy Wardley wrote:
Thanks Andy,
> On Sun, May 20, 2001 at 05:58:18PM +0800, Stas Bekman wrote:
> > Using CGI and TT in the same app is an overkill under mod_cgi. Using
> > CGI.pm for HTML generation is slow. Since this is a templating forum we
> > don't need CGI.pm for generating HTML. But we still miss the functionality
> > like stickiness and HTML form widgets API. Is there anybody cooking up a
> > widgets plugin with an API of CGI.pm (to make an easy drop-in replacement)
> > or even different?
>
> I've got a simple HTML plugin which generates attribute lists and
> elements from hash arrays. I'm planning to release it with the next
> version. e.g.
>
> [% USE html %]
> [% html.element(table => { cellpadding => 4 }) %]
>
> Of course, it tends to be more useful like this:
>
> [% html.element( table => my.html.table.style ) %]
>
> I'm sure this could be extended quite easily to do most of the regular
> HTML generation that CGI does, and possibly a bit more, too.
won't html.table(), html.tr() shorter? Or have you reserved the first
level for some other functionality?
> In the case of forms, I would suggest an XML/VIEW approach. Create an
> XML file which describes your form semantically, and create a view
> which renders it into an HTML form.
>
> <form>
> <textfield id="name" length="32"/>
> <product_selector id="prodid"/>
> <address>
> <textfield id="street" length="64"/>
> ...
> </address>
> </form>
>
> What would be useful is a set of templates to supplement the existing
> HTML library for all the various form elements. e.g.
>
> html/form
> html/field/text
> html/field/checkbox
> html/field/hidden
> ...
>
> You would create your own view which implements your site specific form
> elements like <product_selector> and also does your layout specific stuff
> for <address>, etc. Everything else would be inherited from an html
> form/field view which supplies the default templates for <textfield> and
> so on.
But this only talks about simple rendering. But take for example something
like a date widget. When introduced in the <FORM> we want the date widget
to appear as [YEAR][MONTH][DAY] (3 elements), whereas for usual user
display mode it should automatically know to render itself as %d-%M-%Y
strftime string and similar. We are talking about "inteligent" widgets,
doing different things in different contexts.
I suppose it might be a mistake to try to provide TT-specific widget
library, and it should be a more abstract thing with glues to various
backends (TT/CGI/...) and frontends (CGI/Apache::Request/...).
Gunther has started this thread on the mod_perl list, it seems that such a
beast doesn't exist in Perl domain, and there are people willing to give
hand, but so far nobody has offered to start a new Perl project and lead
the effort. Hmm, may be someone on this list needs the same kind of
functionality and have the interest/resources to start the project to
implement smart widgets in Perl.
> > So I was thinking that some sort of collaboration between Apache::Request
> > (or even CGI.pm for mod_cgi) and TT would be extremely useful, where the
> > the former playes the role of handling incoming GET/POST data, handing it
> > to TT transparently to the user (like CGI.pm does) and the latter knows
> > how to render the final HTML/other widget(s), and probably knows about
> > stickyness of data.
>
> Yes, I like the idea. Maybe this could be implemented at the Service
> level? For example, subclass Template::Service to Template::Service::HTTP
> to add the HTTP GET/POST methods. The existing Template::Service::Apache
> module (part of Apache::Template) could then be derived from that. We
> would probably want a Template::CGI module which automatically selects
> the HTTP SERVICE object, but otherwise acts just like Template. This would
> allow people to write their CGI scripts as:
>
> use Template::CGI;
> $tt = Template::CGI->new( ... );
>
> At the start of the template request, the service could either (depending
> on configuration) examine the HTTP headers and pre-parse them, storing the
> results in the stash somewhere, or install callbacks or other references
> into the stash for users and/or plugins to utilise as they require.
>
> The HTTP plugin could then be an interface back to the request (via the
> service callbacks) through which templates could examine headers, set
> cookies, etc.
Whoah, this means that just like with DBI plugin you can write simple cgis
with almost no perl side code to interact with DB, you will be able to
write simple cgi scripts with no perl code at all :)
> Sounds good. Who wants to write it? :-)
I'd definitely do that if... I won't need to port our old ADT HTML-in-Perl
implementation to use TT and separate views from the code on the way.
This looks like a great project to learn TT guts, so probably somebody on
this list will be glad to jump on this challenging problem, implement it
and enjoy the gratitude of fellow perl/tt coders.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
