Thinking aloud on in-browser development languages and tools.
In the concept of 3-tiered HTML page design ( structure/HTML, presentation/CSS, behavior/JS ) none of tiers has given good enough OOP or aspect-OP capabilities I get used to. Could be any language be used on all tiers? Sure, yes.
JS is capable of all. Could not see much of positive sides besides of
❤ sufficient to achieve the goal.
❤ Weakly support of OOP.
☢ lack of strict definitions and validation
☢ Weak interaction with other tiers (css&html). Browser does not support sufficient native interfaces to be used by JS:
§Do you recall how and why getComputedStyle used? Browser does not give API for CSS parameters get and set. Even most popular layout computation routine get box dimentions needed quite CPU expencive work around.
§Structure/HTML dom tree also suffering of lack support on JS level. No transactional and detached/group operations. Each dom node operation accomplished by layout recalculation, while that should be explicit function to finalize series of dom changes.
CSS covers just own tier and almost none of others. IE behaviours do not count since absent in other browsers.
HTML tags. Interesting beast.
❤ Has limited support on all tiers. Styles as inline attribute and result of HTML structure. Behavior as inline scripting and tags( reload meta, MARQUEE, animateTransform, etc. )
☢ Obviously, nothing toward OOP or any serious modular development. IFrame or HTC do not count.
HTC need to be highlighted as BEST solution for HTML modularization on ALL page tiers(structure,layout,behavior). Sadly it did not became a standard even with effort to be part of W3C.
FLASH, Silverlight, Java are just proprietory plugins and have no support on all 3-tiers.
XSL till 2006 was not available in major browsers. Not the issue since.
Has no direct support for either of 3 tiers. But:
❤ natively capable to use any natively supported languages. HTML as structure, behaviors as JS, layout as CSS
❤ not to mention the mix of all 3 for efficiency.
❤ there is no more need to separate tiers for either development or efficiency.
❤ new higher level entities could be introduced on native level: themes, languages, etc. AspectRule (see XSL pipeline implementations ) is one of them.
☢ no frameworks ( working on one)
☢ no developers ( need HTML stack and XSLT in same hands )
Working on XslAspect, I found the need to define own language for "Aspect" rules. I.e. what(rule), where(in model) and when(environment) should be applied. The thing is that the rule should be functional on any point of delivery chain: back-end, before DOM loaded in browser, in run-time. From another side, it should have OOP and AOP capabilities. XSL has all needed, but for syntax makes me uncomfortable. So there is a dilemma: should be new(or some existing) XML-based language invented/used or use old-fasioned XSL for things it is not meant to be ( like methods definition ).
Since XslAspect uses XSL templates, they also need to be OOP capable. ( AOP has XSL nature anyway ). If that will be done, than invention of new things is not necessary. I guess. And even if some new features need to be added, there is still a way to alter XSL with own namespace or add the data into XSL code.
To make the OOP match, it would be wise to make basic OOP stuff defined in XSL terms:
o deployment or source module (group of files). Not OOP stuff, but still needed
o package/namespace ( to separate "classes" )
o Type/Class
o Object
o Method
o Parameters
o return values
Than AOP things. But the join/attach points will define not just what and where the code should be applied but also the (server, browser, runtime) environment and model peaces.
At our disposal XSL has:
· template mode.
· template name.
· template match filter. Which is good for model navigation.
In addition in XSL could be used:
o XslAspect namespace to define own attributes on
§rules,
§xsl:stylesheet as grouping tool
o folder and file name convention
o embedded xml with own namespace
In general, it would be better to use as much native XSL stuff as possible and as last resort - own namespace.
Procedural vs AOP.
Another problem - developer convenience in procedural programming. Aspect assumes applying of rules all instantly and on whole model.
Which is quite different than sequential step-by-step execution. While the efficiency of parallel execution in AOP is not under question, the order of operations and their encapsulation in XSL is not developer and data-driven dev-t friendly: rules applied to same data could be spread in modules and there is no dependency to make strict order. In XSL that dependency could be done on data level by RuleSet ( embedding XML with recurrently enclosed rules ). Usually rules are quite simple (do not confuse with implementation). That way 1st implementation of XslAspect has been done. Another name for such use data processing is pipelining. Result of XSL processing is the source data for further processing.
Is there native XSL way of strictly define the sequence and enclose-dependency?
Sure, there are few ways in addition to RuleSet. Question is, what is more convenient?
· xsl:call-template with parameters. Parameters are calculated first. The parameter value could be the call to another template.
· xsl:apply-template has ability to pass parameters. Unfortunately not cross-browser capable. (or it is in modern ones?)
· Blend input with RuleSet and use complex filtering in xsl:apply-template making select on original data set AND on joint RuleSet.
Actually all methods in framework could be equal and transformed one into another during platform-targeted packaging. So no actual restrictions are in place, just developer's convenience. Speaking of which, lets compare 3 approaches:
· RuleSet
<xa:AcpectRule aspectName="ScrollableTable" >
<xa:AcpectRule aspectName="SortableTable_UI" >
<xa:AcpectRule aspectName="SortableTable_DataSort" >
<xa:sort colNum="2" order="ascending" data-type="text" />
<xa:sort colNum="1" order="descending" data-type="text" />
<xa:AcpectRule aspectName="TestTable" />
</xa:AcpectRule>
</xa:AcpectRule>
</xa:AcpectRule>
· xsl:call-template
It is definitely native XSL. Bulky at least.
<xsl:template name="AspectRule1">
<xsl:call-template name="ScrollableTable">
<xsl:with-param name="data" >
<xsl:call-template name="SortableTable_UI">
<xsl:with-param name="data">
<xsl:call-template name="SortableTable_DataSort">
<xsl:with-param name="data" select="."/>
<xsl:with-param name="Sort">
<xa:sort colNum="2" order="ascending" data-type="text" />
<xa:sort colNum="1" order="descending" data-type="text" />
</xsl:with-param>
</xsl:call-template>
</xsl:with-param>
</xsl:call-template>
</xsl:with-param>
</xsl:call-template>
</xsl:template>
· xsl:apply-template. How to to make the match reference only to the select with 2 nodes(data & rule) and access data from both. It could be done by mode but it will exclude the use of mode for other purposes (like define the module). From another side why module name should differ from aspect rule name? Another problem is pipelining. To make it work apply-template should be called from parent.
<xsl:template mode="AspectRule1_asApply">
<xsl:variable name="d1">
<xsl:apply-templates select="." mode="AspectRule2_asApply"/>
</xsl:variable>
<xsl:apply-templates select="$d1" mode="ScrollableTable" />
</xsl:template>
<xsl:template mode="AspectRule2_asApply">
<xsl:variable name="d1">
<xsl:apply-templates select=" . | $sort " mode="SortableTable_DataSort"/>
</xsl:variable>
<xsl:apply-templates select="$d1" mode="SortableTable_UI" />
</xsl:template>
...
It is obvious to see that AspectRule is shorter and more readable. Note that in all implementation the result of previous processing used as an argument for following one. XSL 1.0 is strictly prohibiting that. But with some tricks and magic it could be worked around on all browsers.
The performance impact which you could see on additional data processing could be relocated to packaging routine, that way xsl:call-template will be generated and delivered to client instead of AspectRule.
In terms of native/interpreted languages the xsl:call-template is natively compiled and AspectRule is the interpreted scripting.
