[Seaside] HTML Encoding change -- why?
Julian Fitzell
julian at beta4.com
Tue Feb 14 20:59:19 UTC 2006
Well, the argument was that if you have data in the database or
something that contains <, >, or even UTF-8 characters, they may need to
be encoded. And since this could be getting output through #tableData:,
#paragraph: or any other of a large number of methods, we wanted that to
happen at the highest level so they all benefited (and could also be
easily changed to use different character sets, etc). We used to have
#encodeText: by the way, but that seemed unnecessarily long-winded for
the common case.
Outputting text that might or might not have characters that need
encoding seemed to be by far the more common case so we added a new
method to deal with the occasional case where you need to output raw
html. It also seemed like an easy upgrade since you just need to
replace all your #text: calls with #html: calls if you want the old
behaviour.
#text: just seemed like the right name for the encoded version and
#html: made more sense for the unencoded version. It also seemed like
we would *improve* the situation for many users who were already using
#text: to output data.
So that's why we decided to break backwards compatibility...
The End :)
Julian
Jeremy Shute wrote:
>>Of course, this breaks backwards compatibility.
>
>
> Like a bandaid. *Rip!* Right off...
>
> I want to know when Seaside is going to do encoding and when it isn't.
> #html and #text seems the plainest distinction possible.
>
> Jeremy
>
>
>
> GPG PUBLIC KEY: 0xA2B36CE5
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
More information about the Seaside
mailing list