RE: The Template Toolkit (Re: Templating Systems)

2000-07-30 Thread Matt Sergeant

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 [EMAIL PROTECTED] 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 Internethttp://www.salon.com/
   Manager, Software and Systems "Livin' La Vida Unix!"
 Ian Kallen [EMAIL PROTECTED] / 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)

2000-07-30 Thread Kip Hampton



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)

2000-07-29 Thread David Hodgkinson


"mgraham" [EMAIL PROTECTED] 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: The Template Toolkit (Re: Templating Systems)

2000-07-29 Thread Joshua Chamas

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.com1-714-625-4051



RE: The Template Toolkit (Re: Templating Systems)

2000-07-29 Thread Ian Kallen


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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] / AIM: iankallen / Fax: (415) 354-3326 




Re: The Template Toolkit (Re: Templating Systems)

2000-07-28 Thread dreamwvr

Hi,
   as mentioned i would like to use perl for a competitive replacement on a bid 
competing with eprise product(which i am still trying to figure out exactly
what it does;-)) doesn't look like much though. anyhow i would like the 
ability like say freshmeat.net does of combining mysql backend with a 
templated front end in their instance php.. but i would like to use mod_perl 
as well it is IMHO more flexible and the skills more applicable to many 
other non web situations. Anyhow i would guess that the potential 
customer will want to do a lot themselves 'most do' so i would like to 
use a template system so that they just drop the file in a specific directory 
and the rest happens for them. that way they don't need to know any 
web stuff except how to ftp the files.. well that is sort of the plan anyhow..
is this a good plan or a recipe for disaster?
TIA 
[EMAIL PROTECTED]



RE: The Template Toolkit (Re: Templating Systems)

2000-07-28 Thread mgraham


 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)

2000-07-28 Thread Dmitry Beransky

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




Re: The Template Toolkit (Re: Templating Systems)

2000-07-28 Thread JoshNarins

Oh, and can I relate a brief success story I had with Mason?

I am going to support frames on my site for trans-oceanic surfers
who appreciate everything I can do to limit download times.

With Mason, the whole thing was done with a shadow directory,
2 autohandlers and three frameset files. It is generally possible
with 1 autohandler and 1 frameset.
The main components slipped into the frames as if GREASED.