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.
