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

[Dale Henrichs]

If you want to try this out yourself, you can do:

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

in a Pharo image and play around... BTW, both 3.0.0-alpha5.15 and 2.0.5' 
are under development and subject to change (I haven't run through all 
of the test loads, yet for example) and I will be makign changes at the 
GemStone level since I'm still refactoring the exception handlers ...

Dale

Dale Henrichs wrote:
> 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
>