Seaside subsets

As 2.7 gets closer to beta (right?) and people might be thinking about
what 2.8 or even 3.0 might look like, I thought it might be
interesting to share a somewhat surprising experience I've had: Dabble
DB, which is by far the most complex web application I've ever worked
on, uses really a rather small subset of Seaside.  For example:

- We never use the old WAHtmlRenderer code.  Ok, no surprise there,
but in case anyone was wondering, it's all Canvas all the way.
- We never use decorations, ever.  No new subclasses of WADecoration,
no #isolate:, no #authenticateWith:during:,etc.  Hasn't come up.
- We never use any of the standard dialog or widget components.  For
us, anyway, the Canvas tags turn out to be the right level of detail
for reuse across apps.  We do plenty of reusing components within the
app, but a generic YesOrNoDialog or WATree doesn't cut it except when
prototyping.
- We do use halos, and I'd like to use them more, but they do badly
with heavily CSS-styled layouts.  Note that I only use them to see
page structure and for view source, I don't use the web-based system
browser (that's what the RFB Server is for).
- We do use the preferences system pretty heavily, with app-specific
subclasses of WASystemConfiguration that provide defaults we can
override from /config.  But we don't use the baroque multiple
inheritance system.
- We don't use libraries (CSS or Javascript) at all.  We use
#updateRoot: and #resourceUrl: heavily to bring in external .css and
.js files which the designer controls.
- We use WATask sparingly.  In fact, pretty much the only use is for
collecting payment info, which is of course the classic example I
always give.
- We certainly do use #call: and #answer:, but much less than you
might expect given how much talk there is about continuations.  And
the #call: stack rarely gets more than one component deep.  Instead,
we're much more likely to conditionally render a child component, or
to have a "currentChild" state variable which is constantly modified
during navigation.
- Except for a handful of those "currentChild" state variables, we
don't use WAStateHolder or #registerObjectForBacktracking: at all.
Well, that's not strictly true: we use it once, with a single
session-global NavigationContext object that holds all the
backtrackable state as instance variables.  The entire component tree
at any given time can almost always be determined by examining the
NavigationContext.
- We do use Scriptaculous, but mostly only the Ajax bits rather than
the effects.

So, I'm curious how typical my experience is.  If it's shared by most
of you, we may want to do some major housecleaning...

Avi
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Avi!

Let me comment from my experience developing Gjallar.

> As 2.7 gets closer to beta (right?) and people might be thinking about
> what 2.8 or even 3.0 might look like, I thought it might be
> interesting to share a somewhat surprising experience I've had: Dabble
> DB, which is by far the most complex web application I've ever worked
> on, uses really a rather small subset of Seaside.  For example:
>
> - We never use the old WAHtmlRenderer code.  Ok, no surprise there,
> but in case anyone was wondering, it's all Canvas all the way.

Same with me. The canvas style is very nice. Giovanni Corriga is actually
trying to mimic it in HttpView now.

> - We never use decorations, ever.  No new subclasses of WADecoration,
> no #isolate:, no #authenticateWith:during:,etc.  Hasn't come up.

We neither. Honestly I haven't even a good clue about what it is. :)

> - We never use any of the standard dialog or widget components.  For
> us, anyway, the Canvas tags turn out to be the right level of detail
> for reuse across apps.  We do plenty of reusing components within the
> app, but a generic YesOrNoDialog or WATree doesn't cut it except when
> prototyping.

We do use inform: here or there. And yes, we also have several of our own
components we reuse within the app. And we actually have a subclass of
WACanvas for some added bits. But I don't think we use much standard
widgets, well, we do use WABatchedList - and a special version that can
deal with an "unknown" number of items.

> - We do use halos, and I'd like to use them more, but they do badly
> with heavily CSS-styled layouts.  Note that I only use them to see
> page structure and for view source, I don't use the web-based system
> browser (that's what the RFB Server is for).

I don't use them. But I might learn to use them :).

> - We do use the preferences system pretty heavily, with app-specific
> subclasses of WASystemConfiguration that provide defaults we can
> override from /config.  But we don't use the baroque multiple
> inheritance system.

Don't use that. But I would gladly like an introduction covering it
because I don't think I have seen one.

> - We don't use libraries (CSS or Javascript) at all.  We use
> #updateRoot: and #resourceUrl: heavily to bring in external .css and
> .js files which the designer controls.

Interesting. We use libraries, but we have seen some issues with slow
loading. Perhaps we should do it like you do.

> - We use WATask sparingly.  In fact, pretty much the only use is for
> collecting payment info, which is of course the classic example I
> always give.

Never used it.

> - We certainly do use #call: and #answer:, but much less than you
> might expect given how much talk there is about continuations.  And
> the #call: stack rarely gets more than one component deep.  Instead,
> we're much more likely to conditionally render a child component, or
> to have a "currentChild" state variable which is constantly modified
> during navigation.

Only use it a little. But that might primarily be because I haven't really
"adopted" that style.

> - Except for a handful of those "currentChild" state variables, we
> don't use WAStateHolder or #registerObjectForBacktracking: at all.
> Well, that's not strictly true: we use it once, with a single
> session-global NavigationContext object that holds all the
> backtrackable state as instance variables.  The entire component tree
> at any given time can almost always be determined by examining the
> NavigationContext.

We don't use any of that, well, perhaps somewhere - but honestly - I am
not sure how to use it and we haven't bothered yet to "back"-button-proof
Gjallar.

> - We do use Scriptaculous, but mostly only the Ajax bits rather than
> the effects.

Same here. No effects yet. AFAIK we only use the completion thingy so far.

> So, I'm curious how typical my experience is.  If it's shared by most
> of you, we may want to do some major housecleaning...
>
> Avi

One thing we have done is to keep track of parent components with an added
instvar. We have our own WAComponent subclass. We only use it sparingly
and perhaps we could move away from it by using some other kind of
component coordination - like for example piggybacking on the session or
something.

regards, Göran

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/2/14, Avi Bryant <[hidden email]>:
> As 2.7 gets closer to beta (right?) and people might be thinking about
> what 2.8 or even 3.0 might look like, I thought it might be
> interesting to share a somewhat surprising experience I've had: Dabble
> DB, which is by far the most complex web application I've ever worked
> on, uses really a rather small subset of Seaside.  For example:
>
> - We never use the old WAHtmlRenderer code.  Ok, no surprise there,
> but in case anyone was wondering, it's all Canvas all the way.

We only use it in legacy applications but they run with old Seaside
versions anyway (updating even when not changing the renderer API is
not that easy).

> - We never use decorations, ever.  No new subclasses of WADecoration,
> no #isolate:, no #authenticateWith:during:,etc.  Hasn't come up.

We use it rarely, mostly Magritte related where it comes in very
handy. It certainly could be implemented with components that have to
be nested as well. One interesting use we have is a "performance
decoration" that does logging and the other are mostly for sutff
around Magritte components like titles, borders and backgrounds.

> - We never use any of the standard dialog or widget components.  For
> us, anyway, the Canvas tags turn out to be the right level of detail
> for reuse across apps.  We do plenty of reusing components within the
> app, but a generic YesOrNoDialog or WATree doesn't cut it except when
> prototyping.

We do neither, they just don't fit into the layout of any site. We
override #confirm: and #inform: in our component root class.

> - We do use halos, and I'd like to use them more, but they do badly
> with heavily CSS-styled layouts.  Note that I only use them to see
> page structure and for view source, I don't use the web-based system
> browser (that's what the RFB Server is for).

Same here.

> - We do use the preferences system pretty heavily, with app-specific
> subclasses of WASystemConfiguration that provide defaults we can
> override from /config.  But we don't use the baroque multiple
> inheritance system.

We have a build system that sets up the whole config stuff.

> - We don't use libraries (CSS or Javascript) at all.  We use
> #updateRoot: and #resourceUrl: heavily to bring in external .css and
> .js files which the designer controls.

Same here. But WAFileLibrary is really convenient for Pier and stuff
like Scriptaculous examples and for getting started fast without
setting up an Apache2.

> - We use WATask sparingly.  In fact, pretty much the only use is for
> collecting payment info, which is of course the classic example I
> always give.

Same here. A problem with WATask is that it doesn't (yet) support back.

> - We certainly do use #call: and #answer:, but much less than you
> might expect given how much talk there is about continuations.  And
> the #call: stack rarely gets more than one component deep.  Instead,
> we're much more likely to conditionally render a child component, or
> to have a "currentChild" state variable which is constantly modified
> during navigation.

We use it quite often for (Magritte) editors and "viewers".

> - Except for a handful of those "currentChild" state variables, we
> don't use WAStateHolder or #registerObjectForBacktracking: at all.
> Well, that's not strictly true: we use it once, with a single
> session-global NavigationContext object that holds all the
> backtrackable state as instance variables.  The entire component tree
> at any given time can almost always be determined by examining the
> NavigationContext.

We use #registerObjectForBacktracking: form time to time but it's rare
(except for widgets like tab-panels and tables and "currentChild"
stuff).

> - We do use Scriptaculous, but mostly only the Ajax bits rather than
> the effects.

Most applications use Ajax very sparsingly (one or two places) but
one uses it very extensively. Lukas is better qualified to answer here.

> So, I'm curious how typical my experience is.  If it's shared by most
> of you, we may want to do some major housecleaning...

One problem we face from time to time is cross component message
passing. If you have an event in an "inner" component but want to
change something in an "outer" component (yeah this is bad coupling
and stuff but still happens). In one application we have explicit
parent links but that turned out quite horrible, I am against this
practice. I have once done an experiment to directly support dynamic
variables but never pursued it any further. It might be worth to have
a second look at it.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Avi, Göran:

Avi, undoubtedly your notes are of high interest, mainly because
DabbleDB must be the largest Seaside production system in the world.

My experience is obviously with more little applications being my real
estate solution the more widely used of my own developments with
Squeak / Seaside, but not near the use nor the complexity of DabbleDB,
of course.

Taking in account the previous comments I can say:



2007/2/14, Göran Krampe <[hidden email]>:
I'm also using only Canvas to render.

> > - We never use decorations, ever.  No new subclasses of WADecoration,
> > no #isolate:, no #authenticateWith:during:,etc.  Hasn't come up.
>
> We neither. Honestly I haven't even a good clue about what it is. :)

Exactly same here :).

I use also inform:  and WABatchedList, but I'm using also Mewa that
provides some widgets.


> > - We do use halos, and I'd like to use them more, but they do badly
> > with heavily CSS-styled layouts.  Note that I only use them to see
> > page structure and for view source, I don't use the web-based system
> > browser (that's what the RFB Server is for).
>
> I don't use them. But I might learn to use them :).
>

Same here.

> > - We do use the preferences system pretty heavily, with app-specific
> > subclasses of WASystemConfiguration that provide defaults we can
> > override from /config.  But we don't use the baroque multiple
> > inheritance system.
>
> Don't use that. But I would gladly like an introduction covering it
> because I don't think I have seen one.
>

Same here.


> > - We don't use libraries (CSS or Javascript) at all.  We use
> > #updateRoot: and #resourceUrl: heavily to bring in external .css and
> > .js files which the designer controls.
>
> Interesting. We use libraries, but we have seen some issues with slow
> loading. Perhaps we should do it like you do.
>

Well, only in my real estate app (not in others) I'm using
ShoreComponents, that use  libraries and I'm experiencing also slow
loading. I'm thinking in abandon Shore because the slow loading,
mainly in a shared server. But I don't use my own libraries nor know
much about libraries use.

> > - We use WATask sparingly.  In fact, pretty much the only use is for
> > collecting payment info, which is of course the classic example I
> > always give.
>
> Never used it.
>

Starting some tests about how to use it to a new system. But not in
use in my current products.

I use a lot #call: and #answer:. Must investigate how to use/implement
the comments from Avi.

Same here.


> > - We do use Scriptaculous, but mostly only the Ajax bits rather than
> > the effects.
>
> Same here. No effects yet. AFAIK we only use the completion thingy so far.
>

I'm planning start using Scriptaculous, made some test mainly with
edit-in-place feature, but need to learn a lot.


Göran: Seems we must go to the same school to learn the same things,
as decorators, halos, preferences, backtracking :D.

Cheers.

--
Germán S. Arduino
http://www.arsol.biz
http://www.arsol.net
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/2/14, Avi Bryant <[hidden email]>:
An other thing we don't use is the #style method of components. And if
the inspector halo icon would open an inspector in the squeak image
instead of the web that wouldn't hurt either.

Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> - We never use the old WAHtmlRenderer code.  Ok, no surprise there,
> but in case anyone was wondering, it's all Canvas all the way.

Yep, using it already yields a deprecation message in the 2.7 version
of Seaside.

> - We never use decorations, ever.  No new subclasses of WADecoration,
> no #isolate:, no #authenticateWith:during:,etc.  Hasn't come up.

Magritte makes heavy use of decorations, e.g. if you tell a
description to generate an editor it answers an instance of a generic
component. Validation, buttons, title, help-text, ... is added with
decorations that can be customized to your needs and your specific
application. Of course this could also be done differently, but I
think it's nice to have.

> - We never use any of the standard dialog or widget components.  For
> us, anyway, the Canvas tags turn out to be the right level of detail
> for reuse across apps.  We do plenty of reusing components within the
> app, but a generic YesOrNoDialog or WATree doesn't cut it except when
> prototyping.

No, but beginners seem to like them to learn from.

> - We do use halos, and I'd like to use them more, but they do badly
> with heavily CSS-styled layouts.  Note that I only use them to see
> page structure and for view source, I don't use the web-based system
> browser (that's what the RFB Server is for).

Yes, that's a pity. A redesign using CSS2 outlines and tooltips could
maybe help. Another problem is toolbar at the bottom, it sometimes
needs special care for the CSS design.

> - We do use the preferences system pretty heavily, with app-specific
> subclasses of WASystemConfiguration that provide defaults we can
> override from /config.  But we don't use the baroque multiple
> inheritance system.

I use them in Pier, but I guess most people don't know how to use them.

> - We use WATask sparingly.  In fact, pretty much the only use is for
> collecting payment info, which is of course the classic example I
> always give.

Yep, except for tutorials and teaching Seaside I find this component useless ;-)

> - We do use Scriptaculous, but mostly only the Ajax bits rather than
> the effects.

Ajax, auto-completion and drag&drop are the parts of the library that
I am using mostly right now. However getting really serious about
those things usually requires to rewriting (extending, modifying) big
parts of the JavaScript code to exactly fit the specific needs.

Personally I find the JavaScript part of Scriptaculous quite bloated
and difficult to extend and understand. In my opinion a slim (and
better packaged) library like MooTools (http://mootools.net) would fit
Seaside much better.

> One problem we face from time to time is cross component message
> passing. If you have an event in an "inner" component but want to
> change something in an "outer" component (yeah this is bad coupling
> and stuff but still happens). In one application we have explicit
> parent links but that turned out quite horrible, I am against this
> practice. I have once done an experiment to directly support dynamic
> variables but never pursued it any further. It might be worth to have
> a second look at it.

Philippe: I use announcements to do that. This does not only work from
child to parent, but also the other way round (and from session to
components, session to session, and more). Moreover it does not
violate coupling. After all you talked about events ... an
announcement is a synonym for an event.

Some additional points to the list of Avi:

- I don't know of any usage of the code in the category
Seaside-Components-Frames. I guess this code dates back to the very
first versions of Seaside 2.0 that used some strange technique to
display children ...

- Continuation should go to the base image ;-)

- I never used WACachedDocument, either Apache or a file-library
should do the trick.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Oops

I answered to Avi and not to the list. Weird horde not respecting the reply-to
field...

I have mainly used Seaside to build my online calendar SummerTime. It is the
only "big" web application I have been involved with(infact the only webapp).

I use the #call: (or the #lightbox:) only to call another component (the
editor)
and then switch back to the main page again. I use the ajax in Scriptaculous,
but not really the Scriptaculous effects.

I use libraries for my css, but I think externalising the css could be a plus,
to make it editable to someone not using squeak.

I think ajax has changed the way to see webapps, and we don't want to have to
chage the page anymore, but just to update a part of it. I do that a lot in my
application (maybe too much , when I see the slowness of my calendar :( ).

Yann

http://icalendar.seasidehosting.st
http://www.squeaksource.com/iCalSummerTalk.html
http://yann.monclair.fr/summertalk

Quoting Avi Bryant <[hidden email]>:


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi,

On Wed, 2007-02-14 at 00:46 -0800, Avi Bryant wrote:
> As 2.7 gets closer to beta (right?) and people might be thinking about
> what 2.8 or even 3.0 might look like, I thought it might be
> interesting to share a somewhat surprising experience I've had: Dabble
> DB, which is by far the most complex web application I've ever worked
> on, uses really a rather small subset of Seaside.  For example:
>
> - We never use the old WAHtmlRenderer code.  Ok, no surprise there,
> but in case anyone was wondering, it's all Canvas all the way.

I started to use seaside a few month ago. After two days I recognized
that there is something called Canvas and I switched. I switched
then to 27a1 completely.
> - We never use decorations, ever.  No new subclasses of WADecoration,
> no #isolate:, no #authenticateWith:during:,etc.  Hasn't come up.

I'm using Magritte. A lot is done using decorators.

> - We never use any of the standard dialog or widget components.  For
> us, anyway, the Canvas tags turn out to be the right level of detail
> for reuse across apps.  We do plenty of reusing components within the
> app, but a generic YesOrNoDialog or WATree doesn't cut it except when
> prototyping.

same here.

> - We do use halos, and I'd like to use them more, but they do badly
> with heavily CSS-styled layouts.  Note that I only use them to see
> page structure and for view source, I don't use the web-based system
> browser (that's what the RFB Server is for).

I use them, too. If they were capable of displaying only the output
for one component without children I would use them even more ;)
No serious browser use here.

> - We do use the preferences system pretty heavily, with app-specific
> subclasses of WASystemConfiguration that provide defaults we can
> override from /config.  But we don't use the baroque multiple
> inheritance system.

I do not know much about it.

> - We don't use libraries (CSS or Javascript) at all.  We use
> #updateRoot: and #resourceUrl: heavily to bring in external .css and
> .js files which the designer controls.

Same here, I externalized all style and scripts and removed them from
the code. Using scriptaculous there is a big performance degrade. I had
an average of 15 link style and link script statements in the header
of every page. Pulling every script to a single file gives you a 183kb
(!!) file but serving via static url the client has to load it only
once.

> - We use WATask sparingly.  In fact, pretty much the only use is for
> collecting payment info, which is of course the classic example I
> always give.

I like the idea of having tasks. It is some sort of workflow planning
for the usage of the site. I use tasks if input of data is spread over
multiple pages. It is some sort of guided input.

> - We certainly do use #call: and #answer:, but much less than you
> might expect given how much talk there is about continuations.  And
> the #call: stack rarely gets more than one component deep.  Instead,
> we're much more likely to conditionally render a child component, or
> to have a "currentChild" state variable which is constantly modified
> during navigation.

I use call:/answer: mostly for viewers and editors. The rest of the
site opperates like your currentChild.

> - Except for a handful of those "currentChild" state variables, we
> don't use WAStateHolder or #registerObjectForBacktracking: at all.
> Well, that's not strictly true: we use it once, with a single
> session-global NavigationContext object that holds all the
> backtrackable state as instance variables.  The entire component tree
> at any given time can almost always be determined by examining the
> NavigationContext.

I do not use this as I don't anything about it.

> - We do use Scriptaculous, but mostly only the Ajax bits rather than
> the effects.
>
At the moment it is only autocompletion. But we are planning to do
some ajax stuff. And we should try to keep our fingers from the
effects ;)

> So, I'm curious how typical my experience is.  If it's shared by most
> of you, we may want to do some major housecleaning...
>
As I can see my experience is lacking a lot of features which seaside
provides. So there is a lot of space for tutorials of any sort. Topics
in this mail I never saw a tutorial about are:

- how to use WADecoration
- how to use preferences
- how to use styles and scripts.
- how to use WATask


Norbert

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

----- Original Message -----
From: "Yann Monclair" <[hidden email]>
> I think ajax has changed the way to see webapps, and we don't want to have
> to
> chage the page anymore, but just to update a part of it. I do that a lot
> in my
> application (maybe too much , when I see the slowness of my calendar :( ).

I haven't used Scriptaculous in my work yet, but I hope to (or
SeasideAsync).  I'm surprised to hear that it is slow.  I thought on of the
important ideas of partial page reloading a la Ajax is that it is supposed
to be faster.

Why is it slow?

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com 


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Carl,

My app is slow, not scriptaculous or ajax, but my use of it. I have a very big
ajax updater to change weeks, and one to hide/show a calendar. I think
they are
slow mostly of how my rendering is done, I should optimise my code. It's not a
problem with the tool, it's a problem with the user (aka me).

HTH,

Yann

Quoting Carl Gundel <[hidden email]>:


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>From building reservetravel.com/v6 as well as a few internal and prototype
applications, here's my take...

> Of Avi Bryant
> Subject: [Seaside] Seaside subsets
>
> - We never use the old WAHtmlRenderer code.  Ok, no surprise
> there, but in case anyone was wondering, it's all Canvas all the way.

Ditto.

> - We never use decorations, ever.  No new subclasses of
> WADecoration, no #isolate:, no #authenticateWith:during:,etc.
>  Hasn't come up.

I use Magritte, which uses them heavily, and I often use addMessage: to wrap
a Magritte generated component with a title, beyond that, I never use them.

> - We never use any of the standard dialog or widget
> components.  For us, anyway, the Canvas tags turn out to be
> the right level of detail for reuse across apps.  We do
> plenty of reusing components within the app, but a generic
> YesOrNoDialog or WATree doesn't cut it except when prototyping.

Ditto, however, I use them as samples, often copying the class and modifying
heavily to get an app specific custom version of something I need.  Paging
in reservetravel.com/v6 is done with a subclass of WABatchedList that works
over a web service passing the necessary state for the needed page.

> - We do use halos, and I'd like to use them more, but they do
> badly with heavily CSS-styled layouts.  Note that I only use
> them to see page structure and for view source, I don't use
> the web-based system browser (that's what the RFB Server is for).

Ditto.

> - We do use the preferences system pretty heavily, with
> app-specific subclasses of WASystemConfiguration that provide
> defaults we can override from /config.  But we don't use the
> baroque multiple inheritance system.

Ditto.

> - We don't use libraries (CSS or Javascript) at all.  We use
> #updateRoot: and #resourceUrl: heavily to bring in external
> .css and .js files which the designer controls.

Ditto.

> - We use WATask sparingly.  In fact, pretty much the only use
> is for collecting payment info, which is of course the
> classic example I always give.

I like WATask, I like having an abstraction for coordinating UI workflow,
and I like that it lets me do things I can't do in other frameworks.  I use
it sparingly, but when I need it, I need it.

> - We certainly do use #call: and #answer:, but much less than
> you might expect given how much talk there is about
> continuations.  And the #call: stack rarely gets more than
> one component deep.  Instead, we're much more likely to
> conditionally render a child component, or to have a
> "currentChild" state variable which is constantly modified
> during navigation.

I use them a lot with Magritte, though the call stack rarely gets deep, and
I do the currentChild thing as well.  

> - Except for a handful of those "currentChild" state
> variables, we don't use WAStateHolder or
> #registerObjectForBacktracking: at all.

Ditto.

> - We do use Scriptaculous, but mostly only the Ajax bits
> rather than the effects.

When possible I just stay on one page and use Scriptaculous to update parts
of it, and lots of Ajax updating and requesting, though little if any of the
effects.  I think the effects are cheesy.  But the updater has completely
changed how I view web apps

>
> So, I'm curious how typical my experience is.  If it's shared
> by most of you, we may want to do some major housecleaning...
>
> Avi

Seems from the other posts and mine, your experiences are mostly typical.
I'm curious, as the original author of the framework, what might you have
done differently knowing what you know now?

Ramon Leon
http://onsmalltalk.com

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Avi, Do you have in mind to break Seaside apart in smaller pieces,
like you did already with SeasideAsync ?
"... we may want to do some major housecleaning... "


I know of five different Seaside VisualWorks projects at customers.
They are all on a fairly recent version of 2.6b1.

> - We never use the old WAHtmlRenderer code.  Ok, no surprise there,
> but in case anyone was wondering, it's all Canvas all the way.

They mostly use the old WAHtmlRenderer.
Some are 20% Canvas, some are not using Canvas at all.

> - We never use decorations, ever.  No new subclasses of WADecoration,
> no #isolate:, no #authenticateWith:during:,etc.  Hasn't come up.

Not used

> - We never use any of the standard dialog or widget components.  For
> us, anyway, the Canvas tags turn out to be the right level of detail
> for reuse across apps.  We do plenty of reusing components within the
> app, but a generic YesOrNoDialog or WATree doesn't cut it except when
> prototyping.

Some have developed their own widgets.
One customer is using the ShoreComponent date selector.

> - We do use halos, and I'd like to use them more, but they do badly
> with heavily CSS-styled layouts.  Note that I only use them to see
> page structure and for view source, I don't use the web-based system
> browser (that's what the RFB Server is for).

Very limited use of the halos.

> - We do use the preferences system pretty heavily, with app-specific
> subclasses of WASystemConfiguration that provide defaults we can
> override from /config.  But we don't use the baroque multiple
> inheritance system.

Not used

> - We don't use libraries (CSS or Javascript) at all.  We use
> #updateRoot: and #resourceUrl: heavily to bring in external .css and
> .js files which the designer controls.

All css and javascript in the image, versioned with Store as part of the
application. Some customers offshore their development. Having
all the resources together with the application in the same bundle
helps a lot.

> - We use WATask sparingly.  In fact, pretty much the only use is for
> collecting payment info, which is of course the classic example I
> always give.

Used a little bit. Reusing the same WATask insures a consistent  
workflow for
different tasks.

> - We certainly do use #call: and #answer:, but much less than you
> might expect given how much talk there is about continuations.  And
> the #call: stack rarely gets more than one component deep.  Instead,
> we're much more likely to conditionally render a child component, or
> to have a "currentChild" state variable which is constantly modified
> during navigation.

Not used.

> - Except for a handful of those "currentChild" state variables, we
> don't use WAStateHolder or #registerObjectForBacktracking: at all.
> Well, that's not strictly true: we use it once, with a single
> session-global NavigationContext object that holds all the
> backtrackable state as instance variables.  The entire component tree
> at any given time can almost always be determined by examining the
> NavigationContext.

Backtracking currently not used. Some customers have disabled the
back button using some javascript, they would like to reenable it
and use backtracking at some point in time.

> - We do use Scriptaculous, but mostly only the Ajax bits rather than
> the effects.

Scriptaculous is not used, although they all would like to use it.
SeasideAsync is used heavily in four projects.

Cheers,
Michel.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Avi,

Please see below,

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

All Canvas here as well.

> - We never use decorations, ever.  No new subclasses of WADecoration,
> no #isolate:, no #authenticateWith:during:,etc.  Hasn't come up.

Single use of it via (self addDecoration: WASessionProtector new) on the
outermost component, no other uses have come up yet, but I haven't
looked at adding application-wide field/form validation and not yet sure
if that's one of the viable approaches.

> - We never use any of the standard dialog or widget components.  For
> us, anyway, the Canvas tags turn out to be the right level of detail
> for reuse across apps.  We do plenty of reusing components within the
> app, but a generic YesOrNoDialog or WATree doesn't cut it except when
> prototyping.

Yup, great to use in presentations, never actually used it here.

> - We do use halos, and I'd like to use them more, but they do badly
> with heavily CSS-styled layouts.  Note that I only use them to see
> page structure and for view source, I don't use the web-based system
> browser (that's what the RFB Server is for).

I tend to toggle them to see the component composition when changing
layout elements, but given that application state had solidified many
months ago, I can't recall last time I used them; indeed reason being
that CSS based layout and halos just don't play well together.

> - We do use the preferences system pretty heavily, with app-specific
> subclasses of WASystemConfiguration that provide defaults we can
> override from /config.  But we don't use the baroque multiple
> inheritance system.

Haven't used it, but really does seem useful once a good use case comes
up.

> - We don't use libraries (CSS or Javascript) at all.  We use
> #updateRoot: and #resourceUrl: heavily to bring in external .css and
> .js files which the designer controls.

This is a more interesting one, speaking from experience, they are great
to get going and keep the files as part of the code-base for seamless
version control and integration. So we do use them, but only in
development. Originally all resources exist in files, every time they
change we load them back into the file libraries (slightly modified to
use file-like addressing) and serve from the image during development
(other guys don't even have front web servers on their workstations). In
production, however, the resources get dumped from the image back into
the file system and apache takes over by overriding aliases normally
served by seaside in development, say /images, /css and /other

> - We use WATask sparingly.  In fact, pretty much the only use is for
> collecting payment info, which is of course the classic example I
> always give.

Our login uses WATask and I loved it, looking forward to using it more
as things come up.

> - We certainly do use #call: and #answer:, but much less than you
> might expect given how much talk there is about continuations.  And
> the #call: stack rarely gets more than one component deep.  Instead,
> we're much more likely to conditionally render a child component, or
> to have a "currentChild" state variable which is constantly modified
> during navigation.

Navigation here is controlled in a similar fashion by an outer
component, I've replaced most previous uses of call: with modal YUI
dialogs few months ago, although that's not to say I'd want it gone from
the base framework.

> - Except for a handful of those "currentChild" state variables, we
> don't use WAStateHolder or #registerObjectForBacktracking: at all.
> Well, that's not strictly true: we use it once, with a single
> session-global NavigationContext object that holds all the
> backtrackable state as instance variables.  The entire component tree
> at any given time can almost always be determined by examining the
> NavigationContext.

Same here, although again, that's not to say there are no feasible uses
of it for us yet, I'd rather have it available than not, and so far its
been a killer demo feature, who cares if its rarely ever used in real
systems :)

> - We do use Scriptaculous, but mostly only the Ajax bits rather than
> the effects.

We use Scriptaculous for Ajax as well as effects, plus bits and pieces
of YUI for overlay dialogs and calendar widgets.

>
> So, I'm curious how typical my experience is.  If it's shared by most
> of you, we may want to do some major housecleaning...

I'm all for it, as long as we don't remove features that are critical
for those ever-important demos, regardless of how little use they may
see in real life.

Cheers!

-Boris
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Carl Gundel wrote:
I've been using more of the Ajax stuff (ala SeasideAsync) and find it
works just fine speedwise -- my web-app is only running on my garage
based Compaq Proliant 6400 (quad Xeon's running at 500Mhz) on Linux and
find no issues w/ speed.. Of course, that's only with 1 user doing
development/testing.. Should be much better when proxied up and put on a
faster (production) machine... I use the Ajax stuff to update a div that
displays the contents of my shopping cart and other address fields..
It's VERY slick and my wife & sister-in-law were very impressed with
what I've got going in this yet-to-be-done web-app..

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Avi Bryant wrote:
[ ... ]
> - We never use the old WAHtmlRenderer code.  Ok, no surprise there,
> but in case anyone was wondering, it's all Canvas all the way.

Ditto..

> - We never use decorations, ever.  No new subclasses of WADecoration,
> no #isolate:, no #authenticateWith:during:,etc.  Hasn't come up.

I've got a WASessionProtector used as part of a decoration and frankly
I've got no clue what that does for me.. I got it from somewhere else..
I might try removing it to see whats missing.. (clueless on that one)..
Otherwise I'm really not sure what Decorations get you.

> - We never use any of the standard dialog or widget components.  For
> us, anyway, the Canvas tags turn out to be the right level of detail
> for reuse across apps.  We do plenty of reusing components within the
> app, but a generic YesOrNoDialog or WATree doesn't cut it except when
> prototyping.

No widgets here yet and I'm planning on keeping it that way.  I'm using
100% Canvas tags too.

> - We do use halos, and I'd like to use them more, but they do badly
> with heavily CSS-styled layouts.  Note that I only use them to see
> page structure and for view source, I don't use the web-based system
> browser (that's what the RFB Server is for).

I use Halo's once in a while as well to view the pretty printed source
or to configure my app -- I also find that my pages' css can goof up the
halo's output, but I can live with that.

> - We do use the preferences system pretty heavily, with app-specific
> subclasses of WASystemConfiguration that provide defaults we can
> override from /config.  But we don't use the baroque multiple
> inheritance system.

I'm also using the preferences, though not extensively yet.. It's
actually pretty cool that I can load my code in from my "Store"
repository and the WASession is overridden and session timeouts are
properly set, etc.

> - We don't use libraries (CSS or Javascript) at all.  We use
> #updateRoot: and #resourceUrl: heavily to bring in external .css and
> .js files which the designer controls.

Ditto.. I was using embedded and #style methods, but have recently
switched to external files.. Works like a charm!

> - We use WATask sparingly.  In fact, pretty much the only use is for
> collecting payment info, which is of course the classic example I
> always give.

I don't believe I've got any WATask instances, but I've yet to code up
my payment mechanism so that may change I suppose.

> - We certainly do use #call: and #answer:, but much less than you
> might expect given how much talk there is about continuations.  And
> the #call: stack rarely gets more than one component deep.  Instead,
> we're much more likely to conditionally render a child component, or
> to have a "currentChild" state variable which is constantly modified
> during navigation.

None of the #call or #answers either.. I am using a 'currentChild' sort
of mechanism that I got from Brian Brown here on the list about a year
ago.. That went a long way towards working the entire menu system I've
got now.. I can't thank him enough for his insight, etc.

> - Except for a handful of those "currentChild" state variables, we
> don't use WAStateHolder or #registerObjectForBacktracking: at all.

Ditto..

> - We do use Scriptaculous, but mostly only the Ajax bits rather than
> the effects.

I use SeasideAsync and find it works great for my uses -- I don't need
the extra features and complexity that Scriptaculous gives -- for now
anyway..

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Rick,

Session protector stores the remote address of a user and checks it for
every request to prevent most obvious session hijacking (url copying),
especially when not using session cookies. There are a number of
limitations, but not many downsides to using it, so it's a good idea to
have it place working with other measures to secure your applications.

Cheers,

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
WADecoration,
> > no #isolate:, no #authenticateWith:during:,etc.  Hasn't come up.
>
> I've got a WASessionProtector used as part of a decoration and frankly
> I've got no clue what that does for me.. I got it from somewhere
else..
> I might try removing it to see whats missing.. (clueless on that
one)..
> Otherwise I'm really not sure what Decorations get you.
>
> > - We never use any of the standard dialog or widget components.  For
> > us, anyway, the Canvas tags turn out to be the right level of detail
> > for reuse across apps.  We do plenty of reusing components within
the
> > app, but a generic YesOrNoDialog or WATree doesn't cut it except
when
> > prototyping.
>
> No widgets here yet and I'm planning on keeping it that way.  I'm
using
> 100% Canvas tags too.
>
> > - We do use halos, and I'd like to use them more, but they do badly
> > with heavily CSS-styled layouts.  Note that I only use them to see
> > page structure and for view source, I don't use the web-based system
> > browser (that's what the RFB Server is for).
>
> I use Halo's once in a while as well to view the pretty printed source
> or to configure my app -- I also find that my pages' css can goof up
the sort _______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Boris Popov wrote:
> Rick,
>
> Session protector stores the remote address of a user and checks it for
> every request to prevent most obvious session hijacking (url copying),
> especially when not using session cookies. There are a number of
> limitations, but not many downsides to using it, so it's a good idea to
> have it place working with other measures to secure your applications.

Thanks Boris -- I probably got it from you! (8->

I'll keep it in place then and add some comments to make it clear what
its doing..
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I prefer canvas - but before you go ripping out the old renderer - let us remember that some of us have a LOT of components using the old renderer and would like very much to not have to rewrite that code anytime soon.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

From: "Todd Blanchard" <[hidden email]>
>I prefer canvas - but before you go ripping out the old renderer -
> let us remember that some of us have a LOT of components using the
> old renderer and would like very much to not have to rewrite that
> code anytime soon.
>
> I'd also like to see better support for REST 'landing points'.

Okay, here are my observations about how we're using Seaside.

-Mostly we rely on the very nice way Seaside allows us to compose views out
of objects.  This makes a lot possible with very little work.  The built-in
session management is real nice too and it's great to have so many built-in
components to build with.
-We do use the canvas API in Run BASIC, buy maybe we have a little of the
WAHtmlRenderer API in there too.  I'd have to go have a careful look.
-We do use #confirm: in a couple of places.  I think this may be the only
thing we do that uses continuations (unless I misunderstand how that feature
works).
-I'm not sure what WADecoration is really for.  I know pretty much for
certain we don't use #isolate: or #authenticateWith:during:
-We haven't been using halos, but I bet when our pages start getting more
complicated it might be a useful feature.  Perhaps there could be an option
when using halos to turn off CSS until the halos are put away.
-I'm sure we'll get to a point in our development where something like
WASystemConfiguration will come in handy.
-As for libraries, we will need those to use SeasideAsync or Scriptaculous,
right?
-Haven't used WATask, and I'm not sure we will.  But if it's a good
mechanism for processing payments we may find it useful.
-I'm not sure if we're using WAStateHolder or
#registerObjectForBacktracking: and even less sure what these things do, but
perhaps some the objects we use take advantage of this stuff.

Before I see anything change, it'd be great to have solid documentation.
Seaside is already great so don't rework it, yet.  From Avi's list I'd be
hard pressed to know what all those features are for and whether or not our
application relies on them.  I have this terrible feeling that we could be
even more productive with Seaside if we could just understand it completely.

Boy would I die for good comprehensive tutorials on SeasideAsync and/or
Scriptaculous.  I've managed to tinker with these things, but I wasn't able
to get confortable enough to begin using them in my project.  I know that
I'm going to need to do it though.

-Carl Gundel
http://www.runbasic.com 


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>
> I haven't used Scriptaculous in my work yet, but I hope to (or
> SeasideAsync).  I'm surprised to hear that it is slow.  I thought on
> of the important ideas of partial page reloading a la Ajax is that it
> is supposed to be faster.
>
> Why is it slow?
>
Using scriptaculous is to me it's really fast !  even updating the full
page (without reloading) to change the language is instantaneous...
after if what's displayed need time to be processed (squeak processing
time) then the display takes time too...

Concerning seaside in general, I find firefox on linux particularly slow
to run seaside apps (even if scriptaculous helps here, times remains
longer than accessing the same app from firefox/windows).

Am i the only one (maybe this is my linux version !)?
(for instance see www.lukas-renggli.ch)
- quite fast on windows -> 2s a click update (faster on opera)
- very slow from linux  -> argh more than 5seconds (I really think I
have a problem with firefox !)

Finally, I like the idea to use mootools.js... looks neat ! probably
more compact, well commented js and all we need !

Cédrick
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside