Pathing and routing work - now ready in trunk - note on "false URLs"

[Antranig Basman]

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.