Inline.
"Robert Wittams" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> I had a look at dojo before and these were the questions that popped up
> in my mind:
>
> Dojo seems to rely on adding its own unnamespaced attributes to normal
> elements. Is this compatible with strict use of XHTML?
No. Yes. And no. And Yes. Let me explain.
1) No. Adding your own attributes is not compatible with XHTML.
2) Yes. You can safely add your own attributes to XHTML code providing your
specified your own namespace for them.
3) AFAIK, at present there is no standard-conformant XHTML browser.
Translation: you can define your own namespace for attributes but browsers
may ignore it and complain about "unknown attributes".
4) Given all that I tend to specify parameters using class names and HTML
payload and/or JavaScript. Dojo supports specification of widget type using
class name. It makes it possible to define your custom widgets in following
manner:
<div class="dojo-mywidget">
<span class="ident">1</span>
<span class="name">Sparky</span>
</div>
I believe it is fully compatible with XHTML.
> What would the mechanism for fallbacks be? To produce the non-JS case,
> then use unobtrusive JS to add dojos funny attributes, and then trigger
> dojo to turn it into a dojo widget, or what?
I prefer unobtrusive JS and "funny" markup, yes.
> What 'profile' of Dojo would we bundle? How would it be handled in our
> svn? A script to go and fetch it from Dojos svn and run the compressor,
> and something to complain if this hasn't been done?
I think we need to do our own profile depending on what we need/have. I
don't think we need to maintain a live version of Dojo. I prefer to freeze
the code between Django Ajax versions.
> Use this to create the scripts to include in tarballs? I don't think we
> want to mirror Dojo in our svn, but rather just track a tagged release?
Yup. Or we can use our own snapshots.
> I think there are a couple of other things that could be interesting
> here...
>
> I think #925 is very important. A 'component' effectively becomes a
> template-tag + a processor. This can be used to create a 'component'
> generic view for partial page updates. Needs more thought (preserving
> other component state on normal posts), but could be amazing if we can
> pull it off.
Yes. I was eyeing it too. In fact we have to have a solution (Ajax or not)
for composite pages. If you look at my blog you can see that some pages are
a combination of generic views. For example, author details have some info
about author and paged list of his/her articles (the limit is 100 items per
page so you will not see page navigation elements here yet). The same goes
for category details --- paged list of articles in the category, list of
subcategories with the most recent articles , and so on. Under the hood I
have specialized views, which partially duplicate a functionality of
existing generic views, and relatively complex templates + custom template
tags. It was either that or combining generic view outputs in raw HTML
handling potential problems along the way (dummy request objects, possible
404/500 in a subview, and so on).
> on my local parser-state branch (see the message Parser Pranks) , I'm
> now experimenting with dynamically creating an ElementTree from
> templates as I go along. This can trivially be transformed to HTML4 or
> Mochi-esque JSON DOM on output. This might give us some flexibility on
> the transport side.
I didn't see it yet but I am curious.
Thanks,
Eugene
