Re: Templating Solutions

2001-06-19 Thread Leo Lapworth

True, DW monkey can crap anything up, but not True that
H::T is better to DW edit than T::T (You can set your tags
to be !-- TT_CODE -- just as with H::T.

Leo

On Mon, Jun 18, 2001 at 05:34:44PM +0100, Struan Donald wrote:
 * at 18/06 17:21 +0100 Roger Burton West said:
  On Mon, Jun 18, 2001 at 04:36:00PM +0100, Greg McCarroll wrote:
  
  The main reason I prefer H::T to T::T is that H::T templates can be
  given to Dreamweaver monkeys to edit without my having to worry that
  they'll screw them up.
 
 That is an important consideration although in my experience a
 taleneted dreamweaver mokey can screw up pretty much anything that
 isn't created by dreamweaver in the first place.
 



Re: Templating Solutions

2001-06-19 Thread Leo Lapworth

Philip,

Have a look at this, TT2 based solution, it's a bit
bloated (as it includes page numbering and various other
functions):

http://test.cuckoo.org/script_template.txt,
the key line is: 
my $results = Emap::HolidayFinder::Tod::do_search(\%form_input,$dbh); 

This is then merged with the template by parsing it
in as a reference in %vals.

The template used (depending on number of results) would
either be:
http://test.cuckoo.org/template_results.txt
http://test.cuckoo.org/template_search.txt

Hope these examples make it clearer how design logic can
be seperated. Especially note that the code does not have
to worry about how to get a drop down list value selected
or whether an error message is to be shown (just if it
should be set).

Leo

On Tue, Jun 19, 2001 at 07:45:26AM +0200, Philip Newton wrote:
 Matthew Byng-Maddick wrote:
  It is possible to write embedded perl templates well, but a
  lot more difficult than if they are separated out.
 
 How does non-embedded Perl look like, then?




Re: Templating Solutions

2001-06-19 Thread Robert Price

At 08:36 AM 6/19/01 +0100, Leo wrote:
Have a look at this, TT2 based solution, it's a bit
bloated (as it includes page numbering and various other
functions):

http://test.cuckoo.org/script_template.txt,
the key line is: 
my $results = Emap::HolidayFinder::Tod::do_search(\%form_input,$dbh); 

[snip]

Hope that's not copyrighted Emap code you have there :-)

Rob




Re: Templating Solutions

2001-06-19 Thread Leo Lapworth

On Tue, Jun 19, 2001 at 10:11:47AM +0100, Robert Price wrote:
 At 08:36 AM 6/19/01 +0100, Leo wrote:
 http://test.cuckoo.org/script_template.txt,
 the key line is: 
 my $results = Emap::HolidayFinder::Tod::do_search(\%form_input,$dbh); 
 
 [snip]
 
 Hope that's not copyrighted Emap code you have there :-)
 

Was part of what I got permission to 'open source' :)

- It's not as if they're going to want to use it any more :)

Leo



Re: Templating Solutions

2001-06-19 Thread Steve Purkis

David Cantrell wrote:
 
 On Mon, Jun 18, 2001 at 08:24:13PM +0100, Matthew Byng-Maddick wrote:
  On Mon, Jun 18, 2001 at 07:54:36PM +0100, David Cantrell wrote:
   On Mon, Jun 18, 2001 at 04:46:25PM +0100, Leo Lapworth wrote:
I'd also like to mention HTML::Mason - Euuu, No, no and thrice no!
(ok, has some nice 'bits' but NO - thou shalt not put thy
HTML and thy Perl in the same file).
   It is NOT POSSIBLE to completely divorce presentation/application.
   So you end up with all sorts of languages made up to be mixed in with
   the presentation - like PHP and the mini-language of TT.  Why are
   those OK (I'm thinking specifically of TT - we all know PHP sucks for
   other reasons) but plain ol' perl isn't?
 
  Ohmigod, I'm agreeing with Cantrell on something!!
 
 What am I doing wrong? ;-)
 
 Seriously, I agree 100% that you should strive to seperate application
 from your presentation as much as possible, but seeing that you can not
 do this entirely, you may as well embed perl in your HTML and save
 yourself the trouble of inventing a whole new wheel.

That sounds like a contradictory statement there - of course the line
will never be 100% clear  cut-out...  And as for inventing new wheels -
well we're all coders  scientists  engineers here...  That's what we
do!


 You can still stick your business logic elsewhere and have that called
 by the perl embedded in the templates.


I see where you're coming from, but think about how this will be abused
- coders will get lazy and eventually just embed all the business logic
in the templates.  Then your life will be a living hell.  As a worst
case scenario you'll end up with (eek!) an inverted Bugzilla!  ;-)

With the vast array of options we've got on Perl tools for templating 
embedding  serving (and other -ings), it seems to me the trend is to
create a whole bunch of new wheels.  Then everybody talks about them 
the better wheel(s) is pointed out, and then maybe then the wheels are
improved to become uber-wheels while in the background the cycle repeats
itself...

I'd argue that embedding code in your templates is on the way out, and
the sooner it goes the better.  I think it was a necessary step away
from embedding templates in your code (eg. cgi scripts), but now it's
time to recognize the aforementioned split  revise our models  tools
accordingly (and create new ones if necessary).

But then again, this has prolly all been said before.  Anyways, that's
my 2c.

--
 Steve Purkis  [EMAIL PROTECTED] t: +44 (0) 207 614 8600
 Unix Developer  red | hot | chilli f: +44 (0) 207 614 8601



Re: Templating Solutions

2001-06-19 Thread David Cantrell

On Tue, Jun 19, 2001 at 10:20:37AM +0100, Steve Purkis wrote:
 David Cantrell wrote:
  
  Seriously, I agree 100% that you should strive to seperate application
  from your presentation as much as possible, but seeing that you can not
  do this entirely, you may as well embed perl in your HTML and save
  yourself the trouble of inventing a whole new wheel.
 
 That sounds like a contradictory statement there

I don't think so.  Whilst you should seperate application and presentation
as much as possible, it's a recognition that you'll never be able to
*entirely* seperate them, and so seeing that you're going to have to have
*some* code mixed in with your presentation, you may as well re-use an
existing language instead of inventing a new one.

   of course the line
 will never be 100% clear  cut-out...  And as for inventing new wheels -
 well we're all coders  scientists  engineers here...  That's what we
 do!

