A couple of suggestions/observations ... related to using the 'Base'

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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

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

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 <[hidden email]> wrote: _______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

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 <a href="http://localhost::8080/...I">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: [hidden email] [[hidden email]] On Behalf Of Julian Fitzell [[hidden email]]
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 <[hidden email]> wrote: _______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Thu, Jun 24, 2010 at 1:47 AM, Dale Henrichs <[hidden email]> wrote:
> 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 <a href="http://localhost::8080/...I">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 ...

Ok. I'd like Dispatchers to be able to (optionally) display their own
contents (rather than relying on the Browse component) which would
help here. But in the meantime, maybe Magritte could just set itself
as the default when loaded (or check if the default is nil and if so
set it)?

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

Splitting out the Components feels vaguely arbitrary to me (ie. I have
no idea what we'd call the remaining package and trouble naming is a
warning sign for me) but dependency-wise it looks possible.
WASqueakWalkback has a dependency on WAInspectorHaloPlugin but that
could maybe be resolved (it's using it to get WAHaloPlugin's
#open:onAnswer: behaviour).

Maybe the problem is just that the setup of Development tools happens
on initialization. I guess we could split into
Seaside-Development-Tools and Seaside-Development-Environment or
something and have the latter one do the initialization. Does that
help?

Julian
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Julian Fitzell wrote:
> On Thu, Jun 24, 2010 at 1:47 AM, Dale Henrichs <[hidden email]> wrote:
>> 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 <a href="http://localhost::8080/...I">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 ...
>
> Ok. I'd like Dispatchers to be able to (optionally) display their own
> contents (rather than relying on the Browse component) which would
> help here. But in the meantime, maybe Magritte could just set itself
> as the default when loaded (or check if the default is nil and if so
> set it)?

I suppose this is the best answer ... although as I've touched on below,
it would be nice if the examples were packaged separately so that one
could control whether or not you even wanted the application registered
in the first place ...

>
>> 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 ...
>
> Splitting out the Components feels vaguely arbitrary to me (ie. I have
> no idea what we'd call the remaining package and trouble naming is a
> warning sign for me) but dependency-wise it looks possible.
> WASqueakWalkback has a dependency on WAInspectorHaloPlugin but that
> could maybe be resolved (it's using it to get WAHaloPlugin's
> #open:onAnswer: behaviour).

Splitting out all of the development components would be arbitrary ...
I'm just suggesting that if the Inspector component were split out
separately then it could be easily used independently of the rest of the
Development code ... I'm not interested in Halos, etc. just WAInspector
... as I said in an earlier message it really didn't look like any of
the other development components were as generically useful as the
Inspector....

As for where it could be stashed, perhaps Tools-Web is a better home
for WAInspector ... it _is_ a web-based tool much like the configuration
editor ... both are unsafe in production without authorization, but
occasionally it makes sense to install them in production.

>
> Maybe the problem is just that the setup of Development tools happens
> on initialization. I guess we could split into
> Seaside-Development-Tools and Seaside-Development-Environment or
> something and have the latter one do the initialization. Does that
> help?

If WAInspector can't find a home outside of the Development stuff then I
suppose ... but does it really make sense to break up Development into
multiple pieces for initialization when the single WAInspector compnent
could be easily moved to another package (like Tools-Web)?

-----
At the risk of opening another can of worms ... as I look at Tools-Web
(especially with Pharo included) ... there seem to be an awful lot of
basically unrelated tools lumped into a single package ... If you want
to add VNC to control, you end up with nearly a dozen other components
loaded (and initialized?) ... For these guys it might make sense to
package each independent tool separately so that a developer can pick
and choose what he wants in his application ... the presence of
initializers is the sticking point ... the Seaside-Widgets can be
loaded, but no applications are automatically registered...Each of the
tools in Tools-Web automatically registers on load, which is a good
thing if you could individually load the tools...

Tools-Web _could_ be turned into a group with individual packages for
each of the independent tools, then a developer could load the whole kit
and kaboodle into his development environment, but then pick and choose
which tools to include in production...

Keep in mind that this discussion is related to the automatic running of
initializers (which is real convenient when you are able to load exactly
what you want and a pain when you have to load the kitchen sink to get a
sponge:). Presumably there are alternate schemes for picking and
choosing which comonents you'd like installed as applications, but why
invent a new mechanism when the initialize works fine ... it's just a
matter of packaging things up into "sensible" units...
-----

Dale
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev