[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 :)
Cédrick
More information about the Seaside
mailing list