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?
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/ _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team