[Seaside] Component tree vs. DOM tree

[Sebastian Sastre]

Hi Sophie,

	that’s what I do. Every Seaside presenter (read: component I use) has
its own DOM homologue. For me works great.

	In my framework the developer does not have to care about DOM classes
because it is handled by the seaside presenters structure that build them. Also
the tree is automatically set at UA.

	Concluding: I don’t see any problem as long as you have a good
separation of concerns.

	cheers,

Sebastian


> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre 
> de itsme213
> Enviado el: Lunes, 10 de Marzo de 2008 14:48
> Para: seaside at lists.squeakfoundation.org
> Asunto: [Seaside] Component tree vs. DOM tree
> 
> Seaside currently keeps a server-side component tree. Each 
> component will 
> typically render a sub-tree of the browser-side DOM tree.
> 
> What would be the disadvantage of maintaining a unified 
> server-side DOM 
> tree, where some (but not all) nodes would correspond to 
> full-blown Seaside 
> components? I think Michael Lucas-Smith had mentioned this
> 
> "you tend to want only one tree to represent your UI state on 
> the server, 
> not two - instead of having WAComponent and WABrush 
> separated, we combined 
> the two so that each widget was an element which was also 
> represented on the 
> client side as a DOM node."
> 
> Thanks - Sophie
> 
> 
> 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside