Re: [OT] About XML and Petal (was Re: templating system opinions(axkit?))

2003-07-28 Thread Chris Devers
On Mon, 28 Jul 2003, Aleksandr Guidrevitch wrote:

 May be I'm a bit late here... But is there any sence in artifical XML
 templating languages since there is XSLT ? Just wonder whether there are
 cons other than long learning curve and performance issues ?

Well, in the case of just TAL/Petal, the point as far as I know isn't so
much that it happens to be valid XML -- though of course that's a welcome
design aspect -- but that it's easy to use in W3C compliant HTML without
masking the interesting bits inside HTML comment blocks.

I can't think of an example now (and apologize for only having had time to
skim much of this long, spiralling thread so far), but I seem to remember
that TAL's syntax allowed for these clever little inside out loop
structures that, among other things, ensures that the unrolled version of
the loop still has proper indentation etc. Unessential maybe, but a nice
touch.


I don't know nearly enough about XSLT to comment on it in depth, but my
impression is that TAL generally derives from the same heritage as all the
assorted Perl template languages, etc, rather than ...well I guess I don't
really know where XSLT derives from (Docbook?), but it seems more like
CSS: a separate document describing how to display one or more other
structured documents.

The difference in the case of TAL / TT / H::T / Mason / etc is that the
template is used to provide that structure itself, assembling it out of
code that is maybe extracting content from a database or calculating it on
the fly something.

My hunch is that the way to work XSLT into the mix -- if it has a place at
all -- is to have your logic (scripts with H::T, code sprinkled in Mason
templates, TT applied where clever TT people apply it)  fleshing out the
framework defined in a template (the H::T template, the non-code part of a
Mason template, the plaintext part of a TT template) as well formed XML,
and then using XSLT to format that intermediate form for display. This
probably makes sense in cases where that intermediate form can be cached
(pages for web or print that change once a day, say), but for truly
dynamic documents the XSLT stage is probably way too much overhead.


Is XSLT appropriate for applying both structure  styling to the free-
form output of a [Perl] program? Does it take a lot of overhead? Would
this overhead happen on the server end (glue XML + XSLT into an HTML
document that goes out over the wire), or on the client end (download XML,
then grab XSLT by reference (like HTML grabs CSS), and then the client
merges them)? If the client does the work, how widespread is support? If
the server does the work, what should the throughput be like?

My hunch -- which I'd be happy to be corrected about -- is that this can't
be any easier than just working directly from traditional template kits,
as has been discussed at remarkable length in this thread :)



-- 
Chris Devers[EMAIL PROTECTED]http://devers.homeip.net:8080/resume/
sorry for helping along in this thread 10 days  dozens of messages ago :)


Re: templating system opinions

2003-07-18 Thread Chris Devers
On Fri, 18 Jul 2003, Patrick Galbraith wrote:

 Just wondering what the best templating system is to use and/or learn.

 I've briefly read up on the pros and cons of each, and am just wondering
 which one is the most widely _used_ and best to learn if you're wanting to
 know something that there are jobs for.

What's best depends on what your requirements are. As far as I can tell,
the big ones are Template::Toolkit, Mason, and HTML::Template; each one
makes different tradeoffs and makes different assumptions about the
division of labor among programmers, web developers,  content producers.
TT is probably the most flexible, but that or might not be what you want.

Honestly, of the three I just listed, none of them are *that* complicated.
If you want to learn these for job hunting purposes -- in which case it's
not really fair to ask you what the requirements are, since you can't
really know that -- you might as well experiment with all three.

A good way to start might be by playing with different content management
etc platforms that use these toolkits. From what I've read, the biggest
examples I can think of are:

 * Slashcode (TT based, runs slashdot.org)

 * Bricolage (H::T, http://www.bricolage.cc/docs/Bric/HTMLTemplate.html,
   CMS used by theregister.co.uk et al)

 * Request Tracker (excellent ticketing system, runs http://rt.cpan.org/,
   home page is http://www.bestpractical.com/rt)

Any of these can be downloaded  used freely. If you have the time for it,
grab a copy of one or more and start playing around.

Have fun :)


-- 
Chris Devers [EMAIL PROTECTED]
http://devers.homeip.net:8080/

drag'n'drop, v.
To throw away your mouse after the first attempt to copy a file leads
to its deletion. See also TRASH CAN.

-- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995


Re: templating system opinions - Mason recommendation

2003-07-18 Thread Chris Devers
Sorry to cc: this to the list, but I stand corrected and might as well
mention that to the list :)


On Fri, 18 Jul 2003, Dave Baker wrote:

 Correction: Bricolage is written in Mason, I believe. That's what the
 Bricolage authors say at http://bricolage.cc/

Hmm, so it does. I wonder where I got the idea that it was H::T based...

 I'm very pleased with Mason -- the online O'Reilly book about Mason is
 at http://www.masonbook.com/book/

A little bird tells me that TT is about to get an O'Reilly book as well,
though it's not on their upcoming titles page (yet).

The only H::T dead-trees material that I know of is a section in _CGI
Programming with Perl_, 2nd edition -- that's where I learned it. I like
the simplicity of H::T, but most other people seem to prefer TT or Mason.
I still think it comes down to whichever system meets your needs the best,
and in different contexts any of them (or others) could be appropriate.


This may have been covered before here, but Zope supports an interesting
template mechanism called TAL, where everything is done by attributes for
the HTML tags, rather than special logical tags as most other systems use
(e.g. the ones mentioned above, SSI, PHP, ASP, JSP, etc). This has the
nice side effect of guaranteeing that all your html templates are always
valid, and so can be used in any html IDE without complication. So for
example, picking a random sample from the spec:


Repeat

  Syntax:
   argument  ::= variable_name expression
   variable_name ::= Name

  When you want to replicate a subtree of your document once for each
  item in a sequence, you use repeat.  The expression should evaluate
  to a sequence. If the sequence is empty, then the statement element
  is deleted, otherwise it is repeated for each value in the sequence.
  If the action is cancelled, then the element is left unchanged, and
  no new variables are defined.

  The variable_name is used to define a local variable and a repeat
  variable. For each repetition, the local variable is set to the
  current sequence element, and the repeat variable is set to an
  iteration object.  You use iteration objects to access information
  about the current repetition (such as the repeat index).
  (Iteration objects are more properly the domain of TALES.)  The
  repeat variable has the same name as the local variable, but is
  only accessible through the builtin variable named repeat (see
  RepeatVariable).

  Examples:

p tal:repeat=txt python:'one', 'two', 'three'
   span tal:replace=txt /
/p
table
  tr tal:repeat=item here/cart
  td tal:content=repeat/item/index1/td
  td tal:content=item/descriptionWidget/td
  td tal:content=item/price$1.50/td
  /tr
/table


It's a pretty clever approach; I'd like to see something like this done
with a Perl backend (I haven't really been keeping track of development,
for all I know there already is a Perl backend...). Read more:

  http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL
  http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL%20Specification%201.4


But anyway, Zope isn't mod_perl, so that's probably not what the original
person was hoping to read about... :)



-- 
Chris Devers[EMAIL PROTECTED]


Re: templating system opinions

2003-07-18 Thread Chris Devers
On Fri, 18 Jul 2003, Patrick Galbraith wrote:

 Yeah, I worked with TT when I was on the Slash team ;)

Then why are you asking a question like this?? :)


-- 
Chris Devers [EMAIL PROTECTED]
http://devers.homeip.net:8080/

Turing machine, n. [After Alan M. Turing (1912-1954), British
  mathematician and computer pioneer.]
The earliest but still the fastest and most reliable computing system
ever conceived. Dis maschine vill run und run (K. Godel).

-- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995


