[Seaside] Design of WAComponent(s)

[Sebastian Sastre]

> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre 
> de Andreas T ö nne
> Enviado el: Jueves, 06 de Marzo de 2008 13:53
> Para: Seaside - general discussion
> Asunto: Re: [Seaside] Design of WAComponent(s)
> 
> Stephane,
> 
> thank you for getting my point. ;-)
> 
> All,
> 
> I found the various objectives for Seaside hiding behind the 
> answers very
> interesting.
> 
> No offense please but some answers show a lack of 
> appreciation for the users
> of Seaside. If you want to grow the users base of Seaside, you need to
> answer the question of Microsoft. If you dont, it will remain 
> a great tool
> from specialists for specialists. And fade in oblivion eventually.
> 
> Let me get some points about my objectives straight (because 
> some jumped to
> conclusions). 
> 
> 1. I do not look at a "one-framework-fits-it-all" approach. I know the
> limitations of a pluggable design for components. It is 
> extremely hard!
> (designing Smalltalk applications for 21 years should qualify 
> me to say
> that) Particularly the mixing of structure, presentation and 
> interactivity
> in one XHTML structure limits the configuration choices for a general
> framework alot. (but I see a value in getting there half way)
> 2. I agree that the core should be small and needs some cleanup (and
> commenting please).
> 
> Having said that, please think about this statement of Stephane for a
> minute:
> 
> > I do not have the skills and time of lukas to create 
> widgets from scratch.
> > But I imagine that I should be able to reuse them.
> 
> Chapeau! That *IS* the main point. Those non-specialist that might be
> attracted to Seaside and Smalltalk are very likely not fluent 
> in the details
> of XHTML, Java-script and AJAX. Asking them to create new 
> components from
> the given examples will end in bad copy&paste programming.
> 
> One interesting point is the size or specialization of predefined
> components. A login component is indeed not very interesting for a
> predefined component. Individual widgets that need to be 
> pieced together
> from primitive HTML and AJAX elements are much more promising. These
> *expected* elements for UI design are pretty much standard 
> and hence open
> for a standard implementation. I shoot for 80:20. I like to 
> catch 80% of the
> standard widgets and components and let 20% be custom implementations.
> 
> Andreas
> 

I've taken some trade offs and what you've described in your last paragraph is
exactly what I've done in my hierarchy.
All that thanks to the amazing Seaside platform.
Let me count to give an idea.. 
7 inputs (text, password, boolean, date, etc) including an autocompleter from my
own (all the js but prototype cames from objects from the image and is not plain
text).
4 values (non inputs)
14 other controls (tabs, anchor, menu, menu from button, etc)
4 layouts (flow horizontal, flow vertical and border covers 99.9% of layout
needs)
On top of that I've have near 200 (and counting) abolutely application custom
made components (editors, headers, toolbars, more creative widgets of our own,
etc) they often have intense DOM interaction between them and are allways loose
coupled using announcements (at server) and #fire: (at DOM).
So I'm sure anyone capable of *using* MVP to develop desktop apps will love to
use this beacause the barrier to scale that apps to web are lowered to a
minimum.
Cheers,

Sebastian