[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