binarycloud-dev

[binarycloud-dev] xslt

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

hi all,

who here has done anything with xslt?

I want to make available all the resources I have so people will understand
what reasons we have for using it, why it is so powerful, and why (here we
go) all distro binarycloud r2 modules will use xslt exclusively for all
presentation.

If anyone's interested, I'll put up some code examples.

_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] xslt

[Monte O. <mo...@is...>]

I'm interested in seeing some examples. How does this affect the use of
template engines, such as Smarty?

Alex Black wrote:

> hi all,
>
> who here has done anything with xslt?
>
> I want to make available all the resources I have so people will understand
> what reasons we have for using it, why it is so powerful, and why (here we
> go) all distro binarycloud r2 modules will use xslt exclusively for all
> presentation.
>
> If anyone's interested, I'll put up some code examples.
>
> _alex
>
> --
> alex black, ceo
> en...@tu...
>
> the turing studio, inc.
> http://www.turingstudio.com
>
> vox+510.666.0074
> fax+510.666.0093
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev

Re: [binarycloud-dev] xslt

[alex b. <en...@tu...>]

> I'm interested in seeing some examples. How does this affect the use of
> template engines, such as Smarty?

Attached.

Note that this isn't r2 stuff really, I'm putzing with some ideas.

But assuming you have sablot compiled in to php you can run this stuff.
It's surprisingly fast.

I got _180k_ of html out of it from a 44k xml source + 5k xslt, and that
only took 1 second.
Most normal documents take in the thounsanths of seconds.

Sablot sort of sucks, but 4.1 will solve that.

Re: smarty:
I'm not going to build in support for smarty, but I should explicitly
mention that you can easily build a smarty subclass for TemplateManager.
TemplateManager was specifically designed to take any template type, it's a
generalized API.

But XSLT is so unbelieveably groovy, I'll be building all my code with it.
Once you get over some of the little idiosyncracies, you realize how
powerful xslt really is.

So the short answer is that all release binarycloud 2 modules will use XSLT
exclusively. If someone wants to write a smarty subclass for
TemplateManager, I'm happy to include it in the release.

_alex

Re: [binarycloud-dev] xslt

[alex b. <en...@tu...>]

> I'm interested in seeing some examples. How does this affect the use of
> template engines, such as Smarty?

Let me expand on this a little, so you understand the reasons:

First, the builder classes (yes these are mysterious and not documented, I
promise this is coming soon) will all be in the business of generating
layout _arrays_ and will not in fact use any presentation code. They will
send xml to TemplateManager, with a template location, and TemplateManager
will rip the definition (xml) into whatever-you-like (PDF, html, wml, etc)
with xslt.

So, that means we can use intelligent builder classes to generate these
arrays (xml), which can all use the _same_ presentation code. That means you
code one form layout, and you only need to code anoher form layout if you
have a special/variant form. Everything else is handled for you, down to
form element generation. For obvious reasons this is extremely powerful.

Now, on top of that, add the ability to output PDF from the same XML that we
output html for forms, or a list (html table, or PDF, etc). Whereas before,
generating PDFs would really be quite scary, and require lots of separate
code - now it isn't scary because of xslt:fo.

xslt has some quirks, the syntax is fairly verbose, but my initial reaction
was wrong: it isn't so verbose as to be annoying, especially when you look
at it in the perspective of a real document, where you see a lot of html,
and a bit of xslt.

Most of the idiosyncracy comes from the element names, and the _exteme_
strictness of the processor - because everything you write has to be valid
xml.

After a small period of "ick", I like that a _lot_: if you are using xslt,
you are implicitly generating xhtml, and at your option, normal html 4 from
the same file. It also means your documents are quite elegant: they are well
formed, structurally correct xml docs, and they look nice. Everything is
easy to read, because the structure is imposed.

I'm still getting use to XPath, and I need to do some experienmentation with
xsl:import, but I'm already hooked. Also, this is already a standard, and I
think you'll see a huge amount of code generated using it.

---

