[Twisted-web] 'mapping' renderer must not use 'slot'

[Sridhar Ratna]

I will put it shortly.  Imagine a mapping type like this ..

map = {
   '1': 'ordinary_string_suitable_for_slot', # simple value
   '2': [ {4:5}, {6:7} ] # complex value
}

If data_foo returns the above dict, the usual way to render it is
using render="mapping". (we assume perfect decoupling between logic
and presentation)

But 'mapping' renderer uses 'slots'.  'slots' could handle only the
first value (keyed '1'), but not the second value (keyed '2') in the
dict.  That is 'slots' cannot handle complex values like [ {4:5},
{6:7} ].  In this case, the list should be rendered using 'sequence'
renderer.  But the 'sequence' requires 'data' and 'slot' deals with
presentation.  Thus is no (decoupled) way to render the above dict
(map) say.  The best one could come up with is

    <div n:data="foo" n:render="mapping">
        <h2><n:slot name="1"/></h2>
        <!-- <p><n:slot name="2"/></p> - throws exception requiring
          flatterner for the dict (or any object if it is used -->
        <!-- <p>In <n:slot name="tags"><ul render="sequence">
            <li n:pattern="item" n:render="tag"></li>
        </ul></n:slot></p> isn't a right syntax .. as n:slot takes care of
        presentation and not data-->
    </div>

For me, the perfect solution to this problem seems to be using
'pattern' instead of 'slot' for the 'mapping' renderer.  The only
advantage of 'slot' to 'pattern' is simplicity of use, but it
introduces some restrictions as we just saw the in the above example.

PS: 'mapping' renderer is just one example, with which I met the conflict.

-- 
Sridhar Ratna - http://srid.bsdnerds.org