[lxml-dev] Targeted XSL transformations

[Emanuele D'Arrigo]

2009/7/16 Stefan Behnel <stefan_ml at behnel.de>

>  > It isn't XUL or me working on a GUI system that does. But lxml does not
> have
> > an etree.CSS() function which generates a CSS transformation, does it?
> > However, it does have an etree.XSLT() function which generates an xslt
> > transformation. Isn't it?
>
> That's what I meant: you don't need that. CSS doesn't do tree
> transformations, it only cares about layout and 'visual effects'. The idea
> is to build up a document that contains the complete content, and then
> associate a CSS file with it that defines where the different parts of the
> content appear and how they should look like (colour, fonts, etc.).


Hmmm. I might be starting to grasp what you are suggesting. You are
suggesting to load the xml/xul content separately from the css information
and associate the two together only as needed, inside the application, as I
build the actual objects that are described by the xul content and are
eventually displayed to screen. This effectively means that the css doesn't
act on the xml/xul content file nor the generated ElementTree, but instead
it acts directly on the display objects that are created out of it. It acts
on the objects that are eventually displayed rather than the xml objects
generated by etree or objectify. Hmmm. That means I'd have to create my own
css selectors that act on the display objects rather than the elements in an
ElementTree object. And of course I'd have to call upon the right selectors
as the relationships of the display objects changes - the original problem I
am facing even with xslt providing style information. Right now I can't
quite think how to do that. But it's certainly something worth investigating
further. Thank you!


> You can use XSLT to aggregate the content into a document, but you'd write
> up a CSS file manually (or with a suitable CSS editor or whatever) to
> define the visual layout of the presentation. Do you have a need to do that
> programmatically?


Programmatically what I need is to be able to add composite GUI elements to
an interface. I.e. a composite GUI element might have text labels, text
input fields and buttons. The description of the element in terms of its
sub-components is in a XUL file but the style is dependent on 1) some
default style information 2) any overriding style information that has been
added or modified at runtime, i.e. by the user.

When I add a composite GUI element to an interface (i.e. a new record in a
table) it's easy enough to add it to the tree of objects in the GUI, but in
terms of style I'd need to find out which style information applies to it
given the nature of the added element and its location in the tree. In a
sense, rather than selecting the element given a (css) rule, I'd need to
select the applicable rules from the element and its position.

Furthermore I'd need to find a way to apply any rule that the addition,
removal or modification of an element has made applicable to other elements.
I.e. the rule E F {color:red} does not apply until the element E has an
element F as a child. When I add that child I must somehow retrieve that
rule and apply it to E. Right now I don't quite know how to do that.

But I realise I am digressing into non-lxml related issues. I apologize if
I'm abusing of your and other's patience. Admittedly there are various parts
of the problem statement that remain unclear even to me. Attempting to
explain it to you and the list does help a little, hence my potentially
unwelcome verbosity.

Thank you again.

Manu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/lxml-dev/attachments/20090716/b0fd855e/attachment.htm