Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Matt Sergeant

On Mon, 4 Sep 2000, Marc D. Spencer wrote:

>o There are actually 3 groups involved, and separation of function
>  as much as possible allows the three groups to work independently on
>  a project without requiring concurrent editing of the same file.
> 
>  - HTML coders
>  - Behavior (the perl or java code)
>  - Resources (pulling in images or other referenced objects)
> 
>  With the templating options discussed so far, you tie the HTML
>  coders and the perl/java coders to editing the same file. Separation
>  of these two is really key, according to those I asked. The Project
>  Managers like the separation too.

I don't think thats the case at all here. We've discussed several
solutions, none of which tie the programmer into editing the template
file. Thats the whole point of these discussions...

>o Don't forget localization. None of the existing products that we were
>  able to look at handled localization of templates. Localization must
>  be handled by HTTP accept headers and/or manual overriding.

This is handled by Apache - what more needs to be done (I'm not being
facetious (sp?) - I'd really like to get more and better answers to this
question)?

>o Virtual hosts are real, and template reuse, especially across VHs,
>  while allowing for VH specific customization (driven by the perl/java
>  or configuration) is a nicety.

Do you mean like www.pdamd.com and www.pdare.com ?

-- 


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: internal_redirect

2000-09-04 Thread Rob Tanner



--On 09/05/00 01:23:04 -0500 Ken Williams <[EMAIL PROTECTED]> 
wrote:

> [EMAIL PROTECTED] (Differentiated Software Solutions Pvt. Ltd) wrote:
>> Hi,
>>
>>The following code is not working.
>>
>> use Apache;
>>
>> Apache->Request->internal_redirect('http://192.168.1.2/smg/html/adce
>> pt_logo.gif');
>>
>> The error is:
>>
>> Can't locate object method "Request" via package "Apache" at
>> ./test.cgi line 5.
>
> It's a lowercase 'r'.   Apache->request->...

That's only half the problem.  Internal redirects are just that.  They 
don't include http://server-name.  They are always internal to the 
server immediate server.

Apache->request->internal_redirect('/smg/html/adcept_logo.gif'); is 
correct form.  But if 192.168.1.2 isn't this server, than a full 
redirect is required.

-- Rob

   _ _ _ _   __ _ _ _ _
  /\_\_\_\_\/\_\ /\_\_\_\_\_\
 /\/_/_/_/_/   /\/_/ \/_/_/_/_/_/  QUIDQUID LATINE DICTUM SIT,
/\/_/__\/_/ __/\/_//\/_/  PROFUNDUM VIDITUR
   /\/_/_/_/_/ /\_\  /\/_//\/_/
  /\/_/ \/_/  /\/_/_/\/_//\/_/ (Whatever is said in Latin
  \/_/  \/_/  \/_/_/_/_/ \/_/  appears profound)

  Rob Tanner
  McMinnville, Oregon
  [EMAIL PROTECTED]



Re: Can't locate object method "No" via package "such"

2000-09-04 Thread Billy Donahue

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 5 Sep 2000, Ken Williams wrote:

> This is pretty funny.  Somehow an error message "No such
> something-or-other" is being interpreted as Perl code.  I don't know why
> it thinks the file is /dev/null, but I'd grep for "No such" in your code
> and see where that error message might be issued/misinterpreted.

Failing that, see if $! is being abused.  $! would contain the text "No such file or 
directory"
after a failed open attempt, for example.

- --
"The Funk, the whole Funk, and nothing but the Funk."
Billy Donahue 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/

iD8DBQE5tJNP+2VvpwIZdF0RAnGTAKCGhjjA/o/o9W6srWXtvQHb4USvgQCaAmc9
PENIbPNX2M05DLbLA7jvYVw=
=OW+v
-END PGP SIGNATURE-




Re: Can't locate object method "No" via package "such"

2000-09-04 Thread Ken Williams

[EMAIL PROTECTED] (Alan E. Derhaag) wrote:
>I upgraded to openssl-0.9.5a and recompiled apache w/mod_ssl and
>mod_perl defining the SSL_BASE to the apache src and now the thing
>won't start and complains about:
>
> Can't locate object method "No" via package "such" at /dev/null line 1.
>
>The compile had no warnings or errors except a `assignment discards
>`const' from pointer target type' warning.
>
>I've grepped the source for all (including openssl) and find nothing
>that might emit this error.
>
>Can I get a recommendation of where to look next?

This is pretty funny.  Somehow an error message "No such
something-or-other" is being interpreted as Perl code.  I don't know why
it thinks the file is /dev/null, but I'd grep for "No such" in your code
and see where that error message might be issued/misinterpreted.


  ------
  Ken Williams Last Bastion of Euclidity
  [EMAIL PROTECTED]The Math Forum





Re: internal_redirect

2000-09-04 Thread Ken Williams

[EMAIL PROTECTED] (Differentiated Software Solutions Pvt. Ltd) wrote:
>Hi,
>
>The following code is not working.
>
>use Apache;
>
>Apache->Request->internal_redirect('http://192.168.1.2/smg/html/adcept_logo.gif');
>
>The error is:
>
>Can't locate object method "Request" via package "Apache" at ./test.cgi
>line 5.

It's a lowercase 'r'.   Apache->request->...


  ------
  Ken Williams Last Bastion of Euclidity
  [EMAIL PROTECTED]The Math Forum





Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Perrin Harkins

Sam Tregar wrote:
> 
> On Mon, 4 Sep 2000, Perrin Harkins wrote:
> 
> > Embedded perl is absolutely the best answer sometimes, but don't
> > underestmate the value of turning your example into this:
> >
> > [% FOREACH thing = list %]
> >   [% thing.name %]
> > [% END %]
> 
> That isn't really much better, in my opinion.  It's still too much of a
> departure from the HTML around it.  Contrast the above to HTML::Template's
> looping:
> 
>   
>  
>   
> 
> With a little education an HTML designer can learn to manipulate the
> template syntax.  You'll have to teach them to program before they can
> deal with a full "foreach" no matter how you dress it up.

I happened to use the default syntax of Template Toolkit as an example,
although that can also be simplified like this:

[% FOREACH list %]
  [% name %]
[% END %]

My point though was just that taglib-based systems like Template Toolkit
and HTML::Template can be easier for some people to work with.

- Perrin



Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Perrin Harkins

brian moseley wrote:
> 
> On Mon, 4 Sep 2000, Perrin Harkins wrote:
> 
> > [% FOREACH thing = list %]
> >   [% thing.name %]
> > [% END %]
> 
> what's the value?

It's easier for some people to understand and write without help from an
engineer.

> you have to write a parser and then
> interpret the instructions.

You always have to do that, since templates with perl code in them are
not valid perl and have to be translated.  The taglib-based systems I'm
familiar with use some kind of parser to read the template and generate
valid perl which is then eval'ed.  That's exactly what Mason does too,
and Mason's parser is not trivial.

> your syntax is no prettier or easier to understand than the
> perl.

That's debatable.  The designers where I work preferred it.

Anyway, this is not a one-size-fits-all issue, and there are good
systems available that use both techniques.  I'm writing an essay about
this issue for the new template guide Drew and I are working on, and
I'll try to summarize all the arguments on both sides.  Please read
through it when we release it and let me know if there's anything I've
missed.

- Perrin



Can't locate object method "No" via package "such"

2000-09-04 Thread Alan E. Derhaag

I upgraded to openssl-0.9.5a and recompiled apache w/mod_ssl and
mod_perl defining the SSL_BASE to the apache src and now the thing
won't start and complains about:

 Can't locate object method "No" via package "such" at /dev/null line 1.

The compile had no warnings or errors except a `assignment discards
`const' from pointer target type' warning.

I've grepped the source for all (including openssl) and find nothing
that might emit this error.

Can I get a recommendation of where to look next?

