[Seaside-dev] codecs overhauled (again)

Julian Fitzell jfitzell at gmail.com
Tue Jun 9 15:53:14 UTC 2009


On Tue, Jun 9, 2009 at 2:29 AM, Philippe
Marschall<philippe.marschall at gmail.com> wrote:
> 2009/6/7 Lukas Renggli <renggli at gmail.com>:
>>> I know this is my agenda item I keep pushing but I do think it will
>>> help users understand what input and output they should be expecting.
>>> I can try to find time to do this if you don't want to but I thought
>>> I'd bring it up again since you were in there anyway.
>>
>> Yeah, I think that would make it much more clear what actually
>> happens. Other web application frameworks use the same terminology of
>> external and internal encoding.
>>
>>> Also, on another note, do we not want to keep tests that explicitly
>>> test WAGenericCodec? I see that it's nice to have generic UTF-8 tests
>>> that just test that there is *some* codec that will do the conversion
>>> but doesn't it still make sense in the Squeak tests to make sure that
>>> the generic codec is functioning properly? Right now the tests all use
>>> "WACodec forEncoding:" which might not even return a WAGenericCodec.
>>
>> I think we had this discussion already a while ago? If not ...
>>
>> I dislike the complexity with all these strings naming encodings and
>> that we enforce the presence of certain codecs. This just makes
>> porting unnecessary hard. I found the approach with subclasses that
>> represent the different encoding pairs much more elegant
>> (object-oriented), the only default being present a null codec.
>
> The problem is that we actually need utf-8 for a lot of URL tests as
> well. Currently they were referencing WAGenericCodec but not
> instantiating it forcing porters to copy and paste the code.

Yes, I agree we basically need to count on UTF-8 support. Though lukas
points out correctly that Seaside would work fine without it as long
as URLs only have ASCII characters less than 127 so I can see an
argument for allowing it to fallback somehow. Still, I don't see
having UTF-8 support as onerous for any platform at the moment so that
doesn't really seem like a big issue.

Julian


More information about the seaside-dev mailing list