[Seaside-dev] A couple of suggestions/observations ... related to using the 'Base'

[Julian Fitzell]

On Thu, Jun 24, 2010 at 1:47 AM, Dale Henrichs <dhenrich at vmware.com> wrote:
> Maybe defaultDispatcher was the wrongterm to use ... default application is what I'm referring to (I think the method names made it sound like you were setting the default dispatcher ... I don't have the latest code at my fingertips) After loading Magritte-Seaside on top of Base I got an error when I hit http://localhost::8080/...I had to put in the full path to the example ... I think it would be convenient since it is somewhat disturbing to get the error ...

Ok. I'd like Dispatchers to be able to (optionally) display their own
contents (rather than relying on the Browse component) which would
help here. But in the meantime, maybe Magritte could just set itself
as the default when loaded (or check if the default is nil and if so
set it)?

> The problem with deploying the development tools in production is that with all of the initialization being done when loading them you ave to undo a number of things to put your production environment back in shape .... Splitting out the WAInspector components into a pacakage that can be loaded independently from the whole development enchilada would just make it easier to use ... WAInspector is just a component and can be used outside of a Development context (which the object log viewer is doing)... I'm looking for a package split more than a philosophical shift  or introducing additional risk... If there were a package called Seaside-Development-Components (ignoring the package name conflict for a second) that contained the WaInspector component, then that would work just fine for my purposes ... WAInspector doesn't actually rely on any of the Development artifacts so it  is something that _could_ be independent of Development ...

Splitting out the Components feels vaguely arbitrary to me (ie. I have
no idea what we'd call the remaining package and trouble naming is a
warning sign for me) but dependency-wise it looks possible.
WASqueakWalkback has a dependency on WAInspectorHaloPlugin but that
could maybe be resolved (it's using it to get WAHaloPlugin's
#open:onAnswer: behaviour).

Maybe the problem is just that the setup of Development tools happens
on initialization. I guess we could split into
Seaside-Development-Tools and Seaside-Development-Environment or
something and have the latter one do the initialization. Does that
help?

Julian