Different kinds of serialization of data are possible.

AHAH

Return prerdendered HTML from server:

• less effort in client +
  
• data not really reusable in client -
• data to serialization overhead great -
• no parsing needed +

Json

return a javascript object noted as javascript and eval it.

• using eval in client -
• data to serialization overhead small +
• data optimal reusable ++
• no parsing needed +

Xml

Generate a XML Format and use a clientside logic to use the data via dom operations.

• dom parsing of data slow -
  
• data to serialization overhead great -
• data good reusable +
• xml parsing needed -

WDDX

Wddx has its origins in Xold Fusion and is a XML Format to serialize and deserialize Data and Objects. PHP has wddx support.

• wddx in js slow & not usable for large datasets --
  
• data to serialization overhead great -
• data good reusable +
• xml parsing needed -
• ease of use +

Soap

Even webservices can be used. Objects are invoked from webservices.

• data to serialization overhead great -
• data optimal reusable ++
• xml parsing needed -

No Serialization

Data comes unserialized from server as text and is passed into a string.

• fast data -> js ++
• no serilalization +
• data reusable +
• no xml parsing needed +
• only one result and value can be used --

What is happening ona Ajax request and how we have to react on that what happens:

Pre Request
Previous to the request we need to instanciate the ajax framework and load all classes.

Firing the request
We need to tell the gui NOT to handle additional clicks for specific parts of the gui, since it could be possible taht a dom id is missing that is needed by the later dom wirte stuff that happens when you server has performed the action and returned a result. Since you can not be sure that the gui is in the same state and you can not make a

var result = myajaxfunc();

just because of the asyncronous nature of the whole thing. There is need for the information what part of teh gui should be blocked, aka event-cancelled

Working with the results data
OK its starting to get a bit tricky, now were in the real events of that ajax request. Since we are doing Async (the A in Ajax) data retrieval, its not possible to do (cant stress this enough)

var result = myajaxfunc();

So you have to use the abillity of javascript to tell it which function name it should use, or which anonymous function i pass. So (simple) the above example gets

var func_result = function (return) {
// domesomething withmyresult
}

myajaxfunc(func_result);

Oops a error occured
Various errors can happen:

- postnuke function does return errormsg
- request status is not 200
- malformed data
- unknown postnuke function called

The first 3 need to be handeled, for the fourth pnAjax will have a re-written pnmodapifunc method, that will NOT return a error page when you call a unknown function (are we java or what ?, who did this .. i dont get it till today, i guess ill need to get my german sheppards on this guy ... wot kind of system design is tis ?) .... anyway .. in a stack of 10 funcs all these errors can occur and need to be handeled ....

Finalizing the thing
If you called 10 Postnuke functions you might need som post processing, that takes polace in the on finalize handler ;) You can gather the results here (like for example getting the products of categorie dogs and birds), match the together and stick them into the pn datagrid ;)

Just a shortie, describing the clientside components of the pnajax framework:

1. Serverside method access Runs via async access of pnmoapifunc methods. That means all php functionality needs to be implemented in pnmodapifuncs to be reused with ajax.

2. Advanced GUI Components Tabs, Datagrids and Tree Elemnts are missing in traditional html in comparsion to GUI Style Applications like they come out of .net and co. These are added via the jsObjects Lib and will be wrapped with a simplifying api, that merges postnuke data structures to the sometimes complicated process of generating these Objects. I have started to add new features to the library as well as fixing some warnings. Ill work a bit more on removing the evil eval in that package

3. Pagecontroller To allow the simplification of a real GUI Application, pnJAax is using a page controller aka PN_PAGE. It will make stuff like events, form checking etc. easy and give the developer a straight informtion where to code for th click-actions a user can do in a userinterface. This class could be seen as a replacement for the pnmodfuncs, that represent the pagecontroler in postnuke.

4. Helper APIs Form validation imlementation, moofx, array comparasion, console logging (firefox/mozilla) etc go here. Again i will reuse the jsObjects stuff, but wrap it with a own api that is simpler.

Yesterday night i changed the datagrid api to jsObects own datagrid. Its a complete solution that is wrapped by a nice little javascript api

var data = new Array();
// var grid = new GRID();
// helpers for udefined stuff
var doNothing = null;
//instantiate grid
// var data_grid = Object();
var dg = new GRID();
function foo() {
var pn_ajax = init_ajax();
pn_ajax.add_pnmodapifunc('pnAjax', 'user', 'test', {}, function(ret){
data.push(ret);
});
pn_ajax.add_pnmodapifunc('pnAjax', 'user', 'test', {}, function(ret){
data.push(ret);
});

var cb_fin = function() {
var cols = {
col1: ["Index", null, null, true],
col2: ["PLZ", null, "69px", null],
col3: ["Name", null, "200px", null],
col4: ["Land", null, "100px", null],
}
dg.build(document, 'dg', cols, data);
}

pn_ajax.add_on_finalize(cb_fin);

pn_ajax.execute();
}

 
thanks to e-voc for the basic datagrid wrapper api, its really simple.

Seeing Sebastian Bergmann on the PHPUG Munich, presenting PHP-Unit2 makes me partly Happy. I am not this far away from the PHP Test thing as i thought.
I guess i need to work a bit more into mock objects and my tutorial on functional php software testing, that will enlight people a bit more practically, and ostly it is thought to enlight myself on first hand, but why not tell that stuff to others then ;)

With a little help from e-voc i made the json serializer work.
No well go soon to be async and the all will be much better.

Besides i started work hard on the integration of jsobjects. I guess ill have to rewrite some of the code to make it work w.o. evil eval.
The grid example is still simple, dropping notices etc .. but the api is growing. I dont have this much time, bus as ill make pnAjax a important component on the pncommerce project, reusing the grid and the tree for basic gui layout, it will get a lot of commits anyway.

The big Ajax discussion has come in place to postnuke. Again it looks like writing down things, instead of write code in the first blink of an idea is considered to be a bad thing there. Markwest requested a unified ajax Project for the postnukeworld, but i guess that will not take place .. why ?

The Approaches are too different

Chestnuts Ajax example is
- not using serialization
- relies on handcoded servers
- has no framework components
- has no event model catching errors from the serverside

Frank Schummertz pnForum Stuff:
- is using AHAH data (returning HTML instead of XML or serialized data
- relies on handcoded servers
- has no framework components
- has no event model catching errors from the serverside

pnAjax
- uses json data serialization
- has a tested gui kit / framework
- relies on no handcoded server to use ajax funcs on the client
- has a event model catching errors from the serverside

Anyway, i am really opposing doing 3 times the same work, but as i see from the mailing list postings, there is a request for a lot of functionality that is already in pnAJax. So i guess it was worth the time to sit down and thing of a framework that can totally integrate with postnuke instead of building stuff on top, that might be sexy, but is ugly code.

You migth call me a thread , but if there is no movement twoards a performant approach for the data stuff and nothing more that, hey, integrate scriptacolous into postnuke, Ill not be the one to jump in and make the lead on such a project .. ill guess it takes a year to explain to others what they need to develop .... pnAjax is rather complex on the code side of the project development ... but easy to use for the final developer, implementing his own apps with just a buch of loc.

eval evaluates a string as js code, you should never reach a state where you need such a lame solution, that is improper programming. eval is
also very slow, because it requires recompilation of the code at runtime. don't use eval.

p.s. there is a point where you might need eval. But all in all hes corect ;)

Its Release Date and following text comes upon my eyes on the Postnuke mailinglist:

i'd suggest that everyone (especially our QA *smile*) grabs the current CVS snapshot for a brief test, especially regarding short urls and the new safehtml filter (to be configured in administration-settings).
So far .. some stuff any QAist needs before he jumps in checking a release:

1. Voice
Voice just means that found bugs are accepted and not discussed away because developers feel pissed about that great number of bugs that are found. If your ego can not live with harsh criticism, dont let someone QA your work, better do a direct rc to the public as soon as all bugs are closed.

2. No More Open Bugs
Sorry, fix all known bugs for the actual Version. No need to write more.

3. Documentation
Write a Documentation of the changes done and what they exactly should implement. A good thing is to write and stick to a rfc. So any one can test if thatpiece of code does exactly what you expect. If you dont have a rfc, you a re in charge to write this piece of information down for your QA. CVS Logs alone is NOT enough. Especially when the product is as big as Postnuke, a lot of written stuff has to be there and processes run silently with little information.

• all bugs in a tracker
• complete api docs
• brief descriptions of new features
• list of changed 3rd party components

and more

4. Time
Dont seta date for release before QA has researched and Dev Team has dgged through the bugs and the changes are reviewed by the qa and its sure that fixes are fixes