-- 
 Alan E. Derhaag New Era Software Development
 http://www.wolfenet.com/~aderhaag/   Auburn, WA, USA
 email: [EMAIL PROTECTED]  [EMAIL PROTECTED] 



internal_redirect

2000-09-04 Thread Differentiated Software Solutions Pvt. Ltd



Hi,
 
    The following code is not 
working.
 
use Apache;
 
Apache->Request->internal_redirect('http://192.168.1.2/smg/html/adcept_logo.gif');
 
The error is:
 
Can't locate object method "Request" via package 
"Apache" at ./test.cgi line 5.
 
Thanks for your solution.
 
Bye
Muthu S Ganesh
 
 
 
Differentiated Software Solutions Pvt. Ltd.176, 
Ground Floor, 6th Main,2nd Block, RT NagarBangalore - 560032Phone : 
91 80 3431470www.diffs-india.com


Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Paul J. Lucas

On Mon, 4 Sep 2000, Eric L. Brine wrote:

> ELB> Great idea, but just one note; ':' is not legal in CSS class names.
> ELB> In fact, underscores are not even allowed in CSS class names!
> 
> PL> So?  They aren't CSS class names.
> 
> In the preview mode, they are treated as such, so in effect they are.

Then I think the web browser you're using is broken.  The CLASS
attribute is (and never was) reserved for the exclusive use of
styles.  Anything not recognized should be ignored.

> In addition, if those are not stripped out by your module (and as far as
> I can tell with a quick look, they are not),

They probably *could* be.

> the resulting HTML does not conform to both strict HTML and CSS.

It's 100% conformant to HTML: please go read the specification.
As to CSS, I can't comment with authority since I'm not that
familiar with the specification; but, as I said above, I would
hope that anything not recognized is ignored.

> PL> The are in fact legal class names according to the HTML spec.
> 
> The HTML spec doesn't define what is a legal class name. It's simply
> defined as "CDATA" (i.e. a HTML escaped string).

Then anything that is legal CDATA is a legal class name, by
definition.  I really don't know how to make that any clearer.

- Paul




[ANNOUNCE] AO preview release

2000-09-04 Thread brian moseley


The URL

http://www.maz.org/ao/src/AO-0.30.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/I/IX/IX/AO-0.30.tar.gz
  size: 191574 bytes
   md5: 737919c28cf814f4339213d1ed608580


README snip--

AO is a servlet engine for Perl. It provides an application
environment with such features as session tracking and
persistence, security (authentication and authorization),
simple configuration, and customizable logging. It also
eventually will implement a Perl version of the (Java)
Servlet API, providing applications with a well known model
for application construction that abstracts the process
model and deployment environment away from the developer.

--

AO integrates out of the box with Apache::Session and Mason.
i'm hoping others will add integration with AxKit,
HTML::Template, Embperl, ASP, etc. the plugin architecture
allows for us to provide even more implementations of
session tracking and persistence, credential checking, role
authorization, etc, or even to replace the core subsystems
themselves. the adapter architecture will eventually allow
us to run AO apps in either an external perl process or
using today's in-process model - without modifications
either way. the addition of the Servlet API will add a
featureful, robust interface to the web application
environment provided by the servlet engine.

this is my first release of AO to the outside world. it's a
pre-pre-pre-developer release; much is unfinished or in need
of rework, altho i am using the engine as is for several
projects today. i'm interested in feedback on both the
general goals of the software as well as on its architecture
and implementation. there's no mailing list, so please
either send mail to me directly or to the modperl mailing
list (preferred). PLEASE read the README before you do
anything else.

--

labor day release. huzzah!




Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Eric L. Brine


ELB> Great idea, but just one note; ':' is not legal in CSS class names.
ELB> In fact, underscores are not even allowed in CSS class names!

PL> So?  They aren't CSS class names.

In the preview mode, they are treated as such, so in effect they are.
Therefore, the document claims does not conform to both strict HTML and
CSS in preview mode.

In addition, if those are not stripped out by your module (and as far as
I can tell with a quick look, they are not), the resulting HTML does not
conform to both strict HTML and CSS.

PL> The are in fact legal class names according to the HTML spec.

The HTML spec doesn't define what is a legal class name. It's simply
defined as "CDATA" (i.e. a HTML escaped string).

ELB



Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Marc D. Spencer

I have to chime in a little (also noting that we have drifted a bit 
off the original topic...)

While working for a large company as the Chief Architect for the web 
group I was faced with the same need to investigate template options 
-  within the discussion of Build or Buy. And yes, JSP (and ATG 
Dynamo) were on the list of potential buy options.

I took a novel approach: Since I am an engineer, and can only really 
think like one, I _asked_ the web designers, and the web technicians, 
and the programming and management staff what their needs were. I'll 
summarize as briefly as I can below:

   o The designers do not like any template structure that uses the
 angle bracket notation . It makes some wysiwyg editors unhappy
 to see foreign tags, and in the current race to HTML4.0 strict, new
 tags make the validation tools (which have to be applied
 pre-template-parsing, of course) unhappy.

   o There are actually 3 groups involved, and separation of function
 as much as possible allows the three groups to work independently on
 a project without requiring concurrent editing of the same file.

 - HTML coders
 - Behavior (the perl or java code)
 - Resources (pulling in images or other referenced objects)

 With the templating options discussed so far, you tie the HTML
 coders and the perl/java coders to editing the same file. Separation
 of these two is really key, according to those I asked. The Project
 Managers like the separation too.

   o Don't forget localization. None of the existing products that we were
 able to look at handled localization of templates. Localization must
 be handled by HTTP accept headers and/or manual overriding.

   o Virtual hosts are real, and template reuse, especially across VHs,
 while allowing for VH specific customization (driven by the perl/java
 or configuration) is a nicety.


We ended up developing our own solution, using mod_perl. By the way, 
performance tested against ATG's Dynamo, it performed 500 - 700% 
faster.

FWIW.




Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Paul J. Lucas

On Mon, 4 Sep 2000, Eric L. Brine wrote:

> Great idea, but just one note; ':' is not legal in CSS class names. In
> fact, underscores are not even allowed in CSS class names!

So?  They aren't CSS class names.  The are in fact legal
class names according to the HTML spec.

- Paul




Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Ruben I Safir

Nah

You do not want the Perl to look like the HTML at all so the HTML
designers aren't confused.

Also - why put so much perl into the page at all?

[- use mymodule.pm -]

Sam Tregar wrote:
> 
> On Mon, 4 Sep 2000, Perrin Harkins wrote:
> 
> > Embedded perl is absolutely the best answer sometimes, but don't
> > underestmate the value of turning your example into this:
> >
> > [% FOREACH thing = list %]
> >   [% thing.name %]
> > [% END %]
> 
> That isn't really much better, in my opinion.  It's still too much of a
> departure from the HTML around it.  Contrast the above to HTML::Template's
> looping:
> 
>   
>  
>   
> 
> With a little education an HTML designer can learn to manipulate the
> template syntax.  You'll have to teach them to program before they can
> deal with a full "foreach" no matter how you dress it up.
> 
> -sam



Re: further adventures with taint

2000-09-04 Thread Michael Blakeley

At 3:58 PM -0700 7/25/2000, Michael Blakeley wrote:
>Solaris 2.6, Perl 5.6, apache 1.3.9, mod_perl 1.24.
>
>I see intermittent Apache error_log entries like:
>
>[Mon Jul 24 04:08:02 2000] [error] Insecure dependency in require 
>while running with -T switch at (eval 85) line 3.
>
>OK, I (normally) run with PerlTaintCheck on, and I've read perlsec. 
>My PATH is ''. How can I find out where this insecure dependency 
>_is_, so I can turn taint back on? The timestamp tells me which 
>script failed, and it uses a whole slew of modules.
>   use strict;
>   use Apache::Constants qw/:http/;
>   use LWP;
>   use tuner;
>   use MIME::Lite;
>   use HTML::Parse;
>
>I suspect MIME::Lite, but the code won't work if I remove it. How 
>can I be sure if it's to blame, os I can attempt to patch it (or its 
>dependencies)? Is there anything like a Taint::Carp, that'd give me 
>a full back-trace from the insecure code (and works under mod_perl)?
>
>Running with PERL5OPT=-d is no good; the problem never shows up. 
>perl -cwT shows nothing (which confirms that it's a runtime error, I 
>suppose).
>
>The Guide, perlrun, perlsec, and the perl books I've read are... a 
>little weak on Taint debugging techniques. If I can ever work 
>through the problems I'm having, I'll be delighted to contribute 
>some docs on this.

I think I've worked through the problem. Alas, I haven't uncovered 
any cool new debugging techniques to document for the list. Instead, 
I lucked into a fix.

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-07/msg00599.html
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-08/msg00126.html

Basically it seems that AP616 (ActiveState's mostly-Win32 patch to 
date) is a pretty good 5.6.1 "release candidate" for Solaris and 
Linux, too. It fixes several known bugs in 5.6.0 (none of them are 
directly Taint-related, but...).

I did have to rebuild perl, mod_perl, and apache - but I'm used to 
that. Also, AP616 added a test for Sys::Syslog, which failed on my 
Solaris system. 5.6.0 didn't have this test, and I don't use 
Sys::Syslog, so I just removed the test. Also, perl -V now returns 
some ActiveState info (which I suppose you could remove).

I've been running with AP616 and Taint On for three days now, and it 
seems to have fixed my problems. I hope so. I really hope so.

-- Mike



Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Eric L. Brine


"Paul J. Lucas" wrote:
> And I still think that:
>   
> Name: John Q. Public
> Job: mod_perl guru
>   
> is cleaner still: *pure* HTML (no fake elements) that any web
> tool will understand [...]

Great idea, but just one note; ':' is not legal in CSS class names. In
fact, underscores are not even allowed in CSS class names! (Dashes are
allowed, however.)

ELB



Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Ian Kallen


I love this perennial thrash.  My 2 cents: don't underestimate the value
of having mobility in the separation of "engineer" and "production" ('HTML
Monkey', as it's been previously referred too, ee ee).  Mason's ability to
have components that are all Perl, all FooML or a mix in the two allows
you to decide where to draw that line.  I've found that in the real world,
producers have two career paths: one towards design and one towards
technology.  I've worked with systems where the technology was rigidly
opaque and there was no way for producers to ease their way into
programming.  I've torn down that wall.  Simple Perl constructs don't
require careful study of the camel book but if folks _want_ to do
sophisticated things with their data handling, they're not hamstrung
by the constructs of an artificial set of boundaries.  That said, I do
insist on having components and classes constructed for re-use -- this is
a concept that even the most novice producer appreciates.  And though I'm
not in the business of career counseling, I can (and have) provide a
system that has entry points for anybody in the broad spectrum of skills.

> If I want to make something simple, make it simple! For instance:
> 
>   
>   $_
>   
> 
> > 2) Say what?  Are you running a school or trying to things done?  Putting
> > raw Perl in your HTML isn't helping you designers is any way I understand.
> 
> I always try to teach while having things done. Learning a bit of Perl
> will help the designers as much as learning "raw HTML" instead of using
> just a WYSIWYG tool: they will be more productive.

--
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: may be an offtopic question

2000-09-04 Thread Alexander Farber (EED)

Niral Trivedi wrote:
> I know that perl 5.6 does support to some extent utf8 and unicode.. but
> can somebody point to me some site or resources which has examples on
> that??? Because I couldn't find any useful information from the perldoc
> for utf8 or perlunicode..

http://www.perl.com/pub/2000/07/p5pdigest/THISWEEK-2702.html#Unicode_Handling_HOWTO



Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Leslie Mikesell

According to Steve Manes:
> At 11:26 AM 9/4/00 -0300, Nelson Correa de Toledo Ferraz wrote:
> >I agree that one shouldn't put lots of code inside of a template, but
> >variables and loops are better expressed in Perl than in a "little
> >crippled language".
> 
> Your example makes perfect sense to me.  But that's why I'm in "Tech" and 
> not "Creative".  I wrote my own quick 'n nasty templating package a few 
> years ago that allowed Perl code to be embedded inside  
> brackets.  So long as I was coding the pages, it worked great, if not as 
> efficiently as embperl or mason.  But in the real world of NYC new media, 
> Creative typically drives the project.  It's more common for the site to be 
> built by artists and HTML sitebuilders, not programmers.  The first time I 
> see the pages is when they get handed off to Tech to glue it all together. 
> This usually happens sometime past Tech's scheduled hand-off date, i.e. 
> five days to do fifteen budgeted days' work in order to make the launch date.

The real advantage of a 'little crippled language' is that perl
itself makes absolutely no effort to keep you from shooting
both your feed off at once and you really don't want to let
layout people destroy your server with something as simple
as a loop that doesn't exit under certain obscure circumstances.
Nor do you want to become the only person who can safely make
changes.

> My favorite anecdote with embedded Perl templates: after a 100-page 
> creative update to an existing site, nothing worked.  Turned out that some 
> funky HTML editor had HTML-escaped the Perl code.   That was a fun all-nighter.

HTML::Embperl anticipates this problem and would have kept on
working anyway.

  Les Mikesell
   [EMAIL PROTECTED]



Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Jim Winstead

On Sep 04, brian moseley wrote:
> On Mon, 4 Sep 2000, Perrin Harkins wrote:
> 
> > [% FOREACH thing = list %]
> >   [% thing.name %]
> > [% END %]
> 
> what's the value? you have to write a parser and then
> interpret the instructions. that's what eval() is for! and
> your syntax is no prettier or easier to understand than the
> perl.

an interesting design constraint to introduce is allowing arbitrary
(read: non-trusted) users to use the template markup. sometimes
you can't just allow arbitrary perl to be embedded.

and another thing i like to cater to is allowing the templates
to be reasonably edited in common wysiwyg editors, which pushed
me towards the ASP-style tag delimiters. paul's use of the class
syntax is an interesting alternative to that.

jim



Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread brian moseley

On Mon, 4 Sep 2000, Perrin Harkins wrote:

> [% FOREACH thing = list %]
>   [% thing.name %]
> [% END %]

what's the value? you have to write a parser and then
interpret the instructions. that's what eval() is for! and
your syntax is no prettier or easier to understand than the
perl.






Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread brian moseley

On Mon, 4 Sep 2000, Matt Sergeant wrote:

> Thats not how SQL taglibs work in things like AxKit and
> Cocoon. The taglib generates a data structure, which
> gets processed in the next stage of the pipeline (this
> is more efficient than it sounds, but the efficiency is
> hidden from the user).

oh yeah, you're right. ok well, xslt syntax still sucks! :)




Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Sam Tregar

On Mon, 4 Sep 2000, Perrin Harkins wrote:

> Embedded perl is absolutely the best answer sometimes, but don't
> underestmate the value of turning your example into this:
> 
> [% FOREACH thing = list %]
>   [% thing.name %]
> [% END %]

That isn't really much better, in my opinion.  It's still too much of a
departure from the HTML around it.  Contrast the above to HTML::Template's
looping:

  
 
  

With a little education an HTML designer can learn to manipulate the
template syntax.  You'll have to teach them to program before they can
deal with a full "foreach" no matter how you dress it up.

-sam





Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Paul J. Lucas

On Mon, 4 Sep 2000, Perrin Harkins wrote:

> I can still think of situtations in applications I've worked on where there
> were mutually excusive chunks of HTML that would have looked funny with this
> approach, but it gets you about 95% of the way towards a previewing system
> for free.  Cool.

Yes, in the case of mutually-exclusive sections of HTML, you
would get shown both for a preview.  (There is also a built-in
"unless::" class.)  In my experience, it's doesn't crop up THAT
often.

I'm also not claiming the technique is perfect or right for
every possible situation.  Some hairy HTML pages can take some
head-scratching to figure out how to get the page generated
using the technique, but the majority of cases are fairly
straight-forward.

- Paul




Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Perrin Harkins

I was trying to stay out of this one, but...

brian moseley wrote:
> % for my $thing (sort @list) {
><% $thing->{name} %>
> % }

[...]

> there are no sophisticated or mysterious constructs in those
> examples...

Just two kinds of data structures, hash de-referencing syntax, and
lexical scoping, and I would probably have passed that list as a
reference too so you'd need to use @{$list}.  Embedded perl is
absolutely the best answer sometimes, but don't underestmate the value
of turning your example into this:

[% FOREACH thing = list %]
  [% thing.name %]
[% END %]

> i argue that for applications, a nice mvc architecture using
> templates with embedded perl is a fine, fine choice.

Yes, and so is an MVC architecture using templates with a taglib of some
sort.  It largely depends on the nature of the project and the people
involved.

- Perrin



Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Matt Sergeant

On Mon, 4 Sep 2000, brian moseley wrote:

> On Mon, 4 Sep 2000, Matt Sergeant wrote:
> 
> > b) We all meet different people. The people I've worked
> > with, even people proficient in Javascript, flip their
> > lid when they get forced to look at things like $_ and
> > regexps when they know of easier systems out there. And
> > I know what SF is like - anyone working in computing
> > there is getting paid a hell of a lot more than the
> > people working in it here (cost of housing not
> > withstanding).
> 
> your point being, they are highly paid so they are ok
> looking at perl?

No, they are highly paid because they are highly skilled, generally.

> it's a hell of a lot sillier, imo, to use a sql taglib to
> draw data out of a database while you're processing a
> template, than to draw the data FIRST, handling errors and
> business logic, and THEN process your template, doing a very
> simple merge of template and data.

Thats not how SQL taglibs work in things like AxKit and Cocoon. The taglib
generates a data structure, which gets processed in the next stage of the
pipeline (this is more efficient than it sounds, but the efficiency is
hidden from the user).

-- 


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




Can't locate object method "can_stack_handlers" via package "Apache"

2000-09-04 Thread Struan Donald

Hi,

the problem i'm having is that i'm trying to use a module with the
following code in:

if(Apache->can_stack_handlers) {
Apache->push_handlers(PerlChildInitHandler => sub {
for my $aref (@ChildConnect) {
shift @$aref;
Apache::Sybase::Simple->connect(@$aref);
}
});
}

it's being run in loaded in startup.pl which causes apache to die on
startup without any errors and when i run the startup,pl on the
command line i get:

Can't locate object method "can_stack_handlers" via package "Apache"
at /usr/lib/perl5/site_perl/5.005/Apache/Sybase/Simple.pm line 22.
BEGIN failed--compilation aborted at startup.pl line 3.

startup.pl consists of:

use lib qw(/local/0/site/perl);

use Apache::Sybase::Simple; 

Apache::Sybase::Simple->connect_on_init("user", "pass", "server"); 

1;

It's running on RedHat 6.2 with the RedHat rpm of Apache 1.3.12 and
mod_perl 1.24 which was compiled with apxs just in case it was a weird
issue with the RedHat rpm of mod_perl. Aside from the APXS options the
only other compile option was EVERYTHING=1 so stacked handlers are
compiled in.

So, what am i missing?

thanks

struan
-- 
Struan Donald
mailto:[EMAIL PROTECTED]
Code Flunky, 365 Plc.
http://www.365corp.com/



Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread brian moseley

On Mon, 4 Sep 2000, Matt Sergeant wrote:

> b) We all meet different people. The people I've worked
> with, even people proficient in Javascript, flip their
> lid when they get forced to look at things like $_ and
> regexps when they know of easier systems out there. And
> I know what SF is like - anyone working in computing
> there is getting paid a hell of a lot more than the
> people working in it here (cost of housing not
> withstanding).

your point being, they are highly paid so they are ok
looking at perl?

here's one problem. everytime somebody thinks 'embedded
perl' they start thinking about $_ and regexps. when in fact
those constructs are hardly ever used (in my experience) in
display code!

i'll continue to use mason as an example, since that's my
favorite embedded perl system. 98% of my usage is something
like:

% for my $thing (sort @list) {
  <% $thing->{name} %>
% }

or

% if ($something) {
  blah blah blah
% }

there are no sophisticated or mysterious constructs in those
examples... and they're hardly contrived! this is the
essence of 'separation of application and presentation':
application logic provides its results in simple, clean data
structures, and display logic uses iterators, conditionals,
and occassionaly simple formatting functions (taglibs!).

it's a hell of a lot sillier, imo, to use a sql taglib to
draw data out of a database while you're processing a
template, than to draw the data FIRST, handling errors and
business logic, and THEN process your template, doing a very
simple merge of template and data.

i argue that for applications, a nice mvc architecture using
templates with embedded perl is a fine, fine choice. for
strict content presentation - little logic other than how to
render a blob of text - your xslt approach is very
reasonable.




Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Perrin Harkins

"Paul J. Lucas" wrote:
> > What about conditionals and loops though?
> > Wouldn't they break the "preview" ability?
> 
> No: for loops, you just get one iteration; for conditionals, you
> get the result as if the condition were true.

Thanks for the explanation.  I can still think of situtations in
applications I've worked on where there were mutually excusive chunks of
HTML that would have looked funny with this approach, but it gets you
about 95% of the way towards a previewing system for free.  Cool.

- Perrin



Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Paul J. Lucas

On Mon, 4 Sep 2000, Billy Donahue wrote:

> Great, as long as there's no loops or anything but straight up text
> replacement...  I don't like this approach at all!

What I showed *was* a loop; read my other follow-up.

