Subject says it.
Seaside really seems to address most of the issues I had with WO.
I will definitely play with it some more.
Marcel
Marcel Weiher wrote:
Subject says it.
Seaside really seems to address most of the issues I had with WO.
I will definitely play with it some more.
Marcel
Good to hear!
Hopefully we can get part two of the tutorial done in the not too distant future :)
Julian
On Monday, February 25, 2002, at 08:21 AM, Avi Bryant wrote:
On Fri, 22 Feb 2002, Marcel Weiher wrote:
Seaside really seems to address most of the issues I had with WO.
Most; out of curiosity, which issues remain?
Excellent question! My main reason for saying 'most' is that my inspection has only been very superficial so far, so I can't really say 'all' with confidence.
The requirement for special template syntax is still there, though somewhat eased. For some DTP related work, I've implemented a different approach. I use an unmodified source document and then separately describe the hooks into this source document. These hooks are, of course, much more complex to describe/implement, but at least for DTP-related work, the effort is definitely worth it.
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.
I am also not sure wether they should be addressed.
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. ;-)
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.
Marcel
-- Marcel Weiher Metaobject Software Technologies marcel@metaobject.com www.metaobject.com Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
On Mon, 25 Feb 2002, Marcel Weiher wrote:
The requirement for special template syntax is still there, though somewhat eased. For some DTP related work, I've implemented a different approach. I use an unmodified source document and then separately describe the hooks into this source document. These hooks are, of course, much more complex to describe/implement, but at least for DTP-related work, the effort is definitely worth it.
This could likely be implemented using Seaside's macro system. 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
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; were you using an XPath-like specification, or something different?
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? 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). But maybe that's being too pessimistic. What would you want in a stateless system?
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); 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.
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.
On Tue, 26 Feb 2002, Marcel Weiher wrote:
Yes. Another one to override would be ^html to read WO-templates from disk...
Not that this bears directly on what we were talking about, but you can read templates from disk by overriding #template to return an IAFileTemplate -
template ^ IAFileTemplate new file: 'foo.html'; bindWith: [:template | self addBindingsTo: template]
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.
I definitely agree on philosophical grounds, although I think a continuum is useful from totally unmodified source-document to, in simple cases, source document modified enough to have no need for external mapping (hence all the emphasis in Seaside on default bindings). That's a fuzzy line, of course, because it depends on how you define "simple cases" and how much modification you're willing to stomach in the worst case.
Dealing with PDF and PS documents is of course a whole different game, since it's unlikely the developer is going to write these by hand, and so all the developer-friendly shortcuts and defaults make much less sense.
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.
Hmm, that's very interesting. Not so different from Seaside's current notion of transactions, except that in Seaside you're always in one.
How do you make the transition from stateless to stateful? More concretely - are the urls generated on a stateless page always stateless urls? In which case you have stateful pages that initialize themselves from stateless urls and then switch into stateful mode?
My main concern with statelessness is that it leads to much more convoluted control flow. Seaside pages carry around their continuation, which is a *lot* easier to persist as server-side state than as client-side state. If you lose that, you're back to simple GOTOs everywhere, and I don't consider that a win.
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).
Worth it in which ways? Testability? Bookmarkability? Low memory overhead?
So I am not asking that Seaside actually do this, but just dreaming along.
Sure, but I find it interesting to explore anyway.
Cheers, Avi
seaside@lists.squeakfoundation.org
-
Avi Bryant -
Julian Fitzell -
Marcel Weiher