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

[Dale Henrichs]

HTML5 was included because of a Magritte requirement ... it's not part of base...

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

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

Dale
________________________________________
From: seaside-dev-bounces at lists.squeakfoundation.org [seaside-dev-bounces at lists.squeakfoundation.org] On Behalf Of Julian Fitzell [jfitzell at gmail.com]
Sent: Wednesday, June 23, 2010 5:22 PM
To: Seaside - developer list
Subject: Re: [Seaside-dev] A couple of suggestions/observations ... related to  using the 'Base'

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
>
_______________________________________________
seaside-dev mailing list
seaside-dev at lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev