Discussion:
Templates XML conformance
Fournier Daniel
2004-05-05 14:30:10 UTC
Permalink
The use of XML for Xaraya templates is a nice idea: during the
development stage, one can validate them with ordinary XML tools.

Unfortunatly, Xaraya_Classic theme default.xt template is not XML
conformant.

For instance, it uses an XML entity (&xar-baseurl;) to reference the
site base URL. However this entity is not defined within any ENTITY
declaration. How is this entity defined? Is it just a pseudo entity
replaced in the PHP processing of the template?

Another XML conformance violation is the DOCTYPE declaration for HTML,
which should come before document root element.
Why not use a true DOCTYPE declaration for the template and modify it to
have the right HTML DOCTYPE including the baseurl entity declaration
when compiling the template.

The template prolog could be:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE xar:blocklayout
[
<!ENTITY xar-baseurl "$xar-baseurl">
]>
<?xar type="page" ?>
....

after compilation:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
[
<!ENTITY xar-baseurl "http://www.myxarsite.com/">
]>

....

Another problem is the multiplication of elements with identical id
attributes. For instance: <td id="leftmenus">. ID attributes have to be
unique in the document. Probably a class attribute instead of an id (is
this id used somewhere in the document processing?) would suffice.


Daniel Fournier
Marcel van der Boom
2004-05-06 09:20:13 UTC
Permalink
Post by Fournier Daniel
The use of XML for Xaraya templates is a nice idea: during the
development stage, one can validate them with ordinary XML tools.
Unfortunatly, Xaraya_Classic theme default.xt template is not XML
conformant.
Let alone the module templates.
Post by Fournier Daniel
For instance, it uses an XML entity (&xar-baseurl;) to reference the
site base URL. However this entity is not defined within any ENTITY
declaration. How is this entity defined? Is it just a pseudo entity
replaced in the PHP processing of the template?
Yes, the entity is parsed and replaced. The only thing it has in common
with a real entity is the same notation. At some point the
production/generation of those entities could be built into the
compiler, but we're not there yet.
Post by Fournier Daniel
Another XML conformance violation is the DOCTYPE declaration for HTML,
which should come before document root element.
so true, and in fact should not even be in the template directly at all
as far as i am concerned.
Post by Fournier Daniel
Why not use a true DOCTYPE declaration for the template and modify it to
have the right HTML DOCTYPE including the baseurl entity declaration
when compiling the template.
the xar:blocklayout tag was introduced not that long ago, as we are
progressing, things get added along the way. After such a change, we get
a flood of bugreports from people who use the code with that change but
havent updated their templates yet, so change will be slow. But you are
100% right here.
Post by Fournier Daniel
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE xar:blocklayout
[
<!ENTITY xar-baseurl "$xar-baseurl">
]>
<?xar type="page" ?>
....
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
[
<!ENTITY xar-baseurl "http://www.myxarsite.com/">
]>
Either that or we could use an attribute in the blocklayout tag to
denote the generated output (my preference) Remember that the entities
which need declaration are dynamic. The example you gave is a static
one, but we allow things like:

&xar-modurl-module-type-function;

which gets compiled into:

xarModUrl('module','type','function')

to be able to continue this, we would not only need an xml-parser, but
also an entity resolver, both of which we do not have.
Post by Fournier Daniel
Another problem is the multiplication of elements with identical id
attributes. For instance: <td id="leftmenus">. ID attributes have to be
unique in the document. Probably a class attribute instead of an id (is
this id used somewhere in the document processing?) would suffice.
For the "xar:" namespace id's are checked, but because we basically pass
throught everything else verbatim id's in the html space slip through.
But again, you're right.

In short, you are absolutely right on all points raised and this is all
planned for, taking into account the existing compatability problems out
there. Before 1.0 not much will happen in this area. A couple of things
i have been working on already in separate repositories.
--
marcel
Fournier Daniel
2004-05-07 03:32:57 UTC
Permalink
Thnaks for all your answers, Marcel. That makes sense: being new to
Xaraya I'm not (yet) concerned with backward compatibility :-)

Daniel
Post by Marcel van der Boom
Post by Fournier Daniel
The use of XML for Xaraya templates is a nice idea: during the
development stage, one can validate them with ordinary XML tools.
Unfortunatly, Xaraya_Classic theme default.xt template is not XML
conformant.
Let alone the module templates.
Post by Fournier Daniel
For instance, it uses an XML entity (&xar-baseurl;) to reference the
site base URL. However this entity is not defined within any ENTITY
declaration. How is this entity defined? Is it just a pseudo entity
replaced in the PHP processing of the template?
Yes, the entity is parsed and replaced. The only thing it has in common
with a real entity is the same notation. At some point the
production/generation of those entities could be built into the
compiler, but we're not there yet.
Post by Fournier Daniel
Another XML conformance violation is the DOCTYPE declaration for HTML,
which should come before document root element.
so true, and in fact should not even be in the template directly at all
as far as i am concerned.
Post by Fournier Daniel
Why not use a true DOCTYPE declaration for the template and modify it
to have the right HTML DOCTYPE including the baseurl entity
declaration when compiling the template.
the xar:blocklayout tag was introduced not that long ago, as we are
progressing, things get added along the way. After such a change, we get
a flood of bugreports from people who use the code with that change but
havent updated their templates yet, so change will be slow. But you are
100% right here.
Post by Fournier Daniel
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE xar:blocklayout
[
<!ENTITY xar-baseurl "$xar-baseurl">
]>
<?xar type="page" ?>
....
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
[
<!ENTITY xar-baseurl "http://www.myxarsite.com/">
]>
Either that or we could use an attribute in the blocklayout tag to
denote the generated output (my preference) Remember that the entities
which need declaration are dynamic. The example you gave is a static
&xar-modurl-module-type-function;
xarModUrl('module','type','function')
to be able to continue this, we would not only need an xml-parser, but
also an entity resolver, both of which we do not have.
Post by Fournier Daniel
Another problem is the multiplication of elements with identical id
attributes. For instance: <td id="leftmenus">. ID attributes have to
be unique in the document. Probably a class attribute instead of an id
(is this id used somewhere in the document processing?) would suffice.
For the "xar:" namespace id's are checked, but because we basically pass
throught everything else verbatim id's in the html space slip through.
But again, you're right.
In short, you are absolutely right on all points raised and this is all
planned for, taking into account the existing compatability problems out
there. Before 1.0 not much will happen in this area. A couple of things
i have been working on already in separate repositories.
Andy Varganov
2004-05-06 10:36:31 UTC
Permalink
Post by Fournier Daniel
Another problem is the multiplication of elements with identical id
attributes. For instance: <td id="leftmenus">. ID attributes have to be
unique in the document. Probably a class attribute instead of an id (is
this id used somewhere in the document processing?) would suffice.
those IDs are referencing CSS anonymous rules - in a good tradition of CSS they
should not be duplicated, but as you can see in the output they are not.. using
anonymous classes is not quite appropriate from the designer POV, classes should
only be used for 'potentially' multiple instances of the css ruleset on a webpage.

Andy
Loading...