You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by mgraham <mg...@toronto.circadence.com> on 2000/07/24 18:58:35 UTC
RE: The Template Toolkit (Re: Templating Systems)
> Andy Wardley wrote:
> * The Template Toolkit is *ONLY* a template system. This is a Good
> Thing. It processes text (HTML, Latex, POD, etc). You can use it
> under Apache/mod_perl, in stand-alone CGI scripts, or in other
> environments entirely unrelated to HTML or the web. This is also
a
> Good Thing.
Form state-maintenance and validation is a grey area. I'd love to
have a TT module that was capable of maintaining form state, and
validating user input. This is an application that doesn't have much
to do with templating per se, but the module would nevertheless need
intimate knowledge of the template internals.
For instance, I would like a backend web application to be able to
learn about form fields from the template tags:
[% input type='text' name='email' required=1
validate_as='email_address' %]
The program then knows that the 'email' field is required. Later on,
a manager can instruct an HTML designer to make the email field
optional. And the backend application doesn't need to be modified at
all. Or, more importantly, retested.
Template::Toolkit v2 does look very interesting, but it look like it
is missing the hooks into the Template structure that a comprehensive
Form module would need. For instance, how would the module gather the
info about a template when it had already been compiled and cached on
disk?
I've been using Text::Boilerplate for years, mainly because it already
had special HTML form field tags. Over time I've added additional
features, like form validation and cacheing (via Files or DBI) the
compiled templates as perl code. Eventually, I'd like to release my
extensions, but I'd be just as happy if the same functionality could
be built in to another system, such as Template::Toolkit.
Michael
Re: The Template Toolkit (Re: Templating Systems)
Posted by David Hodgkinson <da...@hodgkinson.org>.
"mgraham" <mg...@toronto.circadence.com> writes:
> > Andy Wardley wrote:
> > * The Template Toolkit is *ONLY* a template system. This is a Good
> > Thing. It processes text (HTML, Latex, POD, etc). You can use it
> > under Apache/mod_perl, in stand-alone CGI scripts, or in other
> > environments entirely unrelated to HTML or the web. This is also
> a
> > Good Thing.
>
> Form state-maintenance and validation is a grey area. I'd love to
> have a TT module that was capable of maintaining form state, and
> validating user input.
...and better still having an intimate relationship with an
underlying database schema :-)
--
Dave Hodgkinson, http://www.hodgkinson.org
Editor-in-chief, The Highway Star http://www.deep-purple.com
Apache, mod_perl, MySQL, Sybase hired gun for, well, hire
-----------------------------------------------------------------
Re: XForms & ASP (was: The Template Toolkit )
Posted by Joshua Chamas <jo...@chamas.com>.
Dmitry Beransky wrote:
>
> [Mon Jul 31 10:45:53 2000] (eval 76): String found where operator expected at
> (eval 76) line 50, at end of line
> [Mon Jul 31 10:45:53 2000] (eval 76): (Missing operator before ?)
> [Mon Jul 31 10:45:53 2000] [error] [asp] [605] [error] [Mon Jul 31 10:45:53 20
> 00] (eval 76): Can't find string terminator "'" anywhere before EOF at (eval 7
> 6) line 50. <--> , /usr/lib/perl5/site_perl/5.005/Apache/ASP.pm line 1740
>
> It doesn't look like I have any runaway strings, so any idea what gives?
>
The XMLSubsMatch parser is pretty aggressive, and found a
tag in your <% perl code %> that it tried parsing. If you
had debug 2 set, the output would give you more of a hint
as to what was going on. It doesn't only look for tags
in the HTML segments, though this is what it ought to do.
I would recommend using the Script_OnFlush event handler
to grab all of the data at once and process it with XML, or the
XSLT extension even. You can find the response buffer in
$Response->{BinaryRef} as a scalar reference. This member
is documented at:
http://www.apache-asp.org/objects.html
Only if you are looking to extend all forms with the
the xform might I implement this with XMLSubsMatch.
-- Joshua
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks >> free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
Re: XForms & ASP
Posted by Joshua Chamas <jo...@chamas.com>.
Dmitry Beransky wrote:
> ...
> recognizable tokens (as in '<'.'form'). Unfortunately, I cannot use XML or
> XSLT processing, as you recommend, because the content of the tags often is
> HTML. This brings me to another question. Is (would) it possible to do
> recursive recursive XML processing (similar to XSLT) with ASP? Here's an
> example:
>
> <html>
> <head>
> <xform id="formID">
> ...
> </xform>
> </head>
> <body>
> ...
> <asp:form id="formID">
> First name: <asp:input id="firstName"/>
> Last name: <asp:input id="lastName"/>
> </asp:form>
> </body>
> </html>
>
> What I need to do is to process the asp:form element, transform the tag
> itself into appropriate html and then recursively process its content, so
> that I could get to the asp:input tags.
>
If its HTML you need, you could substitute a call to
HTML::Parser instead with a XMLSub <asp:form> to
look for the input tags. You could also do this
all at once at the Script_OnFlush event to parse
both the xform and form at runtime.
If you wanted just a XMLSubsMatch approach, you will have
to work backwards, because inner tags are evaluated
first as sub routines. If you need the input data when you
evaluate the <asp:form>, then you could try using script
globals to capture data for you, like in each input tag
you could set something in $Inputs{$id} = $data and
then reference %Inputs in your <asp:form> ... that's
pretty backwards, and is a limitation with a pure
XMLSubs approach to a problem like this.
Best of luck, and I am very interested in what you
end up with.
-- Joshua
XForms & ASP (was: The Template Toolkit )
Posted by Dmitry Beransky <db...@ucsd.edu>.
I'm still pretty vague on where I want to go with this myself :). Just
bits and pieces of ideas. Last night I tried to put something together,
though, and ran into a strange problem which I can't figure out how to
solve. Perhaps, you may have a suggestion, Joshua (the xform markup's
taken directly from w3c's side):
Here's my sample ASP file:
<%@language="PerlScript"%>
<%
use XML::DOM;
use XML::XPath;
my ($xform,$xform_xpath);
%>
<html>
<head>
<xform xmlns="http://www.w3.org/2000/xforms"
action="http://www.my.com/cgi-bin/receiver.pl"
method="postXML"
id="po_xform">
<model>
<group name="purchaseOrder">
<group name="shipTo">
<string name="name"/>
<string name="street"/>
<string name="city"/>
<string name="state"/>
<string name="zip">
<mask>ddddd</mask>
</string>
</group>
</group>
</model>
</xform>
</head>
<body>
<h1>Form</h1>
<form id="po_xform"/>
<form/>
</body>
</html>
<%
sub form
{
}
sub xform
{
my ($attributes, $body) = @_;
my $parser = new XML::DOM::Parser;
$body =~ s/\n//mgs;
$body = "<xform>$body</xform>";
$Response->Write($body );
}
%>
when I run this, I get the following error:
[Mon Jul 31 10:45:53 2000] (eval 76): String found where operator expected at
(eval 76) line 50, at end of line
[Mon Jul 31 10:45:53 2000] (eval 76): (Missing operator before ?)
[Mon Jul 31 10:45:53 2000] [error] [asp] [605] [error] [Mon Jul 31 10:45:53 20
00] (eval 76): Can't find string terminator "'" anywhere before EOF at (eval 7
6) line 50. <--> , /usr/lib/perl5/site_perl/5.005/Apache/ASP.pm line 1740
It doesn't look like I have any runaway strings, so any idea what gives?
Thanks
Dmitry
At 09:01 PM 7/29/00, Joshua Chamas wrote:
>If you could tell me more about this sometime, like where you
>are going with this, and how this might be brought into the
>server to ease developer use that would be great. Its still
>takes a bit to get my head around XML ways of looking at things.
>Dmitry Beransky wrote:
> >
> > That's where the XForm may come quite handy
> > (<http://www.w3.org/MarkUp/Forms/>). The specification is still been
> > worked on, but it has some parts that can already be used on the back
> > end. I can see it (me thinks) fit quite nicely into Apache::ASP XML
> > processor. I thought about coding it up, but never got the time.
> >
Re: The Template Toolkit (Re: Templating Systems)
Posted by Joshua Chamas <jo...@chamas.com>.
Dmitry Beransky wrote:
>
> At 09:58 AM 7/24/00, mgraham wrote:
> >For instance, I would like a backend web application to be able to
> >learn about form fields from the template tags:
> >
> > [% input type='text' name='email' required=1
> >validate_as='email_address' %]
>
> That's where the XForm may come quite handy
> (<http://www.w3.org/MarkUp/Forms/>). The specification is still been
> worked on, but it has some parts that can already be used on the back
> end. I can see it (me thinks) fit quite nicely into Apache::ASP XML
> processor. I thought about coding it up, but never got the time.
>
If you could tell me more about this sometime, like where you
are going with this, and how this might be brought into the
server to ease developer use that would be great. Its still
takes a bit to get my head around XML ways of looking at things.
What I do see from second glance that there is at least the
possibility for a XSLT stylesheet to be developed that would
take care of an XML form consisting of both the xform data
and the regular form for processing. But still it seems
that there might be some part of the XML form generation
that could be handled by the server. Perhaps what would
facilitate this model would be to render the $Request->Form()
data into the XML somewhere so that XSLT processor could
then pick it up?
Does this standard cover the way in which the developer
might then work with the data on the server? I'm wondering
if in ASP the developer would still use $Request->Form()
for final data storage with whatever database backend
or XML that needs interfacing with. I didn't quite get
in the example of how the XML file might get updated.
-- Joshua
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks >> free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
Re: The Template Toolkit (Re: Templating Systems)
Posted by Kip Hampton <kh...@totalcinema.com>.
Matt Sergeant wrote:
>
> On Sat, 29 Jul 2000, Ian Kallen wrote:
>
> >
> > XForm sounds just like something I need actually, can any of the XSLT
> > tools transform it? In perl, of course, XML::XSLT, Sablotron (which
> > doesn't compile on FreeBSD btw, feh!)?
>
> I don't think any tools support it yet. The only thing that may come close
> is the FP taglib in Cocoon, which I'd point you to, but something is going
> really slow this morning. Its in the CVS archive only at this point, and
> there's a README in the docs section of the distribution.
>
> Kip Hampton has said he'll work on an equivalent taglib for AxKit.
Yup. Though, XForms is (will be) considerablbly more powerful. The fp
taglib is more concerned with reading/writing form data in XML while
XForms seeks to redefine forms technology in general.
FWIW, the folks over a Stack Overflow have created Mozquito
(http://www.mozquito.org/) that trys to implement many of the cool
features of XForms for today's browsers. What they've done is pretty
astonishing, but when I saw how it worked I ran screaming from the
building. . .
-kip
RE: The Template Toolkit (Re: Templating Systems)
Posted by Matt Sergeant <ma...@sergeant.org>.
On Sat, 29 Jul 2000, Ian Kallen wrote:
>
> XForm sounds just like something I need actually, can any of the XSLT
> tools transform it? In perl, of course, XML::XSLT, Sablotron (which
> doesn't compile on FreeBSD btw, feh!)?
I don't think any tools support it yet. The only thing that may come close
is the FP taglib in Cocoon, which I'd point you to, but something is going
really slow this morning. Its in the CVS archive only at this point, and
there's a README in the docs section of the distribution.
Kip Hampton has said he'll work on an equivalent taglib for AxKit.
>
> Yesterday, Dmitry Beransky <db...@ucsd.edu> frothed and gesticulated...:
> > That's where the XForm may come quite handy
> > (<http://www.w3.org/MarkUp/Forms/>). The specification is still been
> > worked on, but it has some parts that can already be used on the back
> > end. I can see it (me thinks) fit quite nicely into Apache::ASP XML
> > processor. I thought about coding it up, but never got the time.
>
> --
> Salon Internet http://www.salon.com/
> Manager, Software and Systems "Livin' La Vida Unix!"
> Ian Kallen <id...@salon.com> / AIM: iankallen / Fax: (415) 354-3326
>
>
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
RE: The Template Toolkit (Re: Templating Systems)
Posted by Ian Kallen <sp...@salon.com>.
XForm sounds just like something I need actually, can any of the XSLT
tools transform it? In perl, of course, XML::XSLT, Sablotron (which
doesn't compile on FreeBSD btw, feh!)?
Yesterday, Dmitry Beransky <db...@ucsd.edu> frothed and gesticulated...:
> That's where the XForm may come quite handy
> (<http://www.w3.org/MarkUp/Forms/>). The specification is still been
> worked on, but it has some parts that can already be used on the back
> end. I can see it (me thinks) fit quite nicely into Apache::ASP XML
> processor. I thought about coding it up, but never got the time.
--
Salon Internet http://www.salon.com/
Manager, Software and Systems "Livin' La Vida Unix!"
Ian Kallen <id...@salon.com> / AIM: iankallen / Fax: (415) 354-3326
RE: The Template Toolkit (Re: Templating Systems)
Posted by Dmitry Beransky <db...@ucsd.edu>.
At 09:58 AM 7/24/00, mgraham wrote:
>For instance, I would like a backend web application to be able to
>learn about form fields from the template tags:
>
> [% input type='text' name='email' required=1
>validate_as='email_address' %]
That's where the XForm may come quite handy
(<http://www.w3.org/MarkUp/Forms/>). The specification is still been
worked on, but it has some parts that can already be used on the back
end. I can see it (me thinks) fit quite nicely into Apache::ASP XML
processor. I thought about coding it up, but never got the time.
Cheers
Dmitry