Smalltalk › Frameworks & Tools › Seaside › Seaside General

Seaside subsets

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

28 messages Options

cbeler

Re: Seaside subsets

As far as I'm concerned, only doing some prototype apps, so not really
concerned by security, session protection etc... event if I find that
important (In the same time, I'm trying to make some php web developer
use 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.
only canvas, love it even if maybe not so easy to catch (what to combine
with, #with: at the end). Hapilly there are senders...

>> - 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.

Yes it's nice examples to have... maybe we should put them in a category
called components-samples :)
>
>> - 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).
not really used but nice to show :)
>> - 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 ;-)
How do you manage flows then ? logging process for instance...
It seems WATask is a hack (? heard that somewhere) but I like the idea
to represent a flow, a process and I find natural that way... what's the
alternative for you ?

> 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.
agree, looks great !
Maybe you could agree on what's essential... and mootols looks really
compact, extendable, and I'm sure I'll understand it better than the js
of scriptaculous

>
>> 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.

Uhm, I think I'd like to know more on annoucment...
I've ssen a bit through mondrian but don't really get it... found also
some information (from the vw version) but not sure it's the same...

>
> 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.
>

I think a cleanup would be excellent, but some times, code is nice to
understand stuff... like for WACachedDocument, I find interesting to
have it as an example...
Could we keep them in a package extra components, we could also add in
their comment that it's not really used either ...

my 2 cents :)

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

Sebastian Sastre-2

RE: Seaside subsets

In reply to this post by Avi Bryant-2

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de Avi Bryant
> Enviado el: Miércoles, 14 de Febrero de 2007 06:47
> Para: The Squeak Enterprise Aubergines Server - general discussion.
> Asunto: [Seaside] 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.

I'm using the new canvas. The migration becomes ok when you find all the
equivalent ways to render stuff.

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

I never use decoration nor #isolate: (yet) but I think about that feature
that it could be handly and perhaps I'll be using it soon.

> - 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.

I'm using dialogs a lot. I'm developing almos the same as desktop and
dialogs is something we need. I'm using one or two kind of modeled dialogs
wich render a customized frame so you can put there any component to be
rendered but letting the user the clasic cancel ok (#save #rollback)
features. I think this is a must.

> - 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'm also using them a little. They are handy to find a component class and
sometimes to inspect something.

> - 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 don't needed it yet. Just configuring custom session libraries, 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.

We haven't go that deep yet.

> - 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.

They are a must too. I must admit that I've completely understood them
recently

> - 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 rather use them to call the dialogs wich mostly are to edit some object
model.

> - 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.

I'm not using effects yet. We found of more value the updater, autocompleter
and the editor.

We use and reuse shore components quite often.

> 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...

So, here are ours,

Cheers !

Sebastian Sastre

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

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

Lukas Renggli

Re: Seaside subsets

In reply to this post by cbeler

> >> - 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 ;-)
> How do you manage flows then ? logging process for instance...
> It seems WATask is a hack (? heard that somewhere) but I like the idea
> to represent a flow, a process and I find natural that way... what's the
> alternative for you ?

You can do what you do within a task in any callback. Something like

html anchor
callback: [ self call: WAFoo new; call: WABar new ];
with: 'Foo and Bar'

If you extract the contents of the callback block into its own method
you basically have a method defining the flow. So I wouldn't remove
WATask, but it seems to be less useful as most of the flows are
started anyway from a callback (what also avoids the nasty redirect
the first time a WATask is displayed).

> Uhm, I think I'd like to know more on annoucment...
> I've ssen a bit through mondrian but don't really get it... found also
> some information (from the vw version) but not sure it's the same...

Yes, it is mostly the same: the implementation is different, but the
interface should be basically the same. Have a look at the posts of
Vassili Bykov:

http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?showComments=true&entry=3310034894

Cheers,
Lukas

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

Jason Johnson-3

Re: Seaside subsets

In reply to this post by Avi Bryant-2

Well, for my web pages I use Pier.

But one thing I would change (and will if someone else doesn't before I
get there :) is how CSS rendering works. I think instead of having a
#style message that just spits out a string, CSS should have it's own
renderer. It more or less has it's own render phase anyway, we may as
well make it official with a CSSCanvas class or something. This could
help with browser version differences and maybe help with some of the
problems with CSS fighting with Halos (i.e. conflict
detection/resolution). I also have other ideas for such a renderer to
make CSS building more accessible to non-programmers. ;)

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.
> - 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
>

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

Boris Popov, DeepCove Labs (SNN)

RE: Seaside subsets

Isn't CSS best left to people who do it for living anyway? They already
have the tools to get it right. For instance, there isn't a single
#style method in our application and all CSS is referenced externally.

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.

> -----Original Message-----
> From: [hidden email] [mailto:seaside-
> [hidden email]] On Behalf Of Jason Johnson
> Sent: Wednesday, February 28, 2007 9:39 AM
> To: The Squeak Enterprise Aubergines Server - general discussion.
> Subject: Re: [Seaside] Seaside subsets
>
> Well, for my web pages I use Pier.
>
> But one thing I would change (and will if someone else doesn't before

> get there :) is how CSS rendering works. I think instead of having a
> #style message that just spits out a string, CSS should have it's own
> renderer. It more or less has it's own render phase anyway, we may as
> well make it official with a CSSCanvas class or something. This could
> help with browser version differences and maybe help with some of the
> problems with CSS fighting with Halos (i.e. conflict
> detection/resolution). I also have other ideas for such a renderer to
> make CSS building more accessible to non-programmers. ;)
>
> 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.
> > - 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
> >
>
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

Jason Johnson-3

Re: Seaside subsets

Boris Popov wrote:
> Isn't CSS best left to people who do it for living anyway? They already
> have the tools to get it right. For instance, there isn't a single
> #style method in our application and all CSS is referenced externally.
>
> Cheers!
>
> -Boris
>
>
What tools do they have? Any tools I have seen want to work with a
static page. It would have to be a pretty manual process to, for
example, render a specific component. Imagine if there was a CSS
builder component in Seaside. :)
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Boris Popov, DeepCove Labs (SNN)

RE: Seaside subsets

I can't imagine contacting our designer and asking him to use the
seaside tools :) Instead, he usually works with his own set of files
(static, obviously) that use the same markup as the one generated by our
application, uploads new styles/images and quickly tests real
application once again.

-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.

> -----Original Message-----
> From: [hidden email] [mailto:seaside-
> [hidden email]] On Behalf Of Jason Johnson
> Sent: Wednesday, February 28, 2007 11:28 AM
> To: The Squeak Enterprise Aubergines Server - general discussion.
> Subject: Re: [Seaside] Seaside subsets
>
> Boris Popov wrote:
> > Isn't CSS best left to people who do it for living anyway? They
already
> > have the tools to get it right. For instance, there isn't a single
> > #style method in our application and all CSS is referenced
externally.

> >
> > Cheers!
> >
> > -Boris
> >
> >
> What tools do they have? Any tools I have seen want to work with a
> static page. It would have to be a pretty manual process to, for
> example, render a specific component. Imagine if there was a CSS
> builder component in Seaside. :)
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

Philippe Marschall

Re: Seaside subsets

In reply to this post by Avi Bryant-2

Hi

Browsing through the Seaside classes I found the following, most of
them in the WADialog hierarchy:

- WANoteDialog
- WAGridDialog
- WAEditDialog
- WALoginDialog
- WAChangePassword
- WAChoiceDialog
- WAEmailConfirmation
- WAModelProxy (WAProxyTest)
- WADelayedAnswerDecoration (WADelayTest)

Is there anybody using them (besides SmallBlog)?

Cheers
Philippe

2007/2/14, Avi Bryant <[hidden email]>:

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