Re: --help

2003-07-09 Thread Chris Devers
On Wed, 9 Jul 2003, Alexander Prihodko wrote:

 --help

Usage:  [EMAIL PROTECTED] [-s topic] PROBLEM [DETAILS]
Describe a PROBLEM, giving DETAILS, so that the members of
the list can try to assist you.

Example:
Date: Wed, 01 Jan 1970 00:00:00 +
From: D Ritchie [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: won't build on new lab system

Your ^*$*$ software won't compile on this PDP-11. I keep
getting the error cowardly refusing to create an empty
archive. What is *that* supposed to mean?

Here's the full error dump: snipped

And here's the software  hardware I'm running: snipped

Options:
  -p --post: [EMAIL PROTECTED]
  -S --subscribe   : [EMAIL PROTECTED]
  -u --unsubscribe : [EMAIL PROTECTED]
  -h --help: [EMAIL PROTECTED]


Please, try again :)



-- 
Chris Devers [EMAIL PROTECTED]
http://devers.homeip.net:8080/

reusability, n.
A marketing priority overriding that of usability.
See also OBJECT ORIENTEETING.

-- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995


Re: errors installing libapreq [RESOLVED]

2003-06-26 Thread Chris Devers
Well, I rebuilt Apache/mod_perl, and it seemed to work. For those that
hit the same error, the fix -- which I've saved as a script for future
reference :) -- is as follows:

* Install Apache/mod_perl:

#!/bin/sh
# chd.build.apachemodperl.sh

perl=/sw/bin/perl
modperldir=/usr/src/mod_perl-1.27
apachedir=/usr/src/apache_1.3.27
builddir=/usr/local/apache

pushd $modperldir

$perl Makefile.PL \
APACHE_SRC=../apache_1.3.xx/src \
APACHE_PREFIX=${builddir} \
APACHE_USER=www \
APACHE_GROUP=www \
DO_HTTPD=1 \
USE_APACI=1 \
EVERYTHING=1 \
APACI_ARGS='--sbindir=${builddir}/sbin, \
--sysconfdir=${builddir}/etc, \
--localstatedir=${builddir}/var, \
--runtimedir=${builddir}/var/run, \
--logfiledir=${builddir}/var/logs, \
--proxycachedir=${builddir}/var/proxy, \
--enable-module=so'
make
make test
sudo make install

pushd $apachedir
sudo make install

echo Verifying that the build worked:
${builddir}/sbin/apachectl configtest  \
  echo congratulations, you may now reset apache by running  \
  echo ${builddir}/sbin/apachectl start


* Installation may disrupt Perl modules. I had to rebuild Apache::Test

% sudo /sw/bin/perl -MCPAN -e shell
cpan install Apache::Test


* Install libapreq:

% perl Makefile.PL \
 -httpd /usr/local/apache/sbin/httpd \
 -apxs  /usr/local/apache/sbin/apxs
% make
% make test
% make install


Everything went smoothly up to the `perl Makefile.PL [...]` step, where I
got this error:

skipping test setup...Undefined subroutine Apache::Test::config called at 
/sw/lib/perl5/site_perl/5.8.0/darwin/Apache/TestMM.pm line 90.
Warning: prerequisite Apache::Test 1.03 not found. We have unknown version.

And, as I say, rebuilding Apache::Test in the CPAN shell took care of
that. Others may hit different problems that could be fixed similarly.

All better now :)



-- 
Chris Devers[EMAIL PROTECTED]

channeler, n.
Also SPIRIT GUIDE. Politically correct terms for DAEMON.

-- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995


Re: [VERY OT] What hourly rate to charge for programming?

2001-10-11 Thread Chris Devers

On Thu, 11 Oct 2001 [EMAIL PROTECTED] wrote:

 To: Gunther Birznieks [EMAIL PROTECTED],
 
  Still, the beer sucks in both ;-)
 
 That's because it's stale piss, I'm sure the beer glasses are pissed
 in to save money ;-) Heck, the beer is so bad nobody can possibly tell
 the difference anyway.

