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