Re: [binarycloud-dev] xslt

[<al...@th...>]

I am an interface designer and I feel a little behind not knowing how to utilize 
XML and XSLT. I've dabbled with XML but never got very far with it. Does anyone 
have any basic exaples or references that utilize these presentation tools 
effectively? 

As far as learning a new language for developing interfaces, it shouldn't be that 
bad. We've had to wrestle with everything else, and even when it takes invisible 
gifs to set the height and width of table cells and position elements, you do it 
until you find a better technique. 

Alby

---- Original Message ----

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/

_______________________________________________
binarycloud-dev mailing list
bin...@li...
http://lists.sourceforge.net/lists/listinfo/binarycloud-dev