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

[Dale Henrichs]

Julian Fitzell wrote:
> 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)?

I suppose this is the best answer ... although as I've touched on below, 
it would be nice if the examples were packaged separately so that one 
could control whether or not you even wanted the application registered 
in the first place ...

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

Splitting out all of the development components would be arbitrary ... 
I'm just suggesting that if the Inspector component were split out 
separately then it could be easily used independently of the rest of the 
Development code ... I'm not interested in Halos, etc. just WAInspector 
... as I said in an earlier message it really didn't look like any of 
the other development components were as generically useful as the 
Inspector....

As for where it could be stashed, perhaps Tools-Web is a better home 
for WAInspector ... it _is_ a web-based tool much like the configuration 
editor ... both are unsafe in production without authorization, but 
occasionally it makes sense to install them in production.

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

If WAInspector can't find a home outside of the Development stuff then I 
suppose ... but does it really make sense to break up Development into 
multiple pieces for initialization when the single WAInspector compnent 
could be easily moved to another package (like Tools-Web)?

-----
At the risk of opening another can of worms ... as I look at Tools-Web 
(especially with Pharo included) ... there seem to be an awful lot of 
basically unrelated tools lumped into a single package ... If you want 
to add VNC to control, you end up with nearly a dozen other components 
loaded (and initialized?) ... For these guys it might make sense to 
package each independent tool separately so that a developer can pick 
and choose what he wants in his application ... the presence of 
initializers is the sticking point ... the Seaside-Widgets can be 
loaded, but no applications are automatically registered...Each of the 
tools in Tools-Web automatically registers on load, which is a good 
thing if you could individually load the tools...

Tools-Web _could_ be turned into a group with individual packages for 
each of the independent tools, then a developer could load the whole kit 
and kaboodle into his development environment, but then pick and choose 
which tools to include in production...

Keep in mind that this discussion is related to the automatic running of 
initializers (which is real convenient when you are able to load exactly 
what you want and a pain when you have to load the kitchen sink to get a 
sponge:). Presumably there are alternate schemes for picking and 
choosing which comonents you'd like installed as applications, but why 
invent a new mechanism when the initialize works fine ... it's just a 
matter of packaging things up into "sensible" units...
-----

Dale