[Seaside-dev] codecs overhauled (again)

Philippe Marschall philippe.marschall at gmail.com
Tue Jun 9 09:29:10 UTC 2009


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.

Cheers
Philippe


More information about the seaside-dev mailing list