Ahh, you have Budweiser in Australia too, then? ;) 
 

--
Chris Devers [EMAIL PROTECTED]
Apache / mod_perl  http://bunny.skillcheck.com/admin/chris/resume/




Re: FW: Apache_1.3.19/mod_perl-1.24_01/perl5.6.1 on Solaris 2.6/SunO S 5.6

2001-10-03 Thread Chris Devers

On Wed, 3 Oct 2001, Ged Haywood wrote:

 Hi there,
 
 On Tue, 2 Oct 2001, Yeo Puay Hoon wrote:
 
  steps suggested in the apache readme file:  
  # gunzip apache_1.3.19.tar.gz
  # tar -xvf apache_1.3.19.tar 
  # gunzip mod_perl-1.24_01.tar.gz 
  # tar -xvf mod_perl-1.24.01.tar   
  # cd mod_perl-1.24_01  
  # perl Makefile.PL \
 [snip]
 
 Don't install and compile as root, it can cause troubles.
 Only use the root account to make install.
 
Better still, if your system is set up for it, do something like:

 $ tar -xvzf apache_1.3.19.tar.gz# the -z flag decompresses for you
 $ tar -xvzf mod_perl-1.24_01.tar.gz
 $ cd mod_perl-1.24_01
 $ perl Makefile.PL  make  make test  sudo make install
   # if each step is successful, it succeeds automagically,
   # otherwise it fails. also more importantly, it wraps
   # 'make install' in a sudo call, so the work gets logged
   # and you only get to do that one command as root. if
   # your system supports it, sudo is often safer than su.



-- 
Chris Devers [EMAIL PROTECTED]




Re: What hapened to AxKit.com?

2001-10-03 Thread Chris Devers

On Wed, 3 Oct 2001, Perl Man wrote:

 At 02:42 PM 10/3/2001 -0700, you wrote:

 Does anyone have factual information about the
 AxKit website?

 Here's what I got after trying to join their email list:
 
 After 10 days (232 hours), your message could not be 
 fully delivered.
 It failed to be received by the following address(es):
 [EMAIL PROTECTED] (host: sergeant.org) (queue: network)
 Problems usually are due to service interruptions at the receiving 
 machine. Less often, they are caused by the communication system.
 Your message follows:

I tried to get to sergeant.org today and it was inaccessible too. 

/yet another datapoint
 


-- 
Chris Devers [EMAIL PROTECTED]




HTML::Template initialization bug (sorta)

2001-10-01 Thread Chris Devers

I've just resolved a bug I was getting with parameter parsing, and was
told that I should pass it along to the mod_perl list (which I'd been
meaning to subscribe to anyway, so hey). 

I'd been having problems getting CGI.pm to properly parse out script
parameters for various pages that had been working just fine before.
Further investigation showed that a simple script with just a call to
CGI.pm's Dump() method would return parameters that were clearly not part
of the argument portion of the url, and it wasn't grabbing the ones that
were there. Hitting reload would trigger more or less random results --
sometimes it would get the right parameters  return the correct page
contents, other times it would mangle the parameters but, generally, it
would display an incorrect but valid page (i.e. ask for foo?p=bar and get
back foo?p=blat). 

Turns out that a call to 'use HTML::Template' that I'd placed into my
startup.pl script was causing all the errors. Commenting it out and
restarting the server seems -- so far -- to have removed the problem. 

*and there was much rejoicing*

So, if any of you are using H::T, be aware that it doesn't seem to like
being called from your startup.pl scripts. If you're getting weird, semi
random errors across more or less your whole site, this or something like
it could be to blame. 

*yech*

So anyway, yeah. I don't usually join a list  post straight off, so...

goes into lurk mode /


-- 
Chris Devers [EMAIL PROTECTED]