[Seaside] Seaside subsets

Cédrick Béler cbeler at enit.fr
Thu Feb 15 09:53:11 UTC 2007

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 :)


More information about the Seaside mailing list