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

[Julian Fitzell]

I'm not sure that HTML5 should be in Base, but I'm not sure if you
were suggesting that. It seems quite easy for Magritte to depend on
Base + HTML5.

Why is there no default dispatcher? WAAdmin class>>#defaultDispatcher
should result in lazy initialization. Or is Tools-Core not currently
in Base?

Agreed that Magritte should be able to depend (more or less) on Base
(+ additional features it may use).

As for WAInspector, our goal with Seaside-Development was to put in
there all the sketchy stuff that might allow someone to view/monkey
with your image. That way, by not loading it, you were minimizing the
risk in a production system. So in that sense, I have a concern about
putting WAInspector in Tools-Core (actually, Tools-Core is not the
right place because it's supposed to be non-UI - maybe Tools-Web).
That isn't non-negotiable :) , but before we go down that route, two
other thoughts on first reading:

1) Are you sure the ObjectLog viewer isn't a development tool? Many of
the delevopment tools might be useful in a production image with
authentication (or on a different adaptor listening on a different
interface). There's nothing saying you *can't* deploy with the
development tools loaded.
2) What about leveraging WAPlugin in your ObjectLog viewer so that
loading the development tools adds the ability to inspect?

Julian

On Wed, Jun 23, 2010 at 4:41 PM, Dale Henrichs <dhenrich at vmware.com> 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
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>