The other thing about XSLT is it doesn't care about the output. You can use
XSLT to generate multiple versions of a php file using an XML source, you
can use XSLT to output text, csv, you name it. Because of that, it's a
fantastic general purpose tool, which we can use for all kinds of tasks.

Ok, so how does this relate to entities, and all that?
The idea with entities is that they are essentially xml document types:
entities are hierarchical structures with nested attributes, and entity
definitions can include other entities. Entity definitions include a ton of
meta information about each attribute: the basic datatype of the entity,
maybe a regex that should be used to validate the data, the attribute name,
label, etc. All of this knowledge about the fields in your database is in a
clear, structurally sound xml file

That means you can reference entities with xpath-like syntax, and quickly
build layout descriptions for forms, lists, trees, calendars, etc. Your
basic layouts for forms and lists/tables can reside in 2 files. That means
you can write entity definitions, and from those you can generate:
    -metabase xml schemas
    -forms
    -lists
    -displays/layouts

    with no additional code. if you want to override the "default", then you
pass in a template file.

I hope everyone understands that concept, and why it is so powerful. If
anyone doesn't, please speak up.

Instead of building all this markup which is unnecessary, you invest more
time in creating entity definitions, rules which govern adding and editing
entities (complex attribute relationships), and the system will take care of
a lot of the rest of the work for you.

All of the binarycloud r2 "data flow" goes thorugh one class
(EntityManager), and is validated by the same rules - regardless of whether
your input is from an html form, an xml-rpc package, or anywhere else. And
because we have all this knowledge about entities nested in the entity
declarations, we can make edicated guesses about how the entity attributes
should be displayed - so in many cases you can establish a default, and only
rarely will you have to build files to overrirde those defaults.

/rant.

_alex

Re: [binarycloud-dev] xslt

[Monte O. <mo...@is...>]

Yeah, all this stuff as been the XML hype for some time now, and as a
technology person I highly agree that XML (& XSLT) is the way to go, it
just makes sense. What my concern is how this affects the interface
designers. Right now, they know and understand HTML/CSS, and have picked
up the learning curve on how to fit it into a template language. So how
do they deal with XSLT? Learn a whole new concept/language? If they do,
how do they understand and control how XSLT outputs thier work into
HTML? They can be very picky, and may just get totally frustrated trying
to get things to look the way they want. They are already dealing with
browser bugs & inconsistancies, now they have to throw XSLT into the
mix.

Maybe I'm off base here, as I have only read about XML & XSLT and tried
rudimentary examples. I haven't tried to actually put it to use in a
production environment. But, I'm going to grab r2 and do some tests and
analysis.

