I kind of see web pages as hierarchies of (potentially reusable) widgets, not
HTML/XML elements. Depending on the project, widgets' presentation may have to
be graphically designed (it's hard to say no to customers) and this is where I
see a real need for a clean separation of design and coding. However, I
believe when the right widget granularity is chosen, adding dynamic content to
designed widget presentations is rarely more complex than simple string
substitution. This obviously assumes that widgets are constructed of simpler
component widgets...
What I like about the dom approaches like XMLC applied to a widget view is
that:
* simple conventions in the markup (such as id attributes) allow to specify
the extent of widgets and of dynamic content.
* some kind of widget compiler can translate designer output to a
class/instance that provide a clean and simple API to developers.
This allows designers to retouch layout, colors, fonts, spelling, etc. or
translators to translate HTML text--and all that is required by developers is
to rerun the compiler when a new version comes out. If your customer requires
a designer on the team (and you and I may not agree that this is a need), this
is a great feature to have! No dependency on the "final" designed page, or
"freezing" of pages that have been converted to "code" (as in JSP).
However, if you look at the DOM methods to construct/dynamically modify pages,
making it much more difficult to cleanly define higher levels of abstraction as
one would do with composite widgets. Life w/o abstraction sucks unless you are
writing very simple stuff. This is probably why you wrote PTL...
So in summary, I believe that DOM is bad since it doesn't allow to build
abstraction hierarhies above elements, but it's great (in projects where you
need it) to avoid unnecessary bottlenecs in the collaboration of designers and
coders.
I believe that it is possible to combine the the advantages of "separation"
approaches (DOM) with the advantages of approaches that support abstraction
(like PTL) into an approach that used widgets with pluggable (and optionally
designed and compiled) presentations.
BTW, to provide some more background for my ideas above, I wrote some rough
widgets for prototyping complex query forms that would have challenged anyone
to do by hand (some 18 pages html printout for one web page). Among them were
widgets that slightly extended html form elements (with labels, "select all"
buttons or JS calendar tools), and several composite widgets including:
* a field group widget that combines two related input elements into a titled
group
* a table layout widget that lays out form widgets in several rows and columns
* an ordered selection widget that uses two multi-select boxes and some buttons
to specify which components of query results appear in which order in
reports.
* an basic/advanced section widget that keeps one section hidden (CSS magic)
and toggles sections on a button press. It keeps the interface simple for
normal users and gives super users access to all kind of advanced features.
While the above is probably quite exotic for Internet applications, it still
illustrates how widgets allow to cleanly design what units are reusable and how
to use "abstraction" in web page design that drastically cuts on the
complexity.
In case anyone is interested in seeing some widget examples, I'd be happy to
put some up on the web. Note that they only deal with presentation and that
the "data binding" is still missing.
cheers
-bud
On Mon, 11 Nov 2002 11:38:46 -0500
Greg Ward wrote:
> On 06 November 2002, Bud P. Bruegger said:
> > A shortcoming of this and all DOM-based methods (and I believe also
> > ZTP?) is in the granularity; I don't believe it is the page (document)
> > that should be the object of design but rather a page fragment (DOM
> > fragment) that I normally call widget. These are parts like headers,
> > footers, titles, nav bars, form elements, etc. that are typically
> > reused on multiple pages.
>
> Good point, and a very good argument in favour of PTL. Perhaps my
> favourite thing about PTL is that it lets *you* decide on the level of
> granularity you want. You can have a PTL template (or Python function)
> return a single HTML tag, a whole document, or anywhere in between.
>
> I think I can make a solemn vow that nothing DOM-like will ever appear
> in Quixote.
>
> Greg
>
> _______________________________________________
> Quixote-users mailing list
> Quixote-users@mems-exchange.org
> http://mail.mems-exchange.org/mailman/listinfo/quixote-users
>
/-----------------------------------------------------------------
| Bud P. Bruegger, Ph.D.
| Sistema (www.sistema.it)
| Via U. Bassi, 54
| 58100 Grosseto, Italy
| +39-0564-411682 (voice and fax)
\-----------------------------------------------------------------