- From: Didier PH Martin <martind@netfolder.com>
- Date: Wed, 09 Jun 2004 12:34:58 -0400
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
Received on Wednesday, 9 June 2004 09:34:58 UTC