On 1 Aug 2011, at 11:08, Mos wrote:
> > There needs to be a more detailed review of the problem because as Stéphane said, its too easy to bypass default codec - and we've seen people use <%= specifically for that case.
>
> I don't see a problem with <%= %>. It's ok to use it in the exceptional cases if no html-encoding should be applied (check my blogpost). Other way around: Having a feature like <%= => is a requirement to make the default-html-codec flawless.
>
> >The other reason is that default codec is a complete anti-pattern for plugins. Having the app able to change the default codec at will means that all plugins have to assume nothing about default codec and ALWAYS override default codec themselves in every GSP.
>
> That has nothing to do with my suggestion to change the default in Grails 2.0.
> And indeed I think a plugin should not(!) assume anything about the defaullt codec of the application.
> In general a plugin should work regardless of the default codec.
> Only in special cases, e.g. html-ouput or plain-text for emails, a plugin should override the codec themselve in the GSPs.
>
Yeah, but what I mean is, that there is a wider issue to be discussed / established here. It's worth having a full discussion about this because - who knows - default codec as a concept may not be needed after all.
For example with plugins, you have to set default codec to html or none explicitly in every GSP anyway - and fact is most plugins don't (I know none of mine do). So there is a big legacy issue here.
Setting default codec to html on new projects will break an awful lot of plugins for people out of the box. This doesn't mean it is not a valid approach, but it has a high cost associated currently.
We've had a lot of discussions about this, and evolved thinking, forgotten, and re-remembered and forgotten again :)
The core problem is that the GSP author (unless they are also the app author, which is not always the case) has no clue what codec will be applied to an EL value, unless they put a directive at the top of their page. This will lead to defensive programming and negate the entire value of default codecs because every GSP will do a "codec reset". (think CSS reset)
The codec in force needs to have some visibility, and it needs to be possible to switch mid-page.
I think my most recent plan/idea in this regard was:
* Add "encodeAs" or "codec" attribute to the GSP tag mechanism, so it is automatically applied to any and all tags with no effort from the tag author. We already have encodeAs support on a few tags, but it is explicitly added. Example:
<script …>
var url = "${g.createLink(controller:'book', encodeAs:'JavaScript')";
</script>
* Add an "encode" tag namespace for blocks of content:
<encode:html>
This is where I put all my unsafe ${userName} and ${email} stuff,
but what happens when we include a template or other tag content with g:render/include?
Surely all should be escaped.
</encode:html>
* Add a way for the default ("current") codec to be changed temporarily, e.g. inside the implementation of another tag:
<r:script>
var url = "${g.createLink(controller:'book')";
</r:script>
When you're in a tag that explicitly renders a specific type of content e.g. JavaScript from g:javascript/r:script there is zero point in the user specifying the codec to use - it should be automatic. So e.g. the r:script implementation should be able to pass a codec name to the body() invoke method and all the EL evaluations within that body block are encoded with that codec by default. So basically each tag body would have a default codec passed into it, or default to codec of the outer body if there is one.
Hopefully this makes some sense…
~ ~ ~
Marc Palmer
Freelancer (Grails/Groovy/Java)
Founder @
http://noticelocal.com | Developer @
http://weceem.orgMember @
http://spottymushroom.com | Contributor @
http://grails.orgTwitter:
http://twitter.com/wangjammer5 | Resumé:
http://www.anyware.co.uk/marc/Blog:
http://www.anyware.co.uk | Grails Rocks:
http://www.grailsrocks.com---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Locked
