binarycloud-dev

[binarycloud-dev] the xsl decision

[Alex B. <en...@tu...>]

hi all,

I've been mulling over ditching support for "parsed/block" templates from r2
in favor of:
    -pure XSL
    -an XSL -> PHP makefile for speed in important areas.

However, I wanted to find out if there is anyone on the list is using XSL in
production, and get their opinions.

From my now fairly extensive playing-around-with-it experience, I'm pretty
happy with it despite the verboseness, though it seems to have a couple
annoying limitations (no entities, and you can't nest templates, which seems
unbelievably stupid, so I think I might have missed something)

even with the above, this is so much cleaner than any other way I've come
across that I'm tempted.

ideas?


_alex


--
alex black, ceo
en...@tu...

the turing studio, inc.
http://www.turingstudio.com

vox+510.666.0074
fax+510.666.0093

Re: [binarycloud-dev] the xsl decision

[Luke F. <fra...@tc...>]

On Sat, 28 Apr 2001, Alex Black wrote:

> hi all,
> 
> I've been mulling over ditching support for "parsed/block" templates from r2
> in favor of:
>     -pure XSL
>     -an XSL -> PHP makefile for speed in important areas.

By this you mean droping "smarty"-style templates, right? I'm cool with it
as long as we can compile the XSL templates... :)

I hate the XSL syntax, but it is the standard, so we web developers
are going to have to live with it, I guess.

Luke

Re: [binarycloud-dev] the xsl decision

[Alex B. <en...@tu...>]

> On Sat, 28 Apr 2001, Alex Black wrote:
> 
>> hi all,
>> 
>> I've been mulling over ditching support for "parsed/block" templates from r2
>> in favor of:
>>     -pure XSL
>>     -an XSL -> PHP makefile for speed in important areas.
> 
> By this you mean droping "smarty"-style templates, right? I'm cool with it
> as long as we can compile the XSL templates... :)

Heh, you want to write the code? :)

> I hate the XSL syntax, but it is the standard, so we web developers
> are going to have to live with it, I guess.

Well, I'm not in love with it either, but it's a hell of a lot more
efficient than (even cached) "block style" templates.

This isn't final, i.e. I need to work out some other things before I'm
convinced that XSL - only - is a good option.

_a



--
alex black, ceo
en...@tu...

the turing studio, inc.
http://www.turingstudio.com

vox+510.666.0074
fax+510.666.0093

Re: [binarycloud-dev] the xsl decision

[Luke F. <fra...@tc...>]

On Tue, 1 May 2001, Alex Black wrote:
> > By this you mean droping "smarty"-style templates, right? I'm cool with it
> > as long as we can compile the XSL templates... :)
> 
> Heh, you want to write the code? :)

I'm willing, but I haven't thought about how I would do it yet...any
thoughts?

I'm partial to a JSP-style on-the-fly recompilation based on file
modification dates (is that how JSP works? I'm not really sure, but I hope
you understand what I mean).

> > I hate the XSL syntax, but it is the standard, so we web developers
> > are going to have to live with it, I guess.
> 
> Well, I'm not in love with it either, but it's a hell of a lot more
> efficient than (even cached) "block style" templates.

Definately. I'm just a paranoid delusional who thinks XML is a conspiracy
to take the web back from the masses (see: idiotic, complex, verbose
syntax, case sensitivity, etc.)

Luke

Re: [binarycloud-dev] the xsl decision

[Alex B. <en...@tu...>]

> I'm willing, but I haven't thought about how I would do it yet...any
> thoughts?

I'll include detailed specs in the next revision of the r2 docs.

Anyway, the short answer is I have a very clear idea of how it would work.

> I'm partial to a JSP-style on-the-fly recompilation based on file
> modification dates (is that how JSP works? I'm not really sure, but I hope
> you understand what I mean).

I like this method as well, it's clean and allows updates simply.

>>> I hate the XSL syntax, but it is the standard, so we web developers
>>> are going to have to live with it, I guess.
>> 
>> Well, I'm not in love with it either, but it's a hell of a lot more
>> efficient than (even cached) "block style" templates.
> 
> Definately. I'm just a paranoid delusional who thinks XML is a conspiracy
> to take the web back from the masses (see: idiotic, complex, verbose
> syntax, case sensitivity, etc.)

heh :)

From working with it, I'm pretty happy with the whole "cloud" (pardon the
expression) of apps, _especially_ Xpath which I think is very well done.

_a


--
alex black, ceo
en...@tu...

the turing studio, inc.
http://www.turingstudio.com

vox+510.666.0074
fax+510.666.0093

Re: [binarycloud-dev] the xsl decision

[Peter B. <re...@f2...>]

At 01:02 PM 5/2/01 -0500, you wrote:
>I'm partial to a JSP-style on-the-fly recompilation based on file
>modification dates (is that how JSP works? I'm not really sure, but I hope
>you understand what I mean).

Have a look at a new PHP template engine that appeared in the last couple 
of weeks: PHP Server Pages Cooker (PSPCooker)

"PSPCooker is a new template engine for PHP, that mimics Sun's JSP 
functionality. External template files (static HTML files) are compiled 
into PHP files when requested. Then and on subsequent requests, the 
generated PHP files are executed. PSPCooker is able to detect when a HTML 
source file has been modified and will recompile the associated PHP file 
automatically."

Hope that's useful,
Peter.


---oOo---
Do you sendcard?
http://www.sendcard.f2s.com/
PHP postcard script supporting 9 databases!
---oOo---

Re: [binarycloud-dev] the xsl decision

[Luke F. <fra...@tc...>]

On Wed, 2 May 2001, Peter Bowyer wrote:

> Have a look at a new PHP template engine that appeared in the last couple 
> of weeks: PHP Server Pages Cooker (PSPCooker)
> 
> "PSPCooker is a new template engine for PHP, that mimics Sun's JSP 
> functionality. External template files (static HTML files) are compiled 
> into PHP files when requested. Then and on subsequent requests, the 
> generated PHP files are executed. PSPCooker is able to detect when a HTML 
> source file has been modified and will recompile the associated PHP file 
> automatically."

Do you have a link?