HTML Encoding change -- why?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

HTML Encoding change -- why?

Nevin Pratt
In Seaside 2.3, I developed a rather sloppy habit of occasionally typing
html directly in the #text: or #bold: argument.  Here is an example:

   html text: '<br>This is an example'.

rather than

   html break.
   html text: 'This is an example'.

Sometimes as I typed, the html would just kind of roll off my fingers,
and I would take the above shortcut rather than typing separate lines.

But, in Seaside 2.5, this no longer works.  Instead, a text argument
like the above will be transformed into:

   '&lt;br&gt;This is an example'

Which isn't what I expected.  If I had wanted '&lt;' and '&gt;', I would
have typed it.

Well, I guess I can see value in the automatic transformation, but I can
also see value in *not* transforming it.

Is there a thread somewhere that talks about the pros and cons of making
this change?  What was the rationale for making the change?

Nevin

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: HTML Encoding change -- why?

Jason Rogers-4
If you want to write your own HTML you should send the #html: message.

On 2/14/06, Nevin Pratt <[hidden email]> wrote:

> In Seaside 2.3, I developed a rather sloppy habit of occasionally typing
> html directly in the #text: or #bold: argument.  Here is an example:
>
>    html text: '<br>This is an example'.
>
> rather than
>
>    html break.
>    html text: 'This is an example'.
>
> Sometimes as I typed, the html would just kind of roll off my fingers,
> and I would take the above shortcut rather than typing separate lines.
>
> But, in Seaside 2.5, this no longer works.  Instead, a text argument
> like the above will be transformed into:
>
>    '&lt;br&gt;This is an example'
>
> Which isn't what I expected.  If I had wanted '&lt;' and '&gt;', I would
> have typed it.
>
> Well, I guess I can see value in the automatic transformation, but I can
> also see value in *not* transforming it.
>
> Is there a thread somewhere that talks about the pros and cons of making
> this change?  What was the rationale for making the change?
>
> Nevin
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>


--
Jason Rogers

"Where there is no vision, the people perish..."
    Proverbs 29:18
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: HTML Encoding change -- why?

Nevin Pratt
Ah, I see.  Thanks, Jason.

Of course, this breaks backwards compatibility.  But it is a minor change (among the handful of other changes in Seaside 2.5 that effect backwards compatibility).

No big deal, though.

Nevin

If you want to write your own HTML you should send the #html: message.

On 2/14/06, Nevin Pratt [hidden email] wrote:
  
In Seaside 2.3, I developed a rather sloppy habit of occasionally typing
html directly in the #text: or #bold: argument.  Here is an example:

   html text: '<br>This is an example'.

rather than

   html break.
   html text: 'This is an example'.

Sometimes as I typed, the html would just kind of roll off my fingers,
and I would take the above shortcut rather than typing separate lines.

But, in Seaside 2.5, this no longer works.  Instead, a text argument
like the above will be transformed into:

   '&lt;br&gt;This is an example'

Which isn't what I expected.  If I had wanted '&lt;' and '&gt;', I would
have typed it.

Well, I guess I can see value in the automatic transformation, but I can
also see value in *not* transforming it.

Is there a thread somewhere that talks about the pros and cons of making
this change?  What was the rationale for making the change?

Nevin

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

    


--
Jason Rogers

"Where there is no vision, the people perish..."
    Proverbs 29:18
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

  


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: HTML Encoding change -- why?

Jeremy Shute
> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: HTML Encoding change -- why?

Julian Fitzell
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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: HTML Encoding change -- why?

Jeremy Shute
> So that's why we decided to break backwards compatibility...

That's why you *rightly* decided to break backwards compatibility.  This
way is better.

Jeremy

GPG PUBLIC KEY: 0xA2B36CE5

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside