[Seaside-dev] Seaside 2.9 Package Depenedencies

[Philippe Marschall]

2008/7/30 Julian Fitzell <jfitzell at gmail.com>:
> On Wed, Jul 30, 2008 at 2:12 PM, Philippe Marschall
> <philippe.marschall at gmail.com> wrote:
>> 2008/7/30 Julian Fitzell <jfitzell at gmail.com>:
>>> On Wed, Jul 30, 2008 at 2:03 AM, Philippe Marschall
>>> <philippe.marschall at gmail.com> wrote:
>>>> The dependency of Seaside-Core on Seaside-Adapters-Core is
>>>> unfortunate.
>>>
>>> And it seems I just introduced that one... hmm. What's the reasoning
>>> for having Seaside-Adaptors-Core instead of Seaside-Core-Adaptors?
>>
>> It's not part of Seaside-Core. It's the core the the Seaside-Adapters
>> framework which was supposed to optional. You can use it as a base for
>> your server adaptors but don't have too.
>
> Well any particular adapter should be optional, but how can you use
> seaside with *no* adapter?

There is kind of history behind this. When I wrote the Swazoo 2 server
adapter I discovered that I needed a lot of code that is also in the
Kom server adapter. So I factored it out and moved it into seaside
adapters package. This then served as a base for the Kom hierarchy
cleanup. It is intended as a helper package that should help making a
new server adapter easier, especially since it is split up into
portable and non-portable parts. You don't have to use this, if you
want to write your server adapter from scratch that is fine too.

>>> I
>>> mean WAUrlEncoder already depended on having a codec in general,
>>
>> Only on the protocol. Any class implementing the protocol (4 methods) will do.
>
> Understood, obviously. But then perhaps a NullCodec should be made
> available in a package that we can depend on. To be honest, I don't
> understand the desire to have WACodec outside the core... all it does
> is provide the protocol of those 4 methods.

Yeah. It would probably make sense to pull it in. While we're at it
maybe we can move WAGenericCodec to the Squeak package.

>>> it
>>> just didn't have an actual reference to the generic class. Being
>>> unable to print WAUrl when it can't get at a request context process
>>> variable is also unfortunate.
>>
>> Yes but the request context is needed to get encoding right.
>
> If there is a request whose encoding you are trying to match, sure.
> But the WAUrl is a perfectly useful class that you might want to use
> not within a rendering context and it's also nice to be able to
> interact with them when debugging and they didn't work in an inspector
> before I made that change. I also often get an error returned to the
> browser about "nil not understanding #codec" while developing (can't
> recall if it's when I abort or proceed in the debugger or if it's just
> on low level errors or what...).

The problem is that for anything beyond ASCII you need to have an
encoding. And it doesn't always correlate this the request / page body
encoding. But I see your ease of use point.

Cheers
Philippe