> What if you need to actually USE the `class' attribute of your HTML element?

You can use it just fine: read the HTML spec.  The CLASS
attribute is allowed to have multiple values separated by
whitespace.

- Paul




Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Matt Sergeant

On Mon, 4 Sep 2000, brian moseley wrote:

> On Mon, 4 Sep 2000, Matt Sergeant wrote:
> 
> > To a HTML monkey, all those curly brackets, question
> > marks and dollars are magical. All you've done is reduce
> > some keystrokes. Looks fine to a perl programmer, looks
> > like a modem init string to a designer.
> 
> i dunno dude. my experience in san francisco is that a)
> designers and html monkeys are more often than not different
> sets of people and b) while your comments hold true for
> designers, html monkeys are often as proficient in js as i
> am in perl, and they would be mightily offended at your
> condescending comments.

a) I'm in a shitty mood today. Appologies for the HTML monkeys getting in
my way today :-)

b) We all meet different people. The people I've worked with, even people
proficient in Javascript, flip their lid when they get forced to look at
things like $_ and regexps when they know of easier systems out there. And
I know what SF is like - anyone working in computing there is getting paid
a hell of a lot more than the people working in it here (cost of housing
not withstanding).

-- 


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: HTML Template Comparison Sheet ETA

2000-09-04 Thread Paul J. Lucas

On Mon, 4 Sep 2000, Perrin Harkins wrote:

> "Paul J. Lucas" wrote:
> > And I still think that:
> > 
> >   
> > Name: John Q. Public
> > Job: mod_perl guru
> >   
> > 
> > is cleaner still: *pure* HTML (no fake elements) that any web
> > tool will understand and dummy-content so the page designer can
> > see the end-product before any code is written.
> 
> Having placeholder data in there is an interesting benefit.

I currently use the .chtml extension to tell Apache to do my
magic (via ).  But I often do a:

ln file.chtml file.html

and then I can point my browser at the plain .html version when
I want to see what the mock-up page looks like without executing
any code.  In production, I remove the links.

> What about conditionals and loops though?

I just got another e-mail about this so I could clarify.  There
is no loop that you can see in my example, and this is by design
since HTML doesn't loop.

All of this is explained in the documentaion, but, briefly: the
looping is done under the control of the associated .pm file:
for every HTML file, there is an associated .pm file and that's
where all the code is.

The function bound to the class employee_info tells the HTML
Tree engine that it wants to loop (or not loop) by its return
code.

An example of a conditional:


  blah


where do_this has to have been already evaluated and the result
stuffed into $this->{ do_this }.  But, the "if::" is just a
built-in class (to my module) as a short-cut; you're free to
use your own classes.

The underlying HTML parser is smart enough to "know" what
elements terminate other elements (both explicitly and
implicitly) so it "knows" where the end of the conditional or
loop is.

> Wouldn't they break the "preview" ability?

No: for loops, you just get one iteration; for conditionals, you
get the result as if the condition were true.

- Paul




Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread brian moseley

On Mon, 4 Sep 2000, Matt Sergeant wrote:

> To a HTML monkey, all those curly brackets, question
> marks and dollars are magical. All you've done is reduce
> some keystrokes. Looks fine to a perl programmer, looks
> like a modem init string to a designer.

i dunno dude. my experience in san francisco is that a)
designers and html monkeys are more often than not different
sets of people and b) while your comments hold true for
designers, html monkeys are often as proficient in js as i
am in perl, and they would be mightily offended at your
condescending comments.




Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread brian moseley

On Mon, 4 Sep 2000, Matt Sergeant wrote:

> I was questioning whether or not your HTML people found
> Perl easier than some taglib scheme like HTML::Template,
> or whether you meant they found it easier than XSLT.

ah yes. xslt vs mason, specifically.

> again. With XSLT you can markup your article in some XML
> format, and have explicit programmatic control over how
> that entire article gets presented, right down to the
> links and possibly putting in some breakouts, and other
> stuff. You can do this down to individual attributes.
> This is called declarative processing, and its the key
> to XSLT's power, and also provided in a Perl version
> with AxKit, called XPathScript.

ok, sure. i'm coming from a different place than you are, so
i think about the question differently. my application isnt
editorial/content driven. the html people are concerned with
making the header and footer of the page have our customers'
navigation elements; in specifying colors and such. the data
that is presented in the content area of our page is
fragmented and comes from many disparate data sources. its
quite easy to assemble with embedded code, and would be
quite unweildy with xslt (i know, i've tried the approach).

in general, your point is well taken, and you've even helped
me see a use for it inside my system that i hadn't
previously seen. but that's still not as an aid to my html
people - it's so that i don't have to embed html markup into
my message catalogs (where my localized strings come from).
perhaps i can use xslt to transform catalog source in xml
format to several sets of catalogs, one for html, one for
wml. maybe. see below comments. but i still am much more
inclined to go with the html template approach for the
page's framing elements - which means the artifact that my
html people manipulate is still an html page. not an xsl
stylesheet.

> And you can do this in ways far more powerful than CSS
> can cope with, and not only that, you can do this on the
> server to generate stuff other than HTML (which is the
> only thing your CSS is going to work with), such as
> content for WebTV, or WAP, or PDF.

mm, we've found in the real world that a 'one source fits
all' transformation simply can't cope with the vast
differences between devices. perhaps for simple content
presentation its ok, but for a sophisticated application,
the flow has to change quite dramatically across devices.
it's been more practical for us to use separate sets of jsp
templates for each device, with a custom template
inheritance mechanism to provide the benefits of sharing.




Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Matt Sergeant

On Mon, 4 Sep 2000, Nelson Correa de Toledo Ferraz wrote:

> > That's because you're a Perl programmer.  The template syntax wasn't
> > designed for your tastes.  It was designed for the HTML designers you will
> > eventually have to work with - wether while you're actually on the project
> > or when it moves into maintainance and needs design changes.
> 
> That's a good point, but take a look at Perl itself: it doesn't force you
> to be clear, but there are guidelines to make code more readable.

That doesn't help the designer who has honed his HTML skills and now is
chucked a 500 page copy of "Programming Perl" just to get his job done...

> > > And the first one has two major advantages: 1) requires less code in the
> > > Perl modules and 2) allows designers to know how Perl looks like.
> > 
> > 1) The more code you put in your modules the better.  This promotes code
> > reuse and better documentation.
> 
> If I want to make something simple, make it simple! For instance:
> 
>   
>   $_
>   

To a HTML monkey, all those curly brackets, question marks and dollars are
magical. All you've done is reduce some keystrokes. Looks fine to a perl
programmer, looks like a modem init string to a designer.

> > 2) Say what?  Are you running a school or trying to things done?  Putting
> > raw Perl in your HTML isn't helping you designers is any way I understand.
> 
> I always try to teach while having things done. Learning a bit of Perl
> will help the designers as much as learning "raw HTML" instead of using
> just a WYSIWYG tool: they will be more productive.

At Perl? The designers I've met don't want to be more productive in
Perl. They want to get their jobs done, and that involves spending most of
their day in dreamweaver and photoshop (the rest of the time they usually 
spend smoking, or discussing last night's "Corrie")...

-- 


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: HTML Template Comparison Sheet ETA

2000-09-04 Thread Billy Donahue

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 4 Sep 2000, Paul J. Lucas wrote:
> 
>   And I still think that:
> 
> 
>   Name: John Q. Public
>   Job: mod_perl guru
> 
> 
>   is cleaner still: *pure* HTML (no fake elements) that any web
>   tool will understand and dummy-content so the page designer can
>   see the end-product before any code is written.
> 
>   Another benefit in not mixing any code in the template is that
>   the web page designer can wake up tomorrow and change the
>   template to:
> 
> 
>   
> Name
> Job
>   
>   
> John Q. Public
> mod_perl guru
>   
> 

Great, as long as there's no loops or anything but straight up text
replacement...  I don't like this approach at all!

Where in your example do you leave room to display an array of employees?

What if you need to actually USE the `class' attribute of your HTML element?
It's been hijacked!

- --
"The Funk, the whole Funk, and nothing but the Funk."
Billy Donahue 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/

iD8DBQE5s9yF+2VvpwIZdF0RAoZFAKCQ98QYfj+mTSoQb2X+KBCzj6PA2wCgoCfl
jZJ0JNmHxQpzfRJ+6GE3W6Y=
=/kos
-END PGP SIGNATURE-




Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Matt Sergeant

On Mon, 4 Sep 2000, Perrin Harkins wrote:

> "Paul J. Lucas" wrote:
> > And I still think that:
> > 
> >   
> > Name: John Q. Public
> > Job: mod_perl guru
> >   
> > 
> > is cleaner still: *pure* HTML (no fake elements) that any web
> > tool will understand and dummy-content so the page designer can
> > see the end-product before any code is written.
> 
> Having placeholder data in there is an interesting benefit.  What about
> conditionals and loops though?  Wouldn't they break the "preview"
> ability?

That is a loop - just a single line of it, thats all. This is the same as
Enhydra's XMLC technology. You compile it down to a class that gives you
access to attributes named text::name, then you subclass that class
(allowing you to recompile the base class at any time and not affect your
code) and make it loop however many times you need by manipulating a DOM.

-- 


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: HTML Template Comparison Sheet ETA

2000-09-04 Thread Nelson Correa de Toledo Ferraz

> That's because you're a Perl programmer.  The template syntax wasn't
> designed for your tastes.  It was designed for the HTML designers you will
> eventually have to work with - wether while you're actually on the project
> or when it moves into maintainance and needs design changes.

That's a good point, but take a look at Perl itself: it doesn't force you
to be clear, but there are guidelines to make code more readable.

> > And the first one has two major advantages: 1) requires less code in the
> > Perl modules and 2) allows designers to know how Perl looks like.
> 
> 1) The more code you put in your modules the better.  This promotes code
> reuse and better documentation.

If I want to make something simple, make it simple! For instance:

  
  $_
  

> 2) Say what?  Are you running a school or trying to things done?  Putting
> raw Perl in your HTML isn't helping you designers is any way I understand.

I always try to teach while having things done. Learning a bit of Perl
will help the designers as much as learning "raw HTML" instead of using
just a WYSIWYG tool: they will be more productive.

See you,

Nelson

__
Nelson Ferraz   Insite - Solucoes Internet
e-mail: [EMAIL PROTECTED]   http://www.insite.com.br/




Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Perrin Harkins

"Paul J. Lucas" wrote:
> And I still think that:
> 
>   
> Name: John Q. Public
> Job: mod_perl guru
>   
> 
> is cleaner still: *pure* HTML (no fake elements) that any web
> tool will understand and dummy-content so the page designer can
> see the end-product before any code is written.

Having placeholder data in there is an interesting benefit.  What about
conditionals and loops though?  Wouldn't they break the "preview"
ability?

- Perrin



Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Matt Sergeant

On Mon, 4 Sep 2000, brian moseley wrote:

> On Mon, 4 Sep 2000, Matt Sergeant wrote:
> 
> > Unusual bunch :-)
> 
> don't think so. xslt is overly verbose and complicated, and
> its model is the inverse of the standard html page. whereas
> a nice little mason page with some simple embedded perl
> looks enough like what everybody's used to, to not be big,
> scary and new.
> 
> > Or are you talking about XSLT vs Perl? If so then I'd
> > agree - XSLT is mightily scary compared to a simple HTML
> > template scheme. But infinitely more powerful.
> 
> *raises eyebrow*
> 
> please expand on that last comment.

I was questioning whether or not your HTML people found Perl easier than
some taglib scheme like HTML::Template, or whether you meant they found it
easier than XSLT.

Now as to why XSLT is infinitely more powerful...

Most HTML template schemes are great where the template wraps the
content. So you've got basically a HTML page with some places to insert
content. This is basically an extension of the SSI concept, and while
these schemes have become more powerful, they lack the ability to do
really powerful transformations.

For example, take a large article. Now with an ordinary "wrapper" template
scheme, the article *HAS* to be encoded as HTML, otherwise it just can't
be inserted into the template. You can do some fancy things with
pre-processing, but then that ends up being in the realm of code
again. With XSLT you can markup your article in some XML format, and have
explicit programmatic control over how that entire article gets presented,
right down to the links and possibly putting in some breakouts, and other
stuff. You can do this down to individual attributes. This is called
declarative processing, and its the key to XSLT's power, and also provided
in a Perl version with AxKit, called XPathScript.

And of course just to add to that, declarative processing is not the only
way you can do XSLT. You're quite welcome to use the style you are used
to, using a single main template with insertion points, but as your source
gets more complex you tend to need the declarative processing more.

And you can do this in ways far more powerful than CSS can cope with, and
not only that, you can do this on the server to generate stuff other than
HTML (which is the only thing your CSS is going to work with), such as
content for WebTV, or WAP, or PDF.

-- 


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: Executing Perl Scripts on the Web Browser.

2000-09-04 Thread deraco

On 04-Sep-00 ABDUL RAHMAN... wrote:
>Dear All,
>
>Can any body say me how to execute perl scripts on the web server apache.
 What are the 
>configuration steps required to configure to execute the perl scripts on
the any browsers.
>
>Please send me the steps if any body knows.
>
>
>Abdul Rahman.

Hi,

You'll need a directory in which you'll put your scipts (usually : cgi-bin)

In httpd.conf, you have to modify the lines ScriptAlias :
ScriptAlias /cgi-bin/ /my/path/to/cgi-bin/ 

the location lines :

SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI


and the Directory lines

Options ExecCgi
AllowOverride AuthConfig FileInfo Indexes Limit Options
Order allow,deny
Allow from all
   

This works for me.

Take a look at the docs on the Apache website

Hope this helps

Steph





Dear All,
 
Can any body say me how to execute perl scripts on the web server 
apache.  What are the 
configuration steps required to configure to execute the perl scripts on 
the any browsers.
 
Please send me the steps if any body knows.
 
 
Abdul Rahman.


Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Paul J. Lucas

On Mon, 4 Sep 2000, Nelson Correa de Toledo Ferraz wrote:

> I still think that this:
> 
>
>  Name:  
>  Job:  
>
> 
> Is cleaner (well, as much as perl can be :-)) than this:
> 
>
>  Name:  
>  Job:  
>

And I still think that:

  
Name: John Q. Public
Job: mod_perl guru
  

is cleaner still: *pure* HTML (no fake elements) that any web
tool will understand and dummy-content so the page designer can
see the end-product before any code is written.

Another benefit in not mixing any code in the template is that
the web page designer can wake up tomorrow and change the
template to:

  

  Name
  Job


  John Q. Public
  mod_perl guru

  

and not a single line of the associated Perl code has to
change.  So when either the web page designers or the marketers
(*shudder*) decide that the web page needs some snazzing up,
they can snazz them up all they want and they don't have to bug
the programmers to change anything.

See  for details.

(I've got the day off today so I'm gonna try to figure out how
to get this thing submitted to CPAN.)

> And the first one has two major advantages: 1) requires less code in the
> Perl modules

But that's where the code belongs.

> and 2) allows designers to know how Perl looks like.

Web designers don't care what the Perl looks like.

> I agree that one shouldn't put lots of code inside of a template, but
> variables and loops are better expressed in Perl than in a "little crippled
> language".

I agree: Perl should be used to its full ability, but none of it
should be in the template.

- Paul




Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread brian moseley

On Mon, 4 Sep 2000, brian moseley wrote:

> ah. well anyway, it's ubiquitous, and everybody's got
> it. everybody that counts, anyway, imo.

 redundant .. redundant .. redundant





Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread brian moseley

On Mon, 4 Sep 2000, Matt Sergeant wrote:

> No, it originated way before then I think. Sun copied it
> too.

ah. well anyway, it's ubiquitous, and everybody's got
it. everybody that counts, anyway, imo.





Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread brian moseley

On Mon, 4 Sep 2000, Matt Sergeant wrote:

> Unusual bunch :-)

don't think so. xslt is overly verbose and complicated, and
its model is the inverse of the standard html page. whereas
a nice little mason page with some simple embedded perl
looks enough like what everybody's used to, to not be big,
scary and new.

> Or are you talking about XSLT vs Perl? If so then I'd
> agree - XSLT is mightily scary compared to a simple HTML
> template scheme. But infinitely more powerful.

*raises eyebrow*

please expand on that last comment.





Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Matt Sergeant

On Mon, 4 Sep 2000, brian moseley wrote:

> On Mon, 4 Sep 2000, Matt Sergeant wrote:
> 
> > In AxKit your developers design custom "taglibs" that
> > allow you to design your own tags however you want them
> > to appear. There's a built in taglib for SQL, which
> > allows you to produce XML from a DBI database, but
> > writing taglibs is relatively easy. Once you've written
> > the taglib, its just a drop-in component that your
> > designers can use. And they don't need to know anything
> > about these vegetables you speak of... :-)
> 
> heh! the taglib idea originated with jsp, as i recall.

No, it originated way before then I think. Sun copied it too.

-- 


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: HTML Template Comparison Sheet ETA

2000-09-04 Thread David Hodgkinson


brian moseley <[EMAIL PROTECTED]> writes:

> i used to believe this argument. i was all up on the xslt
> bandwagon. and then i took the question to our html dept.
> and they unanimously preferred perl.

Looking for better paid jobs, I'd guess... ;-)

-- 
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: HTML Template Comparison Sheet ETA

2000-09-04 Thread brian moseley

On Mon, 4 Sep 2000, Matt Sergeant wrote:

> In AxKit your developers design custom "taglibs" that
> allow you to design your own tags however you want them
> to appear. There's a built in taglib for SQL, which
> allows you to produce XML from a DBI database, but
> writing taglibs is relatively easy. Once you've written
> the taglib, its just a drop-in component that your
> designers can use. And they don't need to know anything
> about these vegetables you speak of... :-)

heh! the taglib idea originated with jsp, as i recall.

