[Framework-Team] Re: Putting a frame on the AJAX discussion

[Martin Aspeli]

Ben,

> Ask better questions. Ask, "who is the target audience of your effort?"  
> "what data format do we need to produce on the server?" "Can we reuse  
> existing server-side code?" "How much do people need to learn?" "How  
> disruptive to existing templates is this?" "Can we reuse existing  
> templates?"

I definitely agree. These are more important questions. I think I was
hoping to discover the answers by seeing how people would choose to attack
a given problem, but asking them explicitly is probably better.

> You see a collection of hammers in front of us and so you ask us all to  
> hammer and see how well we do?

I completely agree with all your points below. I really don't want to
write any JavaScript! Having read about the Bling approach, it looks very
good. The AZAX approach also looks very interesting, and I think it's
trying to appeal to the same type of audience - avoid writing JS, re-use
existing templates. What I'm unable to understand is whether one approach
is better than the other, because so far I've read a lot of theory, and
I've seen some losely-connected examples. But I'd like to understand how a
solution of the type that we want to put into in Plone 3.0 would look,
side-by-side.

>
> -1

So... are you against asking people to show off their recommended approach
in light of some use cases we want to solve, or are you against the type
of questions I was proposing?

> Many of these projects have different goals, most involve wanting to  
> write JS client applications and front-ends. That audience can and will  
> do whatever they want, and they will.  If they want to use Dojo or  
> Mochikit or Prototype they will, and nothing any of us do will stop them.

I agree. However, there are a number of PLIPs for 3.0 that imply the use
of AJAX. We seem to agree that we don't want to invent and maintain a new
JS library (thank goodness). However, we can't ship Plone core with more
than one library that do the same thing either, and we should be
documenting and encouraging a unified approach for the type of core use
cases that CMFPlone itself is trying to solve. If people want to do other
things, great, but having an extra 300k of JS to download with a lot of
functional overlap will only cause confusion.

We clearly shouldn't be telling people *not* to use a given library, but
we should be encouraging a unified approach for third-party developers.

> The larger Plone audience however are people looking to provide  
> solutions. Adding  JS to the list of must knows in order to use the  
> system and deliver solutions it turns out isn't necessary.  Do you think  
> all the people writing AJAX Rails apps know JS? They don't.

Neither do I :)

> Bling addresses that same audience in the Plone world using the same  
> client libs. It doesn't evangelize a JS technology because to its  
> consumers it doesn't matter, they write a few new TAL tags or have a few  
> new methods available in their views and they are off... Whats more to  
> the point, where rubber really road, the question I am not really  
> hearing, what has to be done on the server?

Agree. AZAX+Kukit seem to have the same philosophy. I guess Bling uses
Prototype, others have said Mochikit are better. Frankly, I have no idea.
But we as the core developers will have to touch some library sometimes.
We need to maintain the inter-connection points between Plone and whatever
approach we choose, and so it's important that we pick something that is
maintainable as well. I'm sure you had to think about how Prototype works
when you made Bling.

> Are people suddenly marshalling data to XML to JSON? No, its not hard,  
> but I'll tell you what, thats not the way it is now, which means  
> existing features need work to use what ever it is they are talking  
> about. Bling transfers HTML, its pretty simple. Its true to support  
> in-place editing and client side real time validation I added a couple  
> of methods, but really... they could have been Pyscripts, and all they  
> do... return the stuff that was already coming out of the normal  
> request/response cycle.

I agree this is the philosophy that makes the most sense.

> Bling is just about a pattern for using AJAX, it depends on the skillset  
> template developers already have. People like Limi are my audience. I  
> keep hearing people talk  about developers writing JS. As a team the  
> framework group doesn't need to do anything to support developers  
> writing JS, if they want to do that they will. Better question, how do  
> you put AJAX into the hand of the integrator, the web master, the casual  
> TAList?

Absolutely - that's my prime concern as well. However, we'll have to
decide how the pattern should work, behind the scenes as well. We'll have
to understand the implications of using different types of libraries. I
think that how this looks to the integrator and template creator is the
most important thing to get out of this, but I don't think I can evaluate
that without seeing some examples in the context of Plone and the use
cases we have for AJAX.

Martin

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/