alex black wrote:
> 
> > I'm interested in seeing some examples. How does this affect the use of
> > template engines, such as Smarty?
> 
> Let me expand on this a little, so you understand the reasons:
> 
> First, the builder classes (yes these are mysterious and not documented, I
> promise this is coming soon) will all be in the business of generating
> layout _arrays_ and will not in fact use any presentation code. They will
> send xml to TemplateManager, with a template location, and TemplateManager
> will rip the definition (xml) into whatever-you-like (PDF, html, wml, etc)
> with xslt.
> 
> So, that means we can use intelligent builder classes to generate these
> arrays (xml), which can all use the _same_ presentation code. That means you
> code one form layout, and you only need to code anoher form layout if you
> have a special/variant form. Everything else is handled for you, down to
> form element generation. For obvious reasons this is extremely powerful.
> 
> Now, on top of that, add the ability to output PDF from the same XML that we
> output html for forms, or a list (html table, or PDF, etc). Whereas before,
> generating PDFs would really be quite scary, and require lots of separate
> code - now it isn't scary because of xslt:fo.
> 
> xslt has some quirks, the syntax is fairly verbose, but my initial reaction
> was wrong: it isn't so verbose as to be annoying, especially when you look
> at it in the perspective of a real document, where you see a lot of html,
> and a bit of xslt.
> 
> Most of the idiosyncracy comes from the element names, and the _exteme_
> strictness of the processor - because everything you write has to be valid
> xml.
> 
> After a small period of "ick", I like that a _lot_: if you are using xslt,
> you are implicitly generating xhtml, and at your option, normal html 4 from
> the same file. It also means your documents are quite elegant: they are well
> formed, structurally correct xml docs, and they look nice. Everything is
> easy to read, because the structure is imposed.
> 
> I'm still getting use to XPath, and I need to do some experienmentation with
> xsl:import, but I'm already hooked. Also, this is already a standard, and I
> think you'll see a huge amount of code generated using it.
> 
> ---
> 
> The other thing about XSLT is it doesn't care about the output. You can use
> XSLT to generate multiple versions of a php file using an XML source, you
> can use XSLT to output text, csv, you name it. Because of that, it's a
> fantastic general purpose tool, which we can use for all kinds of tasks.
> 
> Ok, so how does this relate to entities, and all that?
> The idea with entities is that they are essentially xml document types:
> entities are hierarchical structures with nested attributes, and entity
> definitions can include other entities. Entity definitions include a ton of
> meta information about each attribute: the basic datatype of the entity,
> maybe a regex that should be used to validate the data, the attribute name,
> label, etc. All of this knowledge about the fields in your database is in a
> clear, structurally sound xml file
> 
> That means you can reference entities with xpath-like syntax, and quickly
> build layout descriptions for forms, lists, trees, calendars, etc. Your
> basic layouts for forms and lists/tables can reside in 2 files. That means
> you can write entity definitions, and from those you can generate:
>     -metabase xml schemas
>     -forms
>     -lists
>     -displays/layouts
> 
>     with no additional code. if you want to override the "default", then you
> pass in a template file.
> 
> I hope everyone understands that concept, and why it is so powerful. If
> anyone doesn't, please speak up.
> 
> Instead of building all this markup which is unnecessary, you invest more
> time in creating entity definitions, rules which govern adding and editing
> entities (complex attribute relationships), and the system will take care of
> a lot of the rest of the work for you.
> 
> All of the binarycloud r2 "data flow" goes thorugh one class
> (EntityManager), and is validated by the same rules - regardless of whether
> your input is from an html form, an xml-rpc package, or anywhere else. And
> because we have all this knowledge about entities nested in the entity
> declarations, we can make edicated guesses about how the entity attributes
> should be displayed - so in many cases you can establish a default, and only
> rarely will you have to build files to overrirde those defaults.
> 
> /rant.
> 
> _alex
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev

--
Monte Ohrt <mo...@is...>
http://www.ispi.net/

Re: [binarycloud-dev] xslt

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

> Yeah, all this stuff as been the XML hype for some time now, and as a
> technology person I highly agree that XML (& XSLT) is the way to go, it
> just makes sense. What my concern is how this affects the interface
> designers. Right now, they know and understand HTML/CSS, and have picked
> up the learning curve on how to fit it into a template language. So how
> do they deal with XSLT? Learn a whole new concept/language? If they do,
> how do they understand and control how XSLT outputs thier work into
> HTML? They can be very picky, and may just get totally frustrated trying
> to get things to look the way they want. They are already dealing with
> browser bugs & inconsistancies, now they have to throw XSLT into the
> mix.

Speaking as a a designer (I have a strange hat on now, so I am qualified) -
xslt is wonderful for all of the above.

I get properly compressed output.
I am forced to make clean, properly structured documents.
I'm not forced, but it certainly helps to use CSS properly.

etc.

Yes, XSLT is a learning curve, but I don't have a problem with learning
something new as long as it's better.

Which is why I should re-iterate that TemplateManager can and (no doubt)
will have support for all kinds of template systems, contributed by users.

> Maybe I'm off base here, as I have only read about XML & XSLT and tried
> rudimentary examples. I haven't tried to actually put it to use in a
> production environment. But, I'm going to grab r2 and do some tests and
> analysis.

Well, if you grab the r2 snap I published, you don't be able to run it :)

That's sort of a "directory structure" snap, it doesn't work. It will soon,
though.

_alex