[Seaside-dev] Seaside 2.9 Package Depenedencies

[Julian Fitzell]

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?

>> 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.

>> 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...).

It's all very well for classes to be pulling data out of a request
context if it exists, but if there is a valid default behaviour, I
think they should use that when they can't find a context. Otherwise
everything just gets very fragile and complicated to experiment with.
You can't even experiment with a WAUrl instance in a workspace without
figuring out how to wrap it in a RequestContext and so on...

If you feel strongly that the null codec and abstract superclass
should not be core, perhaps we could modify WAUrlEncoder>>nextPutAll:
to ignore the encoder if it is nil and just output the string?

Julian