27 Feb
2011
27 Feb
'11
10:18 p.m.
On 02/27/2011 01:00 PM, Caleb James DeLisle wrote:
When I was looking for places where
hasProgrammingRights is called, I found calls to
c.x.x.api.Context.get() in the templates. I discovered that there is code in the
templates which
implicitly calls $xcontext.get('something') by calling $xcontext.something where
there is no
function Context.getSomething(). Since this is so easy and there is no way to know that
anything is
wrong since Context.get() returns null if you don't have PR, I am proposing that we
do away with the
practice of implicitly referring to functions in $context entirely.
I don't quite agree, it should be allowed.
$xcontext.tocData
^-- this line is broken entirely, it maps to context.get('tocData') but the line
is:
#set ($xcontext.tocData = $tocData) which is simply invalid and I can't even
figure
out what it would do.
No, it's not invalid. In this case the line is equivalent to
$xcontext.put("tocData", $tocData). Similar to the way $something.prop
is resolved at runtime as one of getProp(), getprop(), get('prop'),
isProp(), #set($something.prop = $value) also searches for setProp(),
setprop(), and finally put("prop").
$xcontext.wiki,
$xcontext.wiki,
$xcontext.wiki,
^-- Maps to $xcontext.get('wiki') I think this is the source of most of the
messages and since it
appears to be relatively new code, it convinces me that the $context.blah pattern is
simply
unsafe and should be abandoned at least for the xcontext object.
I think this is wrong, it should be $xcontext.database (which itself is
a bad name and should be deprecated in favor of a real
xcontext.getWiki() which returns the current wiki name.
I would like to fix these now and establish a best
practice of avoiding the use of these in the
future for $xcontext. I myself avoid this pattern entirely but I do not have a compelling
reason to
propose it as a best practice except for $context.
It's a bit faster, since velocity tries the methods in a specific order
until it can find one that exists and matches the current parameters.
But it's faster and easier to read if the shorthand is used.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/