Today I have finished committing my upgrade to Kettle's pathing and
routing infrastructure... this used to be operated by a number of fairly
incomprehensible directives in the JSON configuration files which were
really only working "by accident" - as reported in
http://issues.fluidproject.org/browse/ENGAGE-216
our URLs at least in the development environment have been entirely
wrong for some time and the app only functioning by means of the natural
censoring being performed by the container.
This rewrite should also have resolved related issues ENGAGE-193 and
ENGAGE-214 although these harder to verify since we have no outstanding
markup which exercises this at present.
Some benefits of this new system are considerable simplification of
configuration - the path rewriting in the templates "just works" without
use of the highly mysterious "rewriteSource" property in the mount table
, nor the "baseDirDepth" property which mysteriously appeared in trunk
on Monday, breaking the nightly :)
However, one important consequence of this change is in the treatment of
"false URLs" - it had formerly been possible to get away with writing
markup like this:
<a class="fl-table-cell" href="../exhibitions/browse.html?db=mccord">
<img class="fl-icon"
src="../../../../fluid-engage-core/components/home/images/Exhibitions.png"
alt="Exhibitions icon" />
</a>
in this case, "../exhibitions/browse.html?db=mccord" is a "false URL" -
it does not refer to anything which actually exists in the filesystem
related to the template but just happens to be "magically correct" once
the template is mounted in the app (which, naturally, could only occur
at one position given the fragility of this system).
As of last night, these "false URLs" will actually be interpreted by the
template rewriting machinery which will attempt to map them onto the
resource that would have been designated by the path in the served
filespace... which is usually nonexistent. This is actually the same
semantic that was historically operated by RSF, but had been disabled in
the renderer since it seemed better for performance reasons not to try
to operate all the details of the "StaticComponentRenderer" system that
used to exist. Unfortunately to deal with, in particular, ENGAGE-193, it
is necessary to restore this behaviour which was generally correct.
In order to protect them from rewriting, these "false URLs" need to be
marked up to the template parser in some way - right now, the most
direct way of doing this is to add the annotation rsf:id="scr=null" in
the template - which is clearly a bit unsatisfactory in this modern world.
This oddity is highlighting a current deficiency in our framework, that
we have no means of abstracting over the system of internal URL
references - in historical RSF this was done by means of the
"ViewParameters" system and the special component UIInternalLink, which
we currently have no equivalents of in Kettle/the Javascript renderer.
This is something which has been on the cards for a while, since our
current URL mapping system is pretty clunky and pedestrian, but there
won't be time to deal with this before the current release.
At the very least, however, these "false URLs" should become identified
with a cutpoint as a prelude to the fact that we want them eventually to
correspond to components - and perhaps we can add some little
"bolt-on" to Justin's growing set of utilities which pairs them up with
a cutpoint attaching them to scr=null.
These sound like a good set of issues to talk over at our dev meeting
tomorrow morning.
Cheers,
A.
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
