[ng-dhtml] Dojo and server-side frameworks

Alex Russell alex at netWindows.org
Thu Sep 9 17:06:32 CDT 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 09 September 2004 11:50 am, Mark D. Anderson wrote:
> On Thu, 9 Sep 2004 10:09:55 -0800, "Dylan Schiemann"
> <mail at dylans.org>
>
> said:
> > So the
> > question for me is, how far do we want to extend Dojo into this
> > realm? Which server-side web app frameworks do we want to work
> > with, and what do we need to do for each of our targets to "play
> > nice" within their system?
>
> I see two different integration models:
> 1) through a shared GUI markup language
> 2) through programmtic integration (the old fashioned way)

[ great deal of insight snipped ]

It is my (incorrect?) assumption that users of varying sophistication 
are going to want the toolkit to be able to cleanly split for them at 
whatever point in the spectrum of potential integration points that 
we can imagine. More clearly, some users might want to just throw 
data at a Mono or Struts/JSF component, whereas sophisticated 
customers might want to pick and choose how they have data flow 
to/from components with very tight control related to their 
performance needs. Likewise, some users aren't going to care at all 
how a widget declaration "looks" in the markup that the browser 
interprets, whereas others may want Dojo components to add a 
downward-compatible capability to an existing app (see the NW inline 
ctor examples).

In this light, transforming a base markup language between 
intermediate formats and eventually de-serializing into component 
objects and data seems like a pretty decent way to allow users to 
insert themselves wherever they wish in the chain, but we still run 
into problems for supplemental interactions. An obvious example is 
some kind of a data table that "pages" through a very large data set. 
I can easily encode this in HTML as a table (with extra attributes) 
and transform to this from an XML declaration, but what about when I 
need the next set of rows? What channel does this flow through? How 
are those rows serialized? And what about other data about the rows 
like indexes for columns, relationships between the data, etc.?

It's these interactions where it seems like things are most in need of 
a standard and reasonably well-performing solution. I don't know if 
XML serilization makes sense here. I don't know that it doesn't, but 
I'm not sure that it does.

I think in general, I'm OK with a source markup which gets transformed 
and then re-constituted for various environments for (at the very 
leat) doing simple widget placement in HTML page (not application) 
environments. What I'm still conflicted about is how we should 
represent the kinds of interactive communications with the server 
side that app authors (not page authors) will want in this context.

Thoughts? Ideas?

- -- 
Alex Russell
alex at burstlib.org   BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
alex at netWindows.org F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBQNPooV0dQ6uSmkYRAsUTAJ9mpDqa3/b++KD/EwBEl/iarusKqwCg4r6A
jHqagqfULFgRkdJgjrSR7yY=
=64mn
-----END PGP SIGNATURE-----




More information about the NG-DHTML mailing list