[Seaside] Two Approaches to Getting Started. Which One Should I Document?

[Michael Roberts]

Dan Shafer wrote:
> Recently i queried the list about my idea of writing a Getting Started
> recipe for Seaside applications. My interest grew out of my inability to
> get a quick handle on the basic process of Seaside app creation.
> 

> I tried both and was successful using both approaches. Clearly Todd's
> approach is somewhat more complex, involving as it does three subclass
> operations. At Step 4 of his procedure, one would have to create the
> home page component, presumably, using renderContentOn: for that component.
> 

Having a root component is pretty mandatory to be honest, so it isn't a
big deal when you make it.  The main difference is that my example
doesn't use the canvas framework so I don't implement #rendererClass but
you can stick that on your root component directly to start off with.
If you feel you want to push that up to an abstract superclass then by
all means but I'd refactor that only when you need to.  You are
essentially comparing the difference between speed and sophistication so
it's not entirely comparable ;-).

> but ultimately is
> one going to have to (or want to) subclass WASession anyway to allow the
> management of app state? WASession *seems* without a great deal of study
> to be fairly complicated.

I personally don't think you need to subclass the session until you have
a reason to do so.  Given that you were talking about 'getting started'
I think that session customisation is slightly beyond the first stage.
If all you want to do is manage some global state then you can do that
with a singleton class or a global, for example.  When you're ready to
subclass the session, go for it.  You can get quite far without it, so I
didn't mention it.

> So would you suggest I document Mike's, Todd's, or both? What are the
> advantages of each? Or do you have another way altogether to approach
> the problem?
> 
By all means write some documentation!  I'm not sure what problem you
are approaching though?  If you just want a recipe for getting started
from scratch then I would probably take mine and add in the
#rendererClass method and mention the config app along with the class
side initialisation code.

Although for getting started, a quicker way is to just hack the counter
application so I guess you need to be clear about what you want your
recipe to achieve.

In a way both approaches are the same, at least mine is a subset of the
other.  Using the web based configuration app and writing class side
methods achieve the same thing but have a different set of side-effects.
 If you write your initialization on the class then it has the advantage
of being persisted and evaluated when you load the class into a fresh
image.  If your configuration is more complicated, however, you will
need to search for the correct messages to use.  The configuration app
makes changing the configuration easy but the changes, afaik, are just
local to the image.  I'm not sure if there is a method to write the
configuration out as an initialize method (I haven't looked) but that
might be quite a useful feature.

Cheers,

Mike