I read all of your posts here.
1.
By having most "ajaxify" support in the templates, the amount of core support code required is minimal, as you can see in my previous posts.
We are talking about implementing ajax in the core, therefore the goals are somewhat different from hacking ajax on as a third-party modification. We care about the total size of changes needed to phpbb. If adding something in the "core" will reduce the amount of changes needed in templates, we should probably add it to the "core".
I put the word "core" in quotes because generally everything shipped in phpbb.com packages we consider "core". I'm interested what meaning you attach to it.
2.
set_ajaxbox - this is spaghetti code. I don't know what part of it is meant to demonstrate the approach vs being code that is supposed to be included in phpbb, but none of "x", "STT", "|" or inline 750 are probably acceptable.
We want to have a solid architecture for ajaxifying things in phpbb. This means the code should be readable and flexible. There are many styles developed for phpbb which will have different markup. There are modifications that will become extensions that alter functionality and by necessity also markup. Ajaxification should as much as possible continue to work in the presence of nonstandard styles and extensions.
3.
NOAJAX - this is probably not what we want. You are close to duplicating all ajaxified code; this is probably not going to be acceptable. There should be one copy of the markup which js then is applied to.
Separately from duplication concerns, when a guest opens a board page you cannot know whether to turn ajax on or off. The markup + js that is served should work in cases when js is both on and off on the client side.
4.
Inline event handlers are probably not going to be acceptable. Part of this is due to styles - as mentioned third-party styles should work with core ajax as long as the elements are sufficiently similar. Part of it is due to separation of markup and js - this is required for maintainability.
5.
I am not seeing where in the code you posted the content of the page is updated. This is a problem with the current implementation - after you perform ajaxified actions you receive no feedback that the action was performed.
6.
Similar to the current ajax implementation, there is insufficient documentation written. I get the impression that data-ajax="" on links makes them ajaxified, subject to me not receiving any feedback on such actions, but beyond this I'm really not sure how anything works. And the only reason I was able to figure out data-ajax="" was because it's done the same way in the current ajax implementation.
As I said for the current ajax implementation, there should be two separate documentation collections: inline documentation for phpbb developers modifying code and user documentation explaining how to ajaxify actions that might be found in extensions. The user documentation should have a lot more prose than code.
7.
My impression of the proposed alternative is it more or less does the same thing we already have in a different way. It is not an improvement in the architecture or quality of the code implementing it.
The characteristics of a true improvement would be:
a. Clear separation between layers (markup/js).
b. Comprehensive developer and user documentation for all added code.
c. All supporting code should be readable and maintainable.
d. Specific ajaxification code should be as small as possible.
e. Ajaxification should survive when nonstandard styles are used as much as possible.
f. Ajaxification should survive when extensions are present as much as possible.
g. Ajaxification that is done in the core should remain in the core, meaning neither nonstandard styles nor extensions should need to duplicate code already present in the core.
If your proposal does actually improve in one of these areas please point out the specifics.
