This breaks the calls to castValue() and formatValue() immediately
below. It is also the root cause of
<http://open.silverstripe.org/ticket/7581> and
<http://open.silverstripe.org/ticket/7590>.

I guess the idea behind this escaping (added as a part of the redesign
in
<https://github.com/silverstripe/sapphire/commit/70d5ffefdd12eb3e69f40...>)
was to prevent XSS problems, but I think it is not feasible to just pass
all data through raw2xml, and especially not at this very early stage.

One good example are images, where the grid field should contain an img
tag for the thumbnail. In my opinion, it would be important that
$summary_fields can contain definitions like MyImage.CMSTHumbnail or
MyTextField.FirstSentence.

What are your thoughts about this? Where should the escaping happen? How
should the code know what not to escape?

Yours
Jakob

Yes! I was just going to post the same question!

Ya i kinda miss the betas for that, it was so cool to be able to just add a
column Image.CMSThumbnail for example and it would render the image :(.

i was bugging the core team the other day about this same matter. lets hope
they found a solution soon :)

El miércoles, 11 de julio de 2012 13:31:14 UTC-4, Jakob Kristoferitsch
escribió:

I would have to agree Jakob, it is kind of one of those big not show  
stopper issues. Kinda disappointed to see it pushed to 3.0.2, seems like  
one of those things that could be slipped in before the final of 3.0.1.  
Especially since your fix Jakob seems to be working well and is a good  
solid fix.
On , Jakob Kristoferitsch <ja...@kristoferitsch.name> wrote:

Sorry guys as Hamish points out on the ticket comment there wasn't time -
hopefully you'll agree there's been a lot of activity for 3.0.1 - look at
the length of the change log - and the work on the 3.0.x line will continue
to be high for a while...

http://doc.silverstripe.org/framework/en/3.0/changelogs/rc/3.0.1-rc1

Cheers,
Sigurd.

Ya makes complete sense to me, its just unfortunate. Oh well hopefully
3.0.2 will be just around the corner like 3.0.1 was :)

Yup - and keep sending in those bug reports and/or pull requests ;)

Sig

On 26 July 2012 00:18, UndefinedOffset <edchip...@gmail.com> wrote:

I accept that it's not part of 3.0.1 (thanks to Hamish for the detailed
explanation), my next goal is to get it into 3.0(.2) as soon as possible.

To do that, I would really like to start a discussion about where
escaping should happen and what code paths should be allowed to bypass it.

Unfortunately, this seems to be a bug where everyone agrees that it is
important, but nobody wants to make any decisions ;-). My proposed fix
is publicly available and I have explained the advantages and
disadvantages that I see. I now would like to get feedback on my
proposal as well as alternative ones.

I think the problem of where to escape applies to a lot of different
places, which is why I want to have the discussion about it in public.
I am actually quite fond of my approach - it might not be the best fit
in this situation, but I think the general direction is correct: Escape
everything, except for objects that promise to do that themselves (by
providing forTemplate(), XML() or something like that).

The dogmatic approach would be to provide an object that wraps a string,
knows what needs to be escaped and provides the methods needed to escape
it for XML output (as well as DB and any other output). The framework
would then never directly output strings, instead relying on these
wrapper objects.

Yours
Jakob

I would expect it to operate in the same way as the rest of the framework
escaping - by default escape strings but not objects. Then allow the user
to use the setFieldCasting method on GridFieldDataColumns to specify if a
string should not be escaped:

$columns->setFieldCasting(array('UnescapedField' => 'HTMLText'));

Andrew Short.

On Wed, Jul 25, 2012 at 11:19 PM, Jakob Kristoferitsch <

Ok, that goes in the direction I am implementing. I still think it is
best to call forTemplate on the Object at the end, since I read the
comment to getColumnContent to mean that the return value will be
directly inserted in the output:
 > @return string HTML for the column. Return NULL to skip.

 > Then allow the user to use the setFieldCasting method
 > on GridFieldDataColumns to specify if a string
 > should not be escaped:
 >
 > $columns->setFieldCasting(array('UnescapedField' => 'HTMLText'))

That is a nice way to handle this problem, but to enable that kind of
behavior I think that the call to castValue() should then be after the
call to formatValue (maybe even the last one). This would make it
possible to use the example from setFieldFormatting:
 > "myFieldName" => '<a href=\"custom-admin/$ID\">$ID</a>'
In combination with setFieldCasting this would then output the link
without escaping it.

Should I rearrange these calls or is there a reason for the current
order (I guess there is...)?

Thanks for your input,
Jakob
Am 25.07.2012 15:31, schrieb

Yours,
Jakob