Hi,
I think - like Ross - than Views are a very clean solution to many
things.
My main problem with skins is exactly what you said :
* Source code may be duplicated depending on where it is used,
* Granularty is complex problem which do not interest skins. The
result is that we have to copy large templates in order to change
a small part
o for instance I had to copy the whole *site* template of the
pelt skin in order to add a line in my header...
The definition and the use of contracts is not - at the moment -
very clear in my mind but I 'm sure it is way we have to work.
Hope a simple documentation will be writen soon !
Cordialement,
Cyriaque,
Thorsten Scherler a écrit :
hello devs,
I just work on the i18n integration for pelt and crossed again the whys
for using views. ;-)
The case is that the site2xhtml.xsl has a lot of repeating code. For
example the "last publish"-contract can be found 2 times in the code:
@@ -236,9 +241,9 @@
<xsl:comment>+
|end Endtabs
+</xsl:comment>
- <DEFANGED_script language="JavaScript"
type="text/javascript"><![CDATA[<!--
- document.write("Published: " + document.lastModified);
- // -->]]></script>
+ <DEFANGED_script type="text/javascript"><![CDATA[<!--
+document.write("]]><i18n:text >Last
Published:</i18n:text> <![CDATA[ " + document.lastModified);
+// -->]]></script>
</div>
<xsl:comment>+
@@ -278,9 +283,9 @@
<div id="footer">
<xsl:comment>+
|start bottomstrip
- +</xsl:comment>
+ +</xsl:comment>
<div class="lastmodified"><DEFANGED_script
type="text/javascript"><![CDATA[<!--
-document.write("Last Published: " + document.lastModified);
+document.write("]]><i18n:text >Last
Published:</i18n:text> <![CDATA[ " + document.lastModified);
// -->]]></script></div>
This is not the only contract that is double in the code. The problem
with that is that I need to search the code for each caption and
senseless repeat the maintainment step of adding the <i18n:text/>-tags.
Now we can enhance the maintainment for the future and we started to
give this code snippets contracts names. This naming enables us to keep
the contract separate from the position code itself. In xsl you would
simply do:
1) replace the script by <xsl:call-template name="last-published"/>
2) add <xsl:template name="last-published">
<DEFANGED_script type="text/javascript"><![CDATA[<!--
document.write("]]><i18n:text >Last
Published:</i18n:text> <![CDATA[ " + document.lastModified);
// -->]]></script>
</xsl:template>
This allows us in a next maintainment just change the code of
<xsl:template name="last-published"/> and apply it in any position where
it is placed. Now this refactoring of the site2xhtml.xsl is exactly what
I am doing in views.
In the viewHelper.xhtml plugin I
added /resources/templates/last-published.ft.
In this file you can find:
<xsl:template name="last-published-body">
<DEFANGED_script type="text/javascript"><![CDATA[<!--
document.write("]]><i18n:text >Last
Published:</i18n:text> <![CDATA[ " + document.lastModified);
// -->]]></script>
</xsl:template>
The only different between the site2xhtml.xsl and the ft is the name
addition "-body". That leads to the template attribute @body="true" and
@head="false". In xhtml a contract can add content to the <body/> or/and
<head/> part of <html/>.
/*sidenote*/
We decided to drop the css definition within the template in favor of a
default set of css that will come with the view. I will delete the
corresponding code soon. CSS stylesheet patches very welcome. ;-)
The above said prepares to answer the question why the development with
views is more efficient in maintainment and more flexible in comparison
to "old fashion skins" in the long run.
In the site2xhtml.xsl there are fixed places for the contracts. There
are some mechanism like e.g.:
<xsl:if test="$config/search and not($config/search/@box-location =
'alt')"/> to influence the output but a skin will never be that flexible
to place a contract where ever you want in the output.
There is where the new forrest:view config-DSL comes in handy. Instead
of defining alternative positions in the skin (which normally as well
means to extend the skinconf.dtd) it lets the user/skin-developer decide
where to place the contracts with a configuration file.
I had to extend the default.fv with a new line:
<forrest:contract name="last-published"/>
to activate the new contract in any place of the output that I want. As
well it is possible to place the contract as much as I want.
Refactoring site2xhtml.xsl has similarities of generating contracts for
the view plugin. The biggest different is that we extract the code
snippet in another file and not the site2xhtml.xsl and winning the
flexibility of placing it where we want.
That prevent as well the situation where you have to "rip parts out of
the skin" if you do not want them. In views you just do not use the
contract and it will not be outputed.
salu2
