Re: Templating Solutions
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 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
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: Technical Meeting - 21st June
On Mon, Jun 18, 2001 at 07:15:32PM +0100, Dave Cross wrote: > Oh... er... it's only three days to the technical meeting and so far I don't > seem to have any talks for it. Thursday.. what, this thursday where does the time go. Assuming I can make it (have to check something), I'll give a little update on the new web site. If you are really desperate I can talk through my XML -> DB schema and docs thingy, but it's not ready for release so only if people are interested. - Both short talks. Leo
Re: Templating Solutions
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
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: Technical Meeting - 21st June
Leo Lapworth <[EMAIL PROTECTED]> writes: > On Mon, Jun 18, 2001 at 07:15:32PM +0100, Dave Cross wrote: > > Oh... er... it's only three days to the technical meeting and so far I don't > > seem to have any talks for it. > > Thursday.. what, this thursday where does the time go. > > Assuming I can make it (have to check something), I'll give a little > update on the new web site. Bugger. I definitely can't make it. -- Piers Cawley www.iterative-software.com
Re: Templating Solutions
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
The List Has Moved
In case anybody hasn't noticed, [EMAIL PROTECTED] has now become [EMAIL PROTECTED] Your mail filters may need updating, you've probably got a ton of junk in your inbox in case you haven't noticed. :-) -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
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
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
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.
Using perl for a high performance mailer daemon ?
Dear All Sorry to drag the tone back down to perl, but, I've a question that is ripe for the lists collective expertise. I want to design a mailer for sending large numbers of individual messages to a large list. This is for a client whom manages companies customers CRM lists. This is more of a prototype / proof of concept, and as such I thought perl would be the best. We are already using qmail, but the expense of queuing a message mean that performance is limited by disc speed and qmail-send the program that manages the queue and sending outbound emails. Hence I want to write is a thing that: a) Looks up and caches MX records in a shared area (shared mem) - easy. b) Load the message template into shared mem - easy. c) Gets message from shared mem, and given a list uses qmail-remote to actual do the smtp conversation (by reading info on different filehandles), if the initial send fails drop back to an smtp relay that will queue the message or bounce it somewhere else. Could this done even quicker with a perl client that does simple checks ? d) Log to a central file - success for failure. I just know there must be a way to do this in perl that is quick (rather than writing it in C). So whats the way the write this so that its execution speed is the fastest (given enougth memory and network bandwidth). Part C is the sticker, i.e. the quickest way to spawn and control alot of other process that communicate over filehandles. Clues on a postcard, ta. Greg
Re: Templating Solutions
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: Technical Meeting - 21st June
> Oh... er... it's only three days to the technical meeting and so far I don't > seem to have any talks for it. Err, I have to produce 3 hours of material so I don't think that the technical meeting would be the right place for it. Apart from that it isn't finished yet. If there is another technical meeting before YAPC::Europe I will do 30 mins worth of material or 3 hours abridged (sort of like campbels condensed soup). Its been a few years since I did this kinda thing so I will be in need of constructive critisism. Red
Re: Templating Solutions
More on XML/XSLT/seperation of roles philosophy http://xml.apache.org/cocoon2/index.html paul Ian Brayshaw wrote: > > > > 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
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
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: Using perl for a high performance mailer daemon ?
Greg Cope sent the following bits through the ether: > I want to design a mailer for sending large numbers of individual > messages to a large list. You're writing a mailer in Perl. Mailers have been done before. If you're using a slow one, then look at other ones, such as exim. Leon -- Leon Brocard.http://www.astray.com/ Iterative Software...http://www.iterative-software.com/ ... S met ing's hap ening t my k ybo rd . .
Re: Using perl for a high performance mailer daemon ?
On Tue, Jun 19, 2001 at 11:39:32AM +0100, Leon Brocard wrote: > Greg Cope sent the following bits through the ether: > > I want to design a mailer for sending large numbers of individual > > messages to a large list. > > You're writing a mailer in Perl. Mailers have been done before. If > you're using a slow one, then look at other ones, such as exim. The trouble is that practically all mailers will write the queue file to disk before they do *anything* else, for safety reasons. If I understood the initial message correctly, this is his problem. I think that qmail, exim and postfix all fall into this category. I have a feeling that it can be turned off in sendmail, but you'd need to check. -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: Using perl for a high performance mailer daemon ?
On Tue, 19 Jun 2001, Philip Newton wrote: > Greg Cope wrote: > > Sorry to drag the tone back down to perl > > You could at least have done it on the proper list (you know, the one that > Jonathan Stowe said he wouldn't be closing down this afternoon). > > CC'ed to the real list. > I fixed the reply address on lists.dircon.co.uk so it shouldnt matter :) /J\
Re: Using perl for a high performance mailer daemon ?
Greg Cope wrote: > Sorry to drag the tone back down to perl You could at least have done it on the proper list (you know, the one that Jonathan Stowe said he wouldn't be closing down this afternoon). CC'ed to the real list. 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
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
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
[ANNOUNCE] Getopt::Attribute 0.02
NAME
Getopt::Attribute - Attribute wrapper for Getopt::Long
SYNOPSIS
use Getopt::Attribute;
my $verbose : Getopt(verbose!);
my $all : Getopt(all);
my $size: Getopt(size=s);
my $more: Getopt(more+);
my @library : Getopt(library=s);
my %defines : Getopt(define=s);
sub quiet : Getopt(quiet) { our $quiet_msg = 'seen quiet' }
usage() if my $man : Getopt(man);
...
# Meanwhile, on some command line:
mypgm.pl --noverbose --all --size=23 --more --more --more --quiet
--library lib/stdlib --library lib/extlib
--define os=linux --define vendor=redhat --man -- foo
DESCRIPTION
This module provides an attribute wrapper around `Getopt::Long'. Instead
of declaring the options in a hash with references to the variables and
subroutines affected by the options, you can use the `Getopt' attribute
on the variables and subroutines directly.
As you can see from the Synopsis, the attribute takes an argument of the
same format as you would give as the hash key for `Getopt::Long'. See
the `Getopt::Long' manpage for details.
Note that since attributes are processed during CHECK, but assignments
on newly declared variables are processed during run-time, you can't set
defaults on those variables beforehand, like this:
my $verbose : Getopt(verbose!) = 1; # DOES NOT WORK
Instead, you have to establish defaults afterwards, like so:
my $verbose : Getopt(verbose!);
$verbose ||= 1;
BUGS
None known so far. If you find any bugs or oddities, please do inform
the author.
AUTHOR
Marcel Grunauer, <[EMAIL PROTECTED]>
COPYRIGHT
Copyright 2001 Marcel Grunauer. All rights reserved.
This library is free software; you can redistribute it and/or modify it
under the same terms as Perl itself.
SEE ALSO
perl(1), Getopt::Long(3pm), Attribute::Handlers(3pm).
Marcel
--
We are Perl. Your table will be assimilated. Your waiter will adapt to
service us. Surrender your beer. Resistance is futile.
-- London.pm strategy aka "embrace and extend" aka "mark and sweep"