Well yeah, and it's fun too, but in this case the new wheel is not
necessary.  And if I'm building this for your company, I think you'd
rather I spent time writing a kick-ass application (which would of
course be maintainable, extensible, scalable and all sorts of other
laudable -ables) rather than spending the same amount of time writing
a kick-ass mini-language (or learning someone else's mini-language)
and a mediocre app.

 I see where you're coming from, but think about how this will be abused
 - coders will get lazy and eventually just embed all the business logic
 in the templates.

Yes, they will.  Unless you have proper procedures in place to prevent
it.  Luckily, perl makes it rather easy to encapsulate application logic
elsewhere.

 I'd argue that embedding code in your templates is on the way out, and
 the sooner it goes the better.

So how do you think it can be achieved?

-- 
David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david/

  Good advice is always certain to be ignored,
  but that's no reason not to give it-- Agatha Christie



Re: Templating Solutions

2001-06-19 Thread Ian Brayshaw

snip type=inevitable love/hate circular debate/

I was going to stay quiet on this one (still don't know why I am now joining 
in).

I am finding XSLT  XML to be a good alternative to normal templating 
techniques. One of the biggest benifits I've found is being able to generate 
the one data set and have it rendered in different ways for different 
applications. I presume this is possible in TT2. H::T has the drawback of 
only allowing substitutions for tags defined in the template. Changing the 
template to render say a reduced set of data typically involves changing 
code.

I'm also free to choose my transformation platform, using something like 
XML::LibXML or Saxon on the server side, or just throwing it straight to the 
user and letting their browser take care of the rest.

Don't think DW jockeys will like the XSLT, but I'm fortunate in not having 
to deal with them.

My £0.02


Ian
(... trying desparately to avoid joining the XML bandwagon ...)
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.




RE: Templating Solutions

2001-06-19 Thread Cross David - dcross

From: David Cantrell [EMAIL PROTECTED]
Sent: Tuesday, June 19, 2001 10:51 AM

 On Tue, Jun 19, 2001 at 10:20:37AM +0100, Steve Purkis wrote:
  David Cantrell wrote:
   
   Seriously, I agree 100% that you should strive to seperate application
   from your presentation as much as possible, but seeing that you can
not
   do this entirely, you may as well embed perl in your HTML and save
   yourself the trouble of inventing a whole new wheel.
  
  That sounds like a contradictory statement there
 
 I don't think so.  Whilst you should seperate application and presentation
 as much as possible, it's a recognition that you'll never be able to
 *entirely* seperate them, and so seeing that you're going to have to have
 *some* code mixed in with your presentation, you may as well re-use an
 existing language instead of inventing a new one.

But as Richard wrote yesterday, the point of mini-languages like the TT2
language is that they are specialised for one particular process[1]

In the case of TT2, you can write logic in it, but it's only very simple
presentaional logic (output one of these blocks for each thing in this list,
for example).

Another good reason, is that the people designing the output format aren't
necessarily the same people that write the data-gathering application. With
TT2 you can have a team of highly skilled and highly paid Perl programmers
doing extremely clever things to gather the data and a larger team of lowly
paid template designers producing the XML, HTML or whatever templates you
need to output the data. You can learn the TT2 language in an afternoon.
Perl, thankfully, takes a little longer.

Dave...

[1] You don't, for example, object to writing regexes in a mini-language
within Perl.

-- 



The information contained in this communication is
confidential, is intended only for the use of the recipient
named above, and may be legally privileged. If the reader 
of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  
If you have received this communication in error, please 
re-send this communication to the sender and delete the 
original message or any copy of it from your computer
system.



Re: Templating Solutions

2001-06-19 Thread Dominic Mitchell

On Tue, Jun 19, 2001 at 08:08:50PM +1000, Ian Brayshaw wrote:
 I am finding XSLT  XML to be a good alternative to normal templating 
 techniques. One of the biggest benifits I've found is being able to generate 
 the one data set and have it rendered in different ways for different 
 applications. I presume this is possible in TT2. H::T has the drawback of 
 only allowing substitutions for tags defined in the template. Changing the 
 template to render say a reduced set of data typically involves changing 
 code.
 
 I'm also free to choose my transformation platform, using something like 
 XML::LibXML or Saxon on the server side, or just throwing it straight to the 
 user and letting their browser take care of the rest.

Having spent last weekend playing with XSLT and XPath, I've come to
similiar conclusions.  At the very least, XSLT is entertaining.  But
what really blew me away was how easy XPath is for grabbing random bits
of your XML for use elsewhere.  Whoever compared it to regular
expressions for XML wasn't far off the mark.

Combined with psgml-mode in emacs, to create xhtml files, it's a rather
nice authoring solution.

 Don't think DW jockeys will like the XSLT, but I'm fortunate in not having 
 to deal with them.

You'd be surprised how many people are willing to learn something when
it's got microsoft attached to it and big whopping books from que.

-Dom

-- 
| Semantico: creators of major online resources  |
|   URL: http://www.semantico.com/   |
|   Tel: +44 (1273) 72   |
|   Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |



Re: Templating Solutions

2001-06-19 Thread Paul Sharpe

More on XML/XSLT/seperation of roles philosophy

  http://xml.apache.org/cocoon2/index.html

paul

Ian Brayshaw wrote:
 
 snip type=inevitable love/hate circular debate/
 
 I was going to stay quiet on this one (still don't know why I am now joining
 in).
 
 I am finding XSLT  XML to be a good alternative to normal templating
 techniques. One of the biggest benifits I've found is being able to generate
 the one data set and have it rendered in different ways for different
 applications. I presume this is possible in TT2. H::T has the drawback of
 only allowing substitutions for tags defined in the template. Changing the
 template to render say a reduced set of data typically involves changing
 code.
 
 I'm also free to choose my transformation platform, using something like
 XML::LibXML or Saxon on the server side, or just throwing it straight to the
 user and letting their browser take care of the rest.
 
 Don't think DW jockeys will like the XSLT, but I'm fortunate in not having
 to deal with them.
 
 My £0.02
 
 Ian
 (... trying desparately to avoid joining the XML bandwagon ...)
 _
 Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.



Re: Templating Solutions

2001-06-19 Thread Leon Brocard

Jonathan Stowe sent the following bits through the ether:

 As a reference for this kind of thing one might ( if one can be arsed to
 look at Java stuff ) to look at the way the Enhydra thingy does things in
 creating classes in directories like :

We don't need no stinking directories - we can generate Perl code on
the fly. This is why comparing Java and Perl tools is tricky...

Leon
-- 
Leon Brocard.http://www.astray.com/
Iterative Software...http://www.iterative-software.com/

... Change is inevitable, except from a vending machine



Re: Templating Solutions

2001-06-19 Thread Leon Brocard

Dominic Mitchell sent the following bits through the ether:

 You'd be surprised how many people are willing to learn something when
 it's got microsoft attached to it and big whopping books from que.

Would it be entertaining for people to give small talks on the
templating system of their choice at the technical meeting on
Thursday? (as long as everyone don't pick TT2 of course...)

Leon
--
Leon Brocard.http://www.astray.com/
Iterative Software...http://www.iterative-software.com/

... Off the keyboard, thru the router, over the bridge, nothing but net!



Re: Templating Solutions

2001-06-19 Thread Mark Fowler

On Tue, 19 Jun 2001, Ian Brayshaw wrote:

 I am finding XSLT  XML to be a good alternative to normal templating
 techniques. One of the biggest benifits I've found is being able to generate
 the one data set and have it rendered in different ways for different
 applications. I presume this is possible in TT2.

Have a look at http://london.pm.org/~mark/ttxpath/

(from last technical meeting)

Leo's been playing around with this a bit more since the last technical
meeting and I've been talking over him how it's possible to switch views
and have different output

The concept is you have a template that defines what 'bits' of the xml you
want which you pull out with xpath.  You then 'tell' TT to render these
with the view ('output system of choice') which goes through the xml and
converts it into whatever output you feel like recursivly like.

Note that this example has too much code in the template view that
really should be squirrled away/converted into perl (/me hides) but
you get the idea...

Later.

Mark.

-- 
s''  Mark Fowler London.pm   Bath.pm
 http://www.twoshortplanks.com/  [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t-Tputs(cl);for$w(split/  +/
){for(0..30){$|=print$t-Tgoto(cm,$_,$y). $w;select$k,$k,$k,.03}$y+=2}




Re: Templating Solutions

2001-06-19 Thread Steve Purkis

David Cantrell wrote:
 
 On Tue, Jun 19, 2001 at 10:20:37AM +0100, Steve Purkis wrote:
  David Cantrell wrote:
of course the line
  will never be 100% clear  cut-out...  And as for inventing new wheels -
  well we're all coders  scientists  engineers here...  That's what we
  do!
 
 Well yeah, and it's fun too, but in this case the new wheel is not
 necessary.  And if I'm building this for your company, I think you'd
 rather I spent time writing a kick-ass application (which would of
 course be maintainable, extensible, scalable and all sorts of other
 laudable -ables) rather than spending the same amount of time writing
 a kick-ass mini-language (or learning someone else's mini-language)
 and a mediocre app.

Agreed (though, people will sneak things like this in anyway!).  But I
think if you can convince your boss that spending 1 mo developing a
templating system (or any set of tools, really) that you believe will
increase your productivity by a large %, then you should go for it.  But
I stipulate: only if there's a valid business reason.  And it's all the
researching into what other people have done that really takes time.

(as an aside: Maybe there's a real need for evaluation of modules /
systems here which CPAN doesn't [can't?] cover...  If I say something
like `Certified', how many flames will I get? ;-)


  I see where you're coming from, but think about how this will be abused
  - coders will get lazy and eventually just embed all the business logic
  in the templates.
 
 Yes, they will.  Unless you have proper procedures in place to prevent
 it.  Luckily, perl makes it rather easy to encapsulate application logic
 elsewhere.


Unfortunately, Perl's flexibility also makes it hard to develop
procedures for ;-)


  I'd argue that embedding code in your templates is on the way out, and
  the sooner it goes the better.
 
 So how do you think it can be achieved?

Mmm.  Might have to re-phrase that - ... embedding *native* code in
your templates   So I'm saying asp, jsp, etc.. are good attempts,
but at opposite ends of the spectrum.  We need a more central solution.

So to answer your question... (Steve gulps at the risk of being shot for
not reading the rest of this thread...):

In general, I think tools like TT are going down the right path.
But I think that, ultimately, this problem can be solved by introducing
a simple java/ECMA-script like language into the ``html'' layer purely
for presentation logic and access to application data.  The language and
how the application feeds data into the Somethin-script datastructures
would have to be spec'd outside of Perl (for obvious reasons - it's not
Perl!).  Combine this in some fashion with XSL and you've got yourself a
generic [perhaps over generic?] way of delivering what marketeers like
to call dynamic content.

The quick alternative to this is to build javascript data structures
with your application  use JS in combination with DHTML to generate the
pages clientside.  (disclaimer: i may have been on crack when i wrote
this ;-)

Anyway, if you combine the scripting idea with something that's been
kicking around in my head for the past year - namely that Perl needs a
good `Application Server' in order to compete in the high end of the
market - then you've got some more `ground breaking technology' (read:
SuperCoolWheel v3.0! ;) for the Marketeers to yabber on about, and
potentially a useful set of tools for us developers.

Of course, as you point out above, who in their right mind would pay for
a new wheel when you could be making your company money instead?  Even
though there's a potentially *huge* market for this, that's still one
problem I can't solve.

regards,
--
 Steve Purkis  [EMAIL PROTECTED] t: +44 (0) 207 614 8600
 Unix Developer  red | hot | chilli f: +44 (0) 207 614 8601



Re: Templating Solutions

2001-06-18 Thread Dominic Mitchell

On Mon, Jun 18, 2001 at 04:36:00PM +0100, Greg McCarroll wrote:
 In a moment of stupidity[1] I agreed to write an article for lathos on
 templating solutions for Perl. This was an attempt to finally break my 
 writing block/issues/mindset problems. It is going to be a compare and 
 contrast article and so far I've looked at,
 
   Template Toolkit
   HTML::Mason
   Text::Template 
   HTML::Template
   HTML::Embperl
   
 First, are there any others that I should look at? Also I'd really like
 any objective input people have about templating with these modules. It
 is important to me to try and not just get the article done and dusted,
 but for once to write a piece of text that I am happy with.

Very simple, but what I've done in the past is simply read in a file and
do something like:

$text =~ s/\$(\w+)/$1/eeg;

Which substitutes any perl vars in the file for stuff in your current
program.  Not very pretty, but cheap and easy.

-Dom

-- 
| Semantico: creators of major online resources  |
|   URL: http://www.semantico.com/   |
|   Tel: +44 (1273) 72   |
|   Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |



Re: Templating Solutions

2001-06-18 Thread Leo Lapworth


Greg,

I did this (just for TT2 and HTML::Template) for torrington,
results (REALLY badly formatted *blushes to admit it was done
in word and saved to HTML*) can be seen at:

http://torrington.cuckoo.org/template_systems.shtml

No (c) on it.. so feel free to hack and copy as you will.

Hope it's of some use, obviously it's aimed at a specific
audience, e.g. the Agency and trying to get them to move
from HTML::Template to TT2 (personally I think that's why
they went under - not using TT, but it's just my consipricy theory) 

:)

I'd also like to mention HTML::Mason - Euuu, No, no and thrice no!
(ok, has some nice 'bits' but NO - thou shalt not put thy
HTML and thy Perl in the same file).

Leo

On Mon, Jun 18, 2001 at 04:36:00PM +0100, Greg McCarroll wrote:
 In a moment of stupidity[1] I agreed to write an article for lathos on
 templating solutions for Perl. 




Re: Templating Solutions

2001-06-18 Thread Leon Brocard

Greg McCarroll sent the following bits through the ether:

 In a moment of stupidity[1]

Fool.

There are at least 30 other Perl templating systems. See the
templating systems benchmark last week on the mod_perl list for
example. Perrin Harkins is presenting Choosing a Templating System
at oscon, so you could at least ask him for his list...

Leon

ps speed isn't important
-- 
Leon Brocard.http://www.astray.com/
Iterative Software...http://www.iterative-software.com/

... If I were you, who'd be me?



Re: Templating Solutions

2001-06-18 Thread Robert Price

At 04:36 PM 6/18/01 +0100, Greg wrote:
In a moment of stupidity[1] I agreed to write an article for lathos on
templating solutions for Perl. This was an attempt to finally break my 
writing block/issues/mindset problems. It is going to be a compare and 
contrast article and so far I've looked at,
[list of CPAN templating modules]

I'm sure many of us have written and used home grown templating systems
such a simple regex over a basic template. It may be a good idea to compare
the templating systems available on CPAN to a home grown one. What
advantages they give and what are the disadvantages etc

Rob




Re: Templating Solutions

2001-06-18 Thread Leo Lapworth

Oi, 

Rob,

What's this, 

Home grown (and not smokable), 

I left Emap too early if your not a TT2 convert yet.

We can 'do lunch' later this week and I'll bash you
with some TT2 docs or something :)

Leo

On Mon, Jun 18, 2001 at 04:57:17PM +0100, Robert Price wrote:
 It may be a good idea to compare
 the templating systems available on CPAN to a home grown one. What
 advantages they give and what are the disadvantages etc




Re: Templating Solutions

2001-06-18 Thread Steve Mynott

Greg McCarroll [EMAIL PROTECTED] writes:

   Template Toolkit
   HTML::Mason
   Text::Template 
   HTML::Template
   HTML::Embperl

Also Apache::ASP 

searching for template on CPAN also gets quite a lot of hits...

-- 
1024/D9C69DF9 steve mynott [EMAIL PROTECTED]

travel is fatal to prejudice, bigotry and narrow-mindedness.  -- mark twain 



Re: Templating Solutions

2001-06-18 Thread Jonathan Peterson


I like ePerl, comprised of
Apache::ePerl
Parse::ePerl

It's a very simple does what it says on the tin way of embedding perl in 
any other (text) fine, plus it has low level access to what it does in it's 
parse routine. Handy in many situations, I find.

No new versions since 1998 and none planned, so it's stable. Or dead, 
depending on your viewpoint.


-- 
Jonathan Peterson
Technical Manager, Unified Ltd, +44 (0)20 7383 6092
[EMAIL PROTECTED]




Re: Templating Solutions

2001-06-18 Thread Roger Burton West

On Mon, Jun 18, 2001 at 04:36:00PM +0100, Greg McCarroll wrote:

First, are there any others that I should look at? Also I'd really like
any objective input people have about templating with these modules. It
is important to me to try and not just get the article done and dusted,
but for once to write a piece of text that I am happy with.

Key distinction is: what sort of code is going into the page? Is it 
something fairly basic (H::T, T::T in some ways of using it) or 
something closer to actual perl? (In the latter case, of course, it is 
Evil, because it removes any possibility of separation of code and 
data - you might as well be writing PHP.)

The main reason I prefer H::T to T::T is that H::T templates can be
given to Dreamweaver monkeys to edit without my having to worry that
they'll screw them up.

Roger



Re: Templating Solutions

2001-06-18 Thread Philip Newton

Simon Wilcox wrote:
 I avoided HTML::Embperl, HTML::Mason  Apache::ASP because they all
 embed perl into the template which is a Bad Thing (tm).

Why is that so evil?

I'm willing to be enlightened here.

Cheers,
Philip
-- 
Philip Newton [EMAIL PROTECTED]
All opinions are my own, not my employer's.
If you're not part of the solution, you're part of the precipitate.



Re: Templating Solutions

2001-06-18 Thread Struan Donald

* at 18/06 17:21 +0100 Roger Burton West said:
 On Mon, Jun 18, 2001 at 04:36:00PM +0100, Greg McCarroll wrote:
 
 The main reason I prefer H::T to T::T is that H::T templates can be
 given to Dreamweaver monkeys to edit without my having to worry that
 they'll screw them up.

That is an important consideration although in my experience a
taleneted dreamweaver mokey can screw up pretty much anything that
isn't created by dreamweaver in the first place.

struan



Re: Templating Solutions

2001-06-18 Thread Greg McCarroll

* Philip Newton ([EMAIL PROTECTED]) wrote:
 Simon Wilcox wrote:
  I avoided HTML::Embperl, HTML::Mason  Apache::ASP because they all
  embed perl into the template which is a Bad Thing (tm).
 
 Why is that so evil?
 

i think it one of two schools of thought

is your template a Template or a Rich Template

by Rich Template i mean it has some programming language
type structures such as loops

i think, if i recall my limited research correctly, MJD talks about
this in the pod for Text::Template under the section Philosophy

Greg


-- 
Greg McCarrollhttp://217.34.97.146/~gem/



Re: Templating Solutions

2001-06-18 Thread Matthew Byng-Maddick

On Mon, Jun 18, 2001 at 06:30:24PM +0200, Philip Newton wrote:
 Simon Wilcox wrote:
  I avoided HTML::Embperl, HTML::Mason  Apache::ASP because they all
  embed perl into the template which is a Bad Thing (tm).
 Why is that so evil?
 I'm willing to be enlightened here.

Mainly maintainability. In the same way as it's evil to mix two types of
language - Perl and SQL, although people seem to be a lot more prepared
to do this :-(

The point is that if you are embedding perl, there are too many places
that things can be changed. It is possible to write embedded perl templates
well, but a lot more difficult than if they are separated out.

MBM

-- 
Matthew Byng-Maddick [EMAIL PROTECTED]   http://colondot.net/



Re: Templating Solutions

2001-06-18 Thread Dominic Mitchell

On Mon, Jun 18, 2001 at 05:39:11PM +0100, Matthew Byng-Maddick wrote:
 On Mon, Jun 18, 2001 at 06:30:24PM +0200, Philip Newton wrote:
  Simon Wilcox wrote:
   I avoided HTML::Embperl, HTML::Mason  Apache::ASP because they all
   embed perl into the template which is a Bad Thing (tm).
  Why is that so evil?
  I'm willing to be enlightened here.
 
 Mainly maintainability. In the same way as it's evil to mix two types of
 language - Perl and SQL, although people seem to be a lot more prepared
 to do this :-(
 
 The point is that if you are embedding perl, there are too many places
 that things can be changed. It is possible to write embedded perl templates
 well, but a lot more difficult than if they are separated out.

Most of the Java thingies that I've looked at start talking about MVC at
this point as a good solution to the problem.  But I don't know anything
about that, and I would love somebody to explain it to me in nice
perlisms.

I'd love to have a decent solution to keeping lots of code out of the
HTML files.  At the moment, I'm thinking that it might just be simplest
to move things over to AxKit taglibs...

-Dom

-- 
| Semantico: creators of major online resources  |
|   URL: http://www.semantico.com/   |
|   Tel: +44 (1273) 72   |
|   Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |



Re: Templating Solutions

2001-06-18 Thread Dave Hodgkinson

Leo Lapworth [EMAIL PROTECTED] writes:

 Oi, 
 
 Rob,
 
 What's this, 
 
 Home grown (and not smokable), 
 
 I left Emap too early if your not a TT2 convert yet.
 
 We can 'do lunch' later this week and I'll bash you
 with some TT2 docs or something :)

Oooh! Me too! 

-- 
Dave Hodgkinson, http://www.hodgkinson.org
Editor-in-chief, The Highway Star   http://www.deep-purple.com
  Interim CTO, web server farms, technical strategy
   



Re: Templating Solutions

2001-06-18 Thread Roger Burton West

On Mon, Jun 18, 2001 at 06:30:24PM +0200, Philip Newton wrote:
Simon Wilcox wrote:
 I avoided HTML::Embperl, HTML::Mason  Apache::ASP because they all
 embed perl into the template which is a Bad Thing (tm).

Why is that so evil?

I'm willing to be enlightened here.

Separation of code and data - or in this case, layout, content
and logic. You can have multiple template files (say, for HTML,
WAP, I-mode, and whatnot) while keeping a single, fairly simple
program as the back-end (which doesn't need to know what sort of
platform it's filling in a template for, just which template file
to load).

Roger



Re: Templating Solutions

2001-06-18 Thread Simon Wilcox

Philip Newton wrote:
 
 Simon Wilcox wrote:
  I avoided HTML::Embperl, HTML::Mason  Apache::ASP because they all
  embed perl into the template which is a Bad Thing (tm).
 
 Why is that so evil?
 
 I'm willing to be enlightened here.
 

A couple of reasons.

Separation of code  presentation is good because it means that your
designers can concentrate on the design  html whilst your programmers
concentrate on function.

It helps if those not familiar with perl don't have to worry about it.
They get a domain specific language that is easy to understand (TT2
scores well here because it hides the differences between scalars,
arrays, hashes and object methods), and hopefully difficult for them to
break.

See this thread for Andy's take on this.

http://www.template-toolkit.org/pipermail/templates/2001-June/001076.html

Secondly, it helps with maintenance  reusability if all your perl code
is in one place, there's less to change and less chance of thiongs going
wrong.

This really helps when the PHBs come along and ask if you can redesign
the pages for a particular client.

Whilst this can be done if you've mixed up perl into your template it
makes it much harder because there is a lot more for the designers to
break (and let's not even mention asp/php/jsp :)

Now I accept that if you are the sole programmer/developer/designer on a
project then it maybe doesn't matter but I have found that it helps me
to work in a separated way, so when they say, as they have, ah, we need
the first two years in this table and the rest in that one it becomes a
presentation issue and not a perl coding issue [1].

HTH,

Simon.

[1] It was really easy to do in a TT2 template as well !



Re: Templating Solutions

2001-06-18 Thread David Cantrell

On Mon, Jun 18, 2001 at 04:46:25PM +0100, Leo Lapworth wrote:

 I'd also like to mention HTML::Mason - Euuu, No, no and thrice no!
 (ok, has some nice 'bits' but NO - thou shalt not put thy
 HTML and thy Perl in the same file).

It is NOT POSSIBLE to completely divorce presentation/application.
So you end up with all sorts of languages made up to be mixed in with
the presentation - like PHP and the mini-language of TT.  Why are
those OK (I'm thinking specifically of TT - we all know PHP sucks for
other reasons) but plain ol' perl isn't?

-- 
David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david/

  Good advice is always certain to be ignored,
  but that's no reason not to give it-- Agatha Christie



Re: Templating Solutions

2001-06-18 Thread Richard Clamp

On Mon, Jun 18, 2001 at 07:54:36PM +0100, David Cantrell wrote:
 It is NOT POSSIBLE to completely divorce presentation/application.

You're missing a word from the end of the sentence, and that's Ilogic.
If you add it you're obviously wrong though...

 So you end up with all sorts of languages made up to be mixed in with
 the presentation - like PHP and the mini-language of TT.  Why are
 those OK (I'm thinking specifically of TT - we all know PHP sucks for
 other reasons) but plain ol' perl isn't?

TT's toy language is a presentation language, not a programming one.
It's different enough so that you can't easily put too much
programming logic into it, IME at least.

-- 
Richard Clamp [EMAIL PROTECTED]
so we've got a deadline.
 we can do deadlines.



Re: Templating Solutions

2001-06-18 Thread Jonathan Stowe

On 18 Jun 2001, Steve Mynott wrote:

 Greg McCarroll [EMAIL PROTECTED] writes:

  Template Toolkit
  HTML::Mason
  Text::Template
  HTML::Template
  HTML::Embperl

 Also Apache::ASP


I did have this crackhead idea a week or two ago about making something
that 'Compiled' HTML to modules with something like a DOM interface (much
like the thing with Enhydra does ) - this of course would not really be
Templating but something more like manipulating the HTML directly through
method calls ...

I wont bore you with the code as its not at all finished.

/J\




Re: Templating Solutions

2001-06-18 Thread Jonathan Stowe

On Mon, 18 Jun 2001, Roger Burton West wrote:

 On Mon, Jun 18, 2001 at 06:30:24PM +0200, Philip Newton wrote:
 Simon Wilcox wrote:
  I avoided HTML::Embperl, HTML::Mason  Apache::ASP because they all
  embed perl into the template which is a Bad Thing (tm).
 
 Why is that so evil?
 
 I'm willing to be enlightened here.

 Separation of code and data - or in this case, layout, content
 and logic.

As a reference for this kind of thing one might ( if one can be arsed to
look at Java stuff ) to look at the way the Enhydra thingy does things in
creating classes in directories like :

 business  data  presentation  resources

/J\




Re: Templating Solutions

2001-06-18 Thread Matthew Byng-Maddick

On Mon, Jun 18, 2001 at 07:54:36PM +0100, David Cantrell wrote:
 On Mon, Jun 18, 2001 at 04:46:25PM +0100, Leo Lapworth wrote:
  I'd also like to mention HTML::Mason - Euuu, No, no and thrice no!
  (ok, has some nice 'bits' but NO - thou shalt not put thy
  HTML and thy Perl in the same file).
 It is NOT POSSIBLE to completely divorce presentation/application.
 So you end up with all sorts of languages made up to be mixed in with
 the presentation - like PHP and the mini-language of TT.  Why are
 those OK (I'm thinking specifically of TT - we all know PHP sucks for
 other reasons) but plain ol' perl isn't?

Ohmigod, I'm agreeing with Cantrell on something!!

Despite having written an embedded perl templating system, I'm now very
much in favour of one where the tags are just delimiters as far as possible.
Thus I think things like HTML::Template are actually better than TT2,
precisely because the toy language in TT2 is just as bad as embedding code.

See my point about SQL, as it's related to this.

MBM

-- 
Matthew Byng-Maddick [EMAIL PROTECTED]   http://colondot.net/



Re: Templating Solutions

2001-06-18 Thread David Cantrell

On Mon, Jun 18, 2001 at 08:24:13PM +0100, Matthew Byng-Maddick wrote:
 On Mon, Jun 18, 2001 at 07:54:36PM +0100, David Cantrell wrote:
  On Mon, Jun 18, 2001 at 04:46:25PM +0100, Leo Lapworth wrote:
   I'd also like to mention HTML::Mason - Euuu, No, no and thrice no!
   (ok, has some nice 'bits' but NO - thou shalt not put thy
   HTML and thy Perl in the same file).
  It is NOT POSSIBLE to completely divorce presentation/application.
  So you end up with all sorts of languages made up to be mixed in with
  the presentation - like PHP and the mini-language of TT.  Why are
  those OK (I'm thinking specifically of TT - we all know PHP sucks for
  other reasons) but plain ol' perl isn't?
 
 Ohmigod, I'm agreeing with Cantrell on something!!

What am I doing wrong? ;-)

Seriously, I agree 100% that you should strive to seperate application
from your presentation as much as possible, but seeing that you can not
do this entirely, you may as well embed perl in your HTML and save
yourself the trouble of inventing a whole new wheel.

You can still stick your business logic elsewhere and have that called
by the perl embedded in the templates.

 Despite having written an embedded perl templating system, I'm now very
 much in favour of one where the tags are just delimiters as far as possible.
 Thus I think things like HTML::Template are actually better than TT2,
 precisely because the toy language in TT2 is just as bad as embedding code.
 
 See my point about SQL, as it's related to this.

Think of SQL as being a cross-language extension to the 'host' language
and you'll feel much better about it :-)

-- 
David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david/

  Good advice is always certain to be ignored,
  but that's no reason not to give it-- Agatha Christie



Re: Templating Solutions

2001-06-18 Thread Philip Newton

Matthew Byng-Maddick wrote:
 It is possible to write embedded perl templates well, but a
 lot more difficult than if they are separated out.

How does non-embedded Perl look like, then?

Is Perl the outside layer and basically does '#include navbar.html' at
certain points?

Or is HTML the outside layer and does something like % require
read-database.pl; read; %?

Or what does it look like if they're *not* in the same file?

I have next to no experience with separated code and data (yes, my SQL
statements are also in my Perl source files); I've written toy CGI scripts
(HTML embedded in Perl) and my day job at the moment includes StoryServer
(Tcl embedded in HTML), so I don't think I have much idea of how something
else would work.

Explanations welcome.

Cheers,
Philip
-- 
Philip Newton [EMAIL PROTECTED]
All opinions are my own, not my employer's.
If you're not part of the solution, you're part of the precipitate.