[whatwg] about rich internat applications

[Didier PH Martin]

HI Jose,

> Why should we use <table/> to store the layout of controls? It is not
> flexible enought. Why to use html to describe a window app? It is *not*
> html. A nice way to go is to define a language/DTD for this specific
> task in the same way that there is docbook to define papers, or svg for
> vector graphics. The implementation of such language would be simpler
> that svg.

I do not follow Jose, who said we "should" use <table> to store the layout
of control? Be more specific. And about the other points this is precisely
what I am asking. You provided another alternative syntax to what FLEX,
XAML, XUL is proposing. The question now is there any suggestion from people
involved in the XBL at w3C?

> 
> Web applications shouldn't be tied to tables, forms and html. I see web
> apps more like client/server apps using http to send the interface and
> to comunicate state changes.
> 

Be more specific Jose because at first sight it seems that you said that
most of the processing occurs on the server side. This is probably not what
you meant. Expand on that. 

I'll tell you my own architectural philosophy

a) a domain model is encoded into a domain model language based on XML and
sent (with a layout definition) to a peer processor (that will handle user
interaction, validation and display, in other words an application).

b) the layout definition should rich enough to at least help me define what
I have today in a local application (menu, toolbar, etc...). This why I like
Xform but find too limited to form and do not help me build web apps (some
more controls are necessary to be added to the basic form controls). But I
really like the binding mechanism.

c) the controls can be binded to the XML domain model, hence, the user
interaction are triggering event that, in their turn, modify the domain
model (the binding is then necessary to bind the control with the data).

d) the XML domain model (enriched or updated with the web app) is retuned to
the server for processing. 

I have a clear separation of the model and the interactors (components
including behavior and view). The server's role is to serialize/de-serialize
a model (also check access rights, perform the necessary operations to
update the stored data, etc...), the client's role is to run the application
that will display/create/modify the data. We now have a client and a server.
When most of the data massaging is performed on the server we have a server
centric architecture resembling more a server-terminal type of relationship
than true client server. This is my humble opinion and I was pleased to see
Macromedia bringing back to us the capacity to build rich internet
application on the client side. End of the dark ages, beginning of the
renaissance...

Cheers
Didier PH Martin