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

[Dale Henrichs]

After sending the earlier email discussing the 'Base' group for 
ConfigurationOfSeaside30, I started work finishing up the GemStone port 
of Magritte2...

Given that we have a 'Base' group for Seaside, I thought that it would 
be a good idea to see just how much of Seaside Magritte-Seaside itself 
required starting with loading just the 'Base' seaside group.

One thing I found out was that Magritte expects Seaside-HTML5 to be 
present... so that was easy enough to deal with...

Another thing that popped up is that there was no default dispatcher (by 
default:) which is not surprising once you think about it, but loading 
just Magritte-Seaside on top of the 'Base' it would be nice if there 
were a way to register a default 'default dispatcher' ... something like 
what happens with exception handlers so that if nothing else come ins, 
the lone registered component somehow becomes the default ...

The Magritte-Seaside component is actually in Magritte-Seaside-Examples, 
so perhaps the examples should be split out for Magritte2 so that they 
can be loaded separately and then it would make more sense to be 
registering a default 'default dispatcher' directly..

I like the notion of having Magritte-Seaside depend upon the 'Base' from 
Seaside ... Basically a developer would then do something like the 
following for loading into a production image:

   (ConfigurationOfMagritte2 project version: '2.0.5')
     load: 'Magritte-Seaside'.
   (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15')
     load: #('Seaside-Adaptors-FastCGI' ).

and then do the following in a development image:

   (ConfigurationOfMagritte2 project version: '2.0.5')
     load: 'Magritte-Seaside'.
   (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15')
     load: #('Seaside-Adaptors-FastCGI' 'Seaside-Development').

ConfigurationOfMagritte could be replaced with any application that used 
  Seaside and similarly load the minimal set of Seaside using explicit 
dependencies from within the configuration .. then the development 
pieces could be incrementally loaded in the development image...

Fnally, for GemStone, I have implemented an ObjectLog viewer/editor 
component ... in production, it is convenient to have the object log 
viewer installed (using authentication), however, the object log viewer 
uses WAInspector which is currently packaged with Development which 
installs (and initializes) a bunch of other things I don't want in 
production ... it would be nice if WAInspector were refactored to be 
usable in a production environment (no tool bar inherited from WATool) 
... this would involve moving WAInspector to Seaside-Tools-Core and then 
  implementing a development version that 'mixed in' the toolbar css and 
friends... In looking through the other development components I don't 
see any other components that would be as useful to have in a production 
installation...

Dale