[Seaside] Tutorial completed: cool
Marcel Weiher
marcel@metaobject.com
Tue, 26 Feb 2002 15:52:19 +0100
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.