i started to write mail to the mason list the other day
discussing taglibs and their usefulness in mason... and then
i realized that the concept is already fully embodied in
mason, with its component structure. really. the syntax is
almost totally equivalent. great stuff.





Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread brian moseley

On Mon, 4 Sep 2000, Billy Donahue wrote:

> Which is close enough to HTML that the HTML people
> should understand it. You never really have to "break
> character" while writing presentation pages.  I prefer
> the custom tags approach to the embedded code approach..
> See, in Java you're better off having a servlet set up
> the 'beans' for the JSP, and then invoking the 'dumb'
> JSP to present them.  The logic is in the servlet, and
> the JSP imports the results with useBean statements. The
> designers never have to tiptoe around the logical work,
> they only edit the JSP files.

yes! agree! after years of experimenting with different
processes and procedures, this is _exactly_ where i'm at.




Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Matt Sergeant

On Mon, 4 Sep 2000, brian moseley wrote:

> On Mon, 4 Sep 2000, Matt Sergeant wrote:
> 
> > You and I are programmers and we agree. However once you
> > move to a larger shop where you'll find non-programmers
> > editing templates, the HTML-ish loop looks more sensible
> > than an entirely new language, unfortunately.
> 
> i used to believe this argument. i was all up on the xslt
> bandwagon. and then i took the question to our html dept.
> and they unanimously preferred perl.

Unusual bunch :-)

Or are you talking about XSLT vs Perl? If so then I'd agree - XSLT is
mightily scary compared to a simple HTML template scheme. But infinitely
more powerful.

-- 


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: HTML Template Comparison Sheet ETA

2000-09-04 Thread brian moseley

On Mon, 4 Sep 2000, Matt Sergeant wrote:

> You and I are programmers and we agree. However once you
> move to a larger shop where you'll find non-programmers
> editing templates, the HTML-ish loop looks more sensible
> than an entirely new language, unfortunately.

i used to believe this argument. i was all up on the xslt
bandwagon. and then i took the question to our html dept.
and they unanimously preferred perl.




Executing Perl Scripts on the Web Browser.

2000-09-04 Thread ABDUL RAHMAN.......




Dear All,
 
Can any body say me how to execute perl scripts on the web server 
apache.  What are the 
configuration steps required to configure to execute the perl scripts on 
the any browsers.
 
Please send me the steps if any body knows.
 
 
Abdul Rahman.


Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Billy Donahue

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 4 Sep 2000, Matt Sergeant wrote:

> > That said, I am a mod_perl novice, and I don't know if there's anything
> > equivalent or better than this in the mod_perl world.
> 
> Well to stick the AxKit oar in, yes, of course there's something better...

Gheesh!  I should have seen that coming!!

- --
"The Funk, the whole Funk, and nothing but the Funk."
Billy Donahue 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/

iD8DBQE5s8ls+2VvpwIZdF0RAipnAJ9NYkWEMK829xZKwCZOCyWWpw70uACglIQU
r25PRJGL7DU45NCzNjAs1sk=
=qfy/
-END PGP SIGNATURE-




Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Sam Tregar

On Mon, 4 Sep 2000, Nelson Correa de Toledo Ferraz wrote:

> I still think that this:
> 
>
>  Name:  
>  Job:  
>
> 
> Is cleaner (well, as much as perl can be :-)) than this:
> 
>
>  Name:  
>  Job:  
>

That's because you're a Perl programmer.  The template syntax wasn't
designed for your tastes.  It was designed for the HTML designers you will
eventually have to work with - wether while you're actually on the project
or when it moves into maintainance and needs design changes.

> And the first one has two major advantages: 1) requires less code in the
> Perl modules and 2) allows designers to know how Perl looks like.

1) The more code you put in your modules the better.  This promotes code
reuse and better documentation.

2) Say what?  Are you running a school or trying to things done?  Putting
raw Perl in your HTML isn't helping you designers is any way I understand.

-sam





Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Steve Manes

At 11:26 AM 9/4/00 -0300, Nelson Correa de Toledo Ferraz wrote:
>I agree that one shouldn't put lots of code inside of a template, but
>variables and loops are better expressed in Perl than in a "little
>crippled language".

Your example makes perfect sense to me.  But that's why I'm in "Tech" and 
not "Creative".  I wrote my own quick 'n nasty templating package a few 
years ago that allowed Perl code to be embedded inside  
brackets.  So long as I was coding the pages, it worked great, if not as 
efficiently as embperl or mason.  But in the real world of NYC new media, 
Creative typically drives the project.  It's more common for the site to be 
built by artists and HTML sitebuilders, not programmers.  The first time I 
see the pages is when they get handed off to Tech to glue it all together. 
This usually happens sometime past Tech's scheduled hand-off date, i.e. 
five days to do fifteen budgeted days' work in order to make the launch date.

I had more success with Sam's HTML::Template package.  The sitebuilders 
seemed to better understand how to work with its simpler concept, although 
I had to stay away from HTML::Template's looping constructs for the same 
reason.  No doubt, if there had been better communications and coordination 
between Tech and Creative and I'd had more hands-on input on what Creative 
was doing to those templates I could have eliminated most of the 
screwups.  But in practice, I've found turf warfare to be status quo 
between Tech and Creative in larger agencies.

My favorite anecdote with embedded Perl templates: after a 100-page 
creative update to an existing site, nothing worked.  Turned out that some 
funky HTML editor had HTML-escaped the Perl code.   That was a fun all-nighter.

---[ http://www.magpie.com ]---=o&>o---
Steve Manes
Brooklyn, N'Yawk




Re: mod_perl on solaris with apache

2000-09-04 Thread Rob Tanner

The combo build just fine on Solaris.  Could you be a tad more 
specoific please.

-- Rob

--On 09/05/00 00:45:45 +1100 Joseph Sirucka 
<[EMAIL PROTECTED]> wrote:

> Hi All
>
> I was wondering has anybody compiled mod_perl under solaris with
> apache. I'm  currently trying to do this and have some difficulty. I
> was hoping somebodys  done this and can give me some guiding light. I
> was in particular tying to  compile apache as a DSO.
>
> Please respond to [EMAIL PROTECTED]
>
> Hope to hear from someone soon
>
> Joseph sirucka




   _ _ _ _   __ _ _ _ _
  /\_\_\_\_\/\_\ /\_\_\_\_\_\
 /\/_/_/_/_/   /\/_/ \/_/_/_/_/_/  QUIDQUID LATINE DICTUM SIT,
/\/_/__\/_/ __/\/_//\/_/  PROFUNDUM VIDITUR
   /\/_/_/_/_/ /\_\  /\/_//\/_/
  /\/_/ \/_/  /\/_/_/\/_//\/_/ (Whatever is said in Latin
  \/_/  \/_/  \/_/_/_/_/ \/_/  appears profound)

  Rob Tanner
  McMinnville, Oregon
  [EMAIL PROTECTED]



Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Matt Sergeant

On Mon, 4 Sep 2000, Billy Donahue wrote:

> I've been working with JSPs lately, and I'd use something like:
> 
> 
> 
>   
> 
>   Name
>   Address
> 
> 
>   
> 
> 
>   
> 
>   
> 
> 
> Which is close enough to HTML that the HTML people should understand it.
> You never really have to "break character" while writing presentation
> pages.  I prefer the custom tags approach to the embedded code approach..
> See, in Java you're better off having a servlet set up the 'beans' for
> the JSP, and then invoking the 'dumb' JSP to present them.  The logic is
> in the servlet, and the JSP imports the results with useBean statements.
> The designers never have to tiptoe around the logical work, they only
> edit the JSP files.
>
> That said, I am a mod_perl novice, and I don't know if there's anything
> equivalent or better than this in the mod_perl world.

Well to stick the AxKit oar in, yes, of course there's something better...

In AxKit your developers design custom "taglibs" that allow you to design
your own tags however you want them to appear. There's a built in taglib
for SQL, which allows you to produce XML from a DBI database, but writing
taglibs is relatively easy. Once you've written the taglib, its just a
drop-in component that your designers can use. And they don't need to know
anything about these vegetables you speak of... :-)

-- 


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: [ANNOUNCE] First AxKit live sites

2000-09-04 Thread Matt Sergeant

On Mon, 4 Sep 2000, Francesco Pasqualini wrote:

> Can someone point me to some rich examples of XML/XSL -> HTML trasformations
> like these ones ?
> I'm interested in the XML XSL sources.
> Unfortunately, all the examples I found until now are very poor and too
> simple.

If you really want to get deep into the guts of XSLT, then I suggest you
buy Michael Kay's excellent book on the topic (XSLT Programmer's Reference
by Wrox Press). Alternatively there's lots of good info in the XSLT FAQ
(try Google for the URL).

-- 


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: HTML Template Comparison Sheet ETA

2000-09-04 Thread Billy Donahue

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 4 Sep 2000, Randal L. Schwartz wrote:

> Nelson> And the first one has two major advantages: 1) requires less
> Nelson> code in the Perl modules and 2) allows designers to know how
> Nelson> Perl looks like.
> 
> Is this a codeword for "share our pain"? :)
> 
> Perhaps any HTML Template Comparison sheet should also show how to
> write a loop like that... I know Template-Toolkit would be a syntax
> somewhat in between the two, for example, while Mason would be more
> Perl-like.

I've been working with JSPs lately, and I'd use something like:



  

  Name
  Address


  


  

  


Which is close enough to HTML that the HTML people should understand it.
You never really have to "break character" while writing presentation
pages.  I prefer the custom tags approach to the embedded code approach..
See, in Java you're better off having a servlet set up the 'beans' for
the JSP, and then invoking the 'dumb' JSP to present them.  The logic is
in the servlet, and the JSP imports the results with useBean statements.
The designers never have to tiptoe around the logical work, they only
edit the JSP files.

That said, I am a mod_perl novice, and I don't know if there's anything
equivalent or better than this in the mod_perl world.

- --
"The Funk, the whole Funk, and nothing but the Funk."
Billy Donahue 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/

iD8DBQE5s77o+2VvpwIZdF0RAtJPAKCRu9QU+Kqvib1ehQ/x1T4X/n3rGgCgm2AO
U5w8Hl8SrWK0jPV98QRNELA=
=6vfU
-END PGP SIGNATURE-




Re: [ANNOUNCE] First AxKit live sites

2000-09-04 Thread Francesco Pasqualini

Can someone point me to some rich examples of XML/XSL -> HTML trasformations
like these ones ?
I'm interested in the XML XSL sources.
Unfortunately, all the examples I found until now are very poor and too
simple.
Thanks

Francesco Pasqualini

- Original Message -
From: "Matt Sergeant" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, September 03, 2000 9:45 PM
Subject: [ANNOUNCE] First AxKit live sites


> I know this isn't the usual form of [ANNOUNCE] messages, and axkit-users
> subscribers will have already seen this, but I just wanted people to see a
> real live site built on AxKit...
>
> PDA Verticals Corp have just finished building 4 sites dedicated to
> vertical markets using PDA's. Owen Stenseth went out on a limb to try out
> AxKit for these sites, and he's been following development and doing his
> own custom patches as things went along. This weekend they launched the
> following 4 sites, and I'm posting the links here so that people can see
> real sites that AxKit is being used for:
>
> http://www.pdamd.com
> http://www.pdare.com
> http://www.pdajd.com
> http://www.pdafn.com
>
> --
> 
>
> 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: HTML Template Comparison Sheet ETA

2000-09-04 Thread Randal L. Schwartz

> "Nelson" == Nelson Correa de Toledo Ferraz <[EMAIL PROTECTED]> writes:

Nelson> And the first one has two major advantages: 1) requires less
Nelson> code in the Perl modules and 2) allows designers to know how
Nelson> Perl looks like.

Is this a codeword for "share our pain"? :)

Perhaps any HTML Template Comparison sheet should also show how to
write a loop like that... I know Template-Toolkit would be a syntax
somewhat in between the two, for example, while Mason would be more
Perl-like.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!



Re: HTML Template Comparison Sheet ETA

2000-09-04 Thread Matt Sergeant

On Mon, 4 Sep 2000, Nelson Correa de Toledo Ferraz wrote:

> I agree that one shouldn't put lots of code inside of a template, but
> variables and loops are better expressed in Perl than in a "little
> crippled language".

You and I are programmers and we agree. However once you move to a larger
shop where you'll find non-programmers editing templates, the HTML-ish
loop looks more sensible than an entirely new language, unfortunately.

-- 


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: HTML Template Comparison Sheet ETA

2000-09-04 Thread Nelson Correa de Toledo Ferraz

> To which HTML::Template responds: "Sure you know Perl, but does the HTML
> designer you're working with?"  HTML::Template has a simple, HTML-esque
> syntax for its template files that is aimed at HTML designers. 

I still think that this:

   
 Name:  
 Job:  
   

Is cleaner (well, as much as perl can be :-)) than this:

   
 Name:  
 Job:  
   

And the first one has two major advantages: 1) requires less code in the
Perl modules and 2) allows designers to know how Perl looks like.

> Keep the
> Perl in your modules and keep the HTML in your template files.  Go the
> other direction and soon enough you've got your programmers changing 
> font colors.

I'd rather putting all the formatting information in a CSS file...

I agree that one shouldn't put lots of code inside of a template, but
variables and loops are better expressed in Perl than in a "little
crippled language".

Nelson

__
Nelson Ferraz   Insite - Solucoes Internet
e-mail: [EMAIL PROTECTED]   http://www.insite.com.br/





mod_perl on solaris with apache

2000-09-04 Thread Joseph Sirucka

Hi All

I was wondering has anybody compiled mod_perl under solaris with apache. I'm 
currently trying to do this and have some difficulty. I was hoping somebodys 
done this and can give me some guiding light. I was in particular tying to 
compile apache as a DSO.

Please respond to [EMAIL PROTECTED]

Hope to hear from someone soon

Joseph sirucka



[ANNOUNCE] Apache::Reload 0.05

2000-09-04 Thread Matt Sergeant

This latest release of Reload adds the ability to specify an entire
hierarchy of modules in the ReloadModules list, like so:

PerlSetVar ReloadModules "My::Foo My::Bar Foo::Bar::*"

which will reload all modules from Foo/Bar.pm to Foo/Bar/Blue/Far/Gear.pm
and so on.

-- 


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: StatINC Question

2000-09-04 Thread Warren D. Johnson


Matt,

Thank you for the followup.  My original thought was that StatINC reloaded
modules as appropriate and that each child should share a common cache of
pre-compiled scripts.  Since that is not the case, it makes developing
larger applications in mod_perl a bit trickier.  Trickier because now
everytime I modify some  file that falls under the supervision of StatINC I
have to do a graceful restart to get all the scripts
re-synchronized/recompiled/reloaded.  Is there any other way around this?
Can you force the apache's child processes to all use the same cache ?  I've
resorted to using PerlRun until it's time to go production, then i will
switch to full modperl.

Hm, thanks!

-Warren

[SNIP, SNIP, SNIP]

> > received a request to handle a mod-perl-script that StatINC would tell
the
> > server to hold up for a second while it recompiles these modules and
then
> > let it go on it's way.  It's almost as if each child process maintains
it's
> > own seperate cached version of the modperl-covered scripts.  Is this the
> > case?
>
> Yes, this is the case. Each child has its own copy of the compiled
> module. When you initially start the server, if your modules are
> pre-loaded, initially this memory will be copy-on-write shared across each
> child (i.e. only one area of memory used and shared between the children),
> but when you reload them using something like StatINC, that sharing
> disappears.
>
> You could try PerlFreshRestart and issue a graceful restart if this isn't
>