[whatwg] about rich internat applications

[Jose Dinuncio]

Hi, Didier


> > 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?

Yes, there is XUL and XAML, but neither has reached popularity so far
(and there is a chance in this fact), and both are browser-specific. So,
without them, there's only tables and forms in html and a server side
app handling sessions. You're right in that the code I show is similar,
and that is the sad part. The problem is solved; there is no problem in
to describe the layout of a window in XML, but today I can't download 
and render a GUI app using the two most popular browsers. So, I hope
this group come with an "GUI description language" (wich won't differ a
lot of XUL) that, being endorsed by mozilla and opera, win credibility
enougth to get apps developed. Surely, it won't run in IE, at least
before getting critical mass at developer's side.

(And, it would be a nice chance to clean a little bit XUL, removing tags
that should be deprecated)


> > 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. 

Well, almost. The model should allow both types of applications,
stand-alone and client-server. The browser acts basicly as plataform in
wich the look'n'feel of the app is downloaded and executed. Since the
browser is inherently web-oriented, it is a nice plataform to make
proxy-apps, apps that are only the VC part of the MVC architecture.

Of course, since there is ECMAScript in the browser, it has all the
power to implement as much of the Model as desired.


> 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).

A question: how much of the domain model would be downloaded by the
browser? Do you mean the data structure that the GUI is suppose to act
on? Please, elaborate on this.

> 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.

I totally agree. A layout definition should be easy to agree on, and a
big step forward.

> 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. 

Ok. Just not once, but every time it'll be nesesary.


We have very close visions, but, are we on the rigth track? This thread
and the list seem to diverge...


-- 
Jose Dinuncio <jdinunci at uc.edu.ve>
Universidad de Carabobo