[Seaside] Tutorial completed: cool

[Marcel Weiher]

On Monday, February 25, 2002, at 06:34 PM, Avi Bryant wrote:

[non-tagged templates]

> This could likely be implemented using Seaside's macro system.

I am sure!  It could also be implemented in WO.  I am also not at all 
sure wether Seaside *should* address these issues that I have  with WO.  
You just asked ;-)

>  Currently,
> there is a macro (IAImplicitIDExpansion) that takes <a href="@foo"> and
> transforms it into <a sea:id="foo">; a later expansion takes that and
> transforms it into <a sea:id="foo" sea:class="IAAnchor">.  Only once all
> the macros have run does IAElementBuilder walk the template and create
> dynamic elements for each tag with a sea:id and sea:class, at which 
> point
> bindings are attached, etc.
>
> It's easy to add new expansions to a particular component; for
> example, overriding #template in the following way:
>
> template
>   |template|
>   template _ super template.
>   template expander
>     replaceAll: [:node | node name = 'b']
>     with: [:node | node name: 'i'].
>   ^ template

Yes.  Another one to override would be ^html to read WO-templates from 
disk...

> should replace all <b> tags in the template with <i> tags.
>
> It sounds like what you want is a macro that adds a sea:id to tags
> specified in a non-trivial way;

Yes.  My basic requirement (both for my particular application and on 
philosophical grounds ;-) is that the source-document not be modified in 
any way.  This makes the mapping significantly more difficult, but makes 
a huge difference in interoperability, with fairly deep consequences.

So you have a mapping:

	concrete source document  ->    template

with the description of the mapping kept external from the source 
document.

>  were you using an XPath-like
> specification, or something different?

Something different, because my source documents are currently PDF and 
EPS files.  The basic mechanism is to have an 'attacher' that describes 
how to find a 'slot' in a source document.

>> Another issue with WO is that it defaults to the "stateful application"
>> model, and stateless processing is really not integrated very well at
>> all.  Statelessness is a really powerful and enabling aspect of the 
>> web,
>> and can also simplify applications.  I have no idea yet how seaside
>> deals with that, since I was quite busy over the week-end.
>
> Seaside is equally guilty here.  I guess you could use methods on
> IASession to pull something similar to WODirectAction, but I'm not 
> sure I
> see the point; yes, statelessness is useful, but how realistic is it to
> mix stateful and stateless designs in a single application?

Highly realistic, and highly useful!  I used to work on a content 
management system written in Objective-C, but with our own web-libs.  We 
started off with a session-based concept, but later managed to migrate 
to a a technique we called 'micro-transactions'.  Most of the app was 
'stateless' in the sense of not having a session and every page access 
being self-contained.  Only when you edited a particular piece of 
information did we generate a tiny session, which usually lasted for 1-3 
page-views, and which discardeed immediately after you were done with 
the transaction.

>   I imaginine
> that Seaside, like WebObjects, will only be used when state is desired,
> and other solutions will be used when statelessness is ok (I personally
> use a mixture of Seaside and Ruby CGI scripts, for example).

Why?

>   But maybe
> that's being too pessimistic.  What would you want in a stateless 
> system?

Transparency.  A stateless component should parse its 'parameters' 
automagically from the URL, and invoking a stateless component should 
automatically encode the parameters.  It should also be easy to switch 
from stateless to a stateful component (optimally:  a component can be 
used in a stateless or a statefull environment).

Once again, I am not sure if this is feasible or that it will actually 
be useful, though I strongly suspect it will (our system was not 
transparent, but the small extra effort was worth it).  So I am not 
asking that Seaside actually do this, but just dreaming along.

>> Incidentally, I also demoed Seaside to a whole bunch of WO/Cocoa
>> developers as part of my impromptu Squeak presentation at the
>> Wocoa-meeting this saturday.  It worked very nicely and I think they
>> were impressed. ;-)
>
> Cool.  It would be great to get some more WO folk involved.  I
> remember you pushing Squeak on the MacOSX-dev list (I think that was the
> first time I heard of it, in fact);

Hey, does that mean I had a part in making Seaside happen (if infinitely 
small)?  Neat.

>  have you ever had much success
> bringing them over to the Squeak side?  (Oh, dear - flashes of Star 
> Wars -
> "do not underestimate the power of the Seaside...").

;-)

>> With my new Cocoa VM that can read the image from the app-wrapper,
>> 'deployment' is also a snap, or rather, a joke:  just copy
>> CocoaSqueak.app to the appropriate machine and launch it.  When I think
>> of the hassles of WO deployment, it just makes me weep.
>
> Yes, and you were talking about saving each image as an app bundle, 
> right?
> I'd like to see that.

OK, coming.

Marcel

--
Marcel Weiher				Metaobject Software Technologies
marcel@metaobject.com		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.