[Seaside-dev] Re: A couple of suggestions/observations ... related
to using the 'Base'
Dale Henrichs
dhenrich at vmware.com
Wed Jun 23 23:49:15 UTC 2010
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
>
More information about the seaside-dev
mailing list