Hi Hussein,

Thanks for the suggestion, but I'm afraid my problem is rather more
complicated than that, and I'm certain that it cannot be solved using
standard CSS. The root "mode" attribute is a kind of shorthand that can
define the settings of several conditions. Mode="normal" might, for example,
mean os="linux", customer="Microsoft", version="3.0". There is a lot of
indirection involved. If the "matches" function I dreamed up were
implemented, this is how I believe I would need to use it:

E:matches("contains(concat(' ', at value,' '),concat('
',/root/local-config/filters/filt...@id=/root/@mode]/criteri...@selector=cur
rent()/@selector]/@value,' '))"){
     background-color: #ffe4c4;
 }

The E element has two attributes of interest, which might be set as follows:

selector="os" value="linux mac"

meaning that the contents of the element are relevant for both linux and mac
OSes.

The local-config element referenced in the xpath expression is included in
documents as an external entity and contains configuration data (including
filter definitions) for all the documents in a particular project.

A filter defines a set of selection criteria:

<filter id="normal">
 <criterion selector="os" value="linux"/>
 <criterion selector="customer" value="Microsoft"/>
 <criterion selector="version" value="3.0"/>
</filter>

and the /root/@mode attribute must contain the name of one of these filters
if it is set.

Selectors and their possible values are defined elsewhere in the config
file.

This probably seems like a very convoluted structure, but it makes it
relatively easy and SAFE to produce many variants of a single document.
Since all filter names, selector names and values are predefined as IDs in
the local-config file, it's easy to prevent the writer making mistakes.

As I said earlier, the "matches" idea is just a bit of "wishful thinking",
and a "transform" function would be a perfectly adequate solution for me. If
you should decide not to implement that, then I will have to find some other
solution myself...

... and it looks as though Alain Pierrot may have provided me with a means
of doing that, so thanks very much to him.

It would be nice to know if you intend to implement a "transform" command,
and if so, what it will look like.

Thanks once again for your unmatchable support.

Kevin Flynn

-----Original Message-----
From: [email protected]
[mailto:xmleditor-support-bounces at xmlmind.com] On Behalf Of Hussein Shafie
Sent: Tuesday, January 02, 2007 3:51 PM
To: Kevin Flynn
Cc: xmleditor-support at xmlmind.com
Subject: Re: [XXE] XMLmind XML Editor 3.5.1

Kevin Flynn wrote:
> I'm one of those whose has a macro that will be broken if I upgrade to
> version 3.5.1. I don't feel I can complain too loudly after 4 or 5 years
as
> a very satisfied "freeloader", and I can probably work around the issue
one
> way or another.
> 
> I like the sound of the transform command Hussein has proposed, but also
> have an alternative/additional suggestion that would solve my problem at
> least.

Let's forget about the "transform" command and let's rather concentrate
on a clean solution for your display problem.



> The homegrown DTD I use includes a conditional filtering mechanism similar
> to (but a little more complex than) docbook "profiling". Since the
documents
> I create make heavy use of this mechanism, they can sometimes get
difficult
> to edit. In order to simplify editing, therefore, I can switch between
> different "views" in which different sets of conditions are applied and
> irrelevant information is hidden. The current view is determined by an
> attribute of the document's root element. Ideally, changing this attribute
> would immediately change the view. This is not possible, however, because
> CSS selectors are not powerful enough. I currently get around this
> limitation by running a "process" transformation that sets a "view"
> attribute to "show" or "hide" on all conditionalized elements each time
the
> "current-view" attribute is updated. This view attribute can then be used
by
> XXE's CSS display mechanism to show/hide the correct elements. The view
> attribute is only needed for display purposes; it has no real function in
> the DTD.
> 
> So my particular problem would presumably be solved by a "transform"
> command, but it occurs to me that it could be more elegantly solved by a
CSS
> extension that allowed an xpath match expression to be used as a selector.
> Then I could do the whole thing like this:
> 
> E:matches("<complex xpath expression matching elements that are to be
> displayed>"){
>     background-color: #ffe4c4;
> }
> 
> E:matches("<complex xpath expression matching elements that are NOT to be
> displayed>"){
>     content: "*";
>     background-color: #409040;
>     color: black;
> }
> 
> And get rid of the superfluous view attribute.

The idea is to create a dependency between the way the root element is
rendered on screen and the value of this attribute (let's call the root
element "root" and this attribute "mode").

---
root[mode] {
    background-color: white;
}
---
The above rule is not useful but it tells XXE that the rendering of root
element "root" depends on attribute "mode".

The following rules change the way element "bar", a descendant of root
element "root", is displayed, depending on the value of attribute "mode"
of root element "root".

---
root[mode=normal] bar {
    background-color: #ffe4c4;
}

root[mode=special] bar {
    content: "*";
    background-color: #409040;
    color: black;
}
---




 
--
XMLmind XML Editor Support List
xmleditor-support at xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 4458 bytes
Desc: not available
Url : 
http://www.xmlmind.com/pipermail/xmleditor-support/attachments/20070104/bf65527b/attachment.bin
 

Reply via email to