[RFC|Merged] AJAX

These requests for comments/change have lead to an implemented feature that has been successfully merged into the 3.1/Ascraeus branch. Everything listed in this forum will be available in phpBB 3.1.
Post Reply
User avatar
naderman
Consultant
Posts: 1727
Joined: Sun Jan 11, 2004 2:11 am
Location: Berlin, Germany
Contact:

Re: [RFC|Merged] AJAX

Post by naderman »

It should certainly be using data-* attributes rather than invalid "ddajax" and "actf" attributes I think? Unfortunately I'm not too aware how current ajaxify works either. Could you maybe outline how they differ from each other and why one is better than the other?

User avatar
DionDesigns
Registered User
Posts: 51
Joined: Sat Apr 21, 2012 4:29 am
Location: Uncertain due to momentum
Contact:

Re: [RFC|Merged] AJAX

Post by DionDesigns »

Yes, in a large-scale production environment, the code should be using data-* attributes. However, the attributes I'm using work just fine, and should continue to work fine into the forseeable future.

I suppose the big difference in my method is it adding "ajaxify" support to specific template data. If you want error messages in templates to display with no page refresh, that can be done. If you want specific pages to display in a lightbox, that can be done as well. I just "ajaxified" the registration agreement page on my board by adding the appropriate support in the ucp_agreement.html file.

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. There is no plugin overhead, and the only requirement is jQuery 1.4 (or later) being loaded before the new "ajaxify" javascript support functions are loaded. In fact, if the support functions were written without the use of jQuery, it would not be necessary to add the overhead of jQuery. (I consider certain jQuery features to be real timesavers and use them in almost every script I write.)

Because the lightbox has been built into my method, MOD/style developers have instant access to a lightbox effect in templates. A simple javascript function such as this:

Code: Select all

function lightbox_display(message) {
    document.getElementById('lightbox').style.display = 'block';
    document.getElementById('msg-ajax').style.display = 'block';
    set_ajaxbox(message);
}
will display a message in a lightbox, and the message can be generated from anywhere. Such a function can be called in an onclick(), onchange(), or onsubmit() event.

As I said, if this method isn't of interest, that's fine with me. If any of the developers would like to test out these features on my board and aren't comfortable with registering as a member (I disallow disposable email addresses), contact via via PM or email, and I'll provide you with a test account.

User avatar
Arty
Former Team Member
Posts: 985
Joined: Wed Mar 06, 2002 2:36 pm
Location: Mars
Contact:

Re: [RFC|Merged] AJAX

Post by Arty »

DionDesigns wrote:Yes, in a large-scale production environment, the code should be using data-* attributes. However, the attributes I'm using work just fine, and should continue to work fine into the forseeable future.
Just because it works, doesn't mean its correct. Please do read spec: http://www.whatwg.org/specs/web-apps/cu ... attr-data-*

ecwpa
Registered User
Posts: 181
Joined: Mon Jan 24, 2005 2:10 am
Contact:

Re: [RFC|Merged] AJAX

Post by ecwpa »

nickvergessen wrote:Subscription and bookmarking and other confirmbox places are using ajax.
what about polls?
Slightly better English than it was in 2005, still improving :D

Senky
Extension Customisations
Extension Customisations
Posts: 315
Joined: Thu Jul 16, 2009 4:41 pm

Re: [RFC|Merged] AJAX

Post by Senky »

ecwpa wrote:what about polls?
+1!!!

User avatar
callumacrae
Former Team Member
Posts: 1046
Joined: Tue Apr 27, 2010 9:37 am
Location: England
Contact:

Re: [RFC|Merged] AJAX

Post by callumacrae »

Senky wrote:
ecwpa wrote:what about polls?
+1!!!
http://tracker.phpbb.com/browse/PHPBB3-10383

There isn't an RFC for it, because there's only really one way to do it.
Made by developers, for developers!
My blog

User avatar
DionDesigns
Registered User
Posts: 51
Joined: Sat Apr 21, 2012 4:29 am
Location: Uncertain due to momentum
Contact:

Re: [RFC|Merged] AJAX

Post by DionDesigns »

Arty wrote:
DionDesigns wrote:Yes, in a large-scale production environment, the code should be using data-* attributes. However, the attributes I'm using work just fine, and should continue to work fine into the forseeable future.
Just because it works, doesn't mean its correct. Please do read spec: http://www.whatwg.org/specs/web-apps/cu ... attr-data-*
I have read it, and I stand by my comment above.

However, since people seem to be focused on a relatively insignificant part of what I posted, I have edited my posts above to use data-* attributes. Now...given that my method offers built-in support for "ajaxified" form submission and error messages, uses fewer resources and less code, and is backward-compatible to at least 3.0.4 (didn't check any further back), I believe it should be given consideration for inclusion into Ascraeus.

Oleg
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am
Contact:

Re: [RFC|Merged] AJAX

Post by Oleg »

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.

User avatar
DionDesigns
Registered User
Posts: 51
Joined: Sat Apr 21, 2012 4:29 am
Location: Uncertain due to momentum
Contact:

Re: [RFC|Merged] AJAX

Post by DionDesigns »

Thank you for your input...that is all I asked.

1. By "core" I mean the .php files, and to a lesser extent the support javascript files.

2. I can see why you would call what I did "spaghetti code", though it's really no more than a difference in philosophy. I don't believe in cluttering up the database with configuration options, which is the method used by phpBB. Clearly what I did in the template (and in set_ajaxbox) could be made into configuration options.

3. I don't think you understand how NOAJAX works. It will only activate if ajax=y is appended to a URL. THAT will only happen if the client is using a supported browser and has javascript turned on. If those aren't true, then all AJAX support is disabled and phpBB will work as it always has done. By having the "ajaxify" support in the templates as opposed to javascript functions, it will be style-independent, though the cost will be initially adding that support in the Ascraeus templates, and forcing style developers to update their pre-Ascraeus templates if they want a style/theme to have "ajaxify" support in Ascraeus.

4. I agree about inline styles, but when reading data from an AJAX GET/POST request, it is not possible to use event listeners in that data without creating true spaghetti code.

5. I'm not sure what you mean here. Let's take the code I posted for viewtopic_body.html as an example. Once "ajaxified", if a user clicks the Delete button in a post, the "Are you sure?" box is displayed in a lightbox. If a user clicks "No", they are returned to the page. If they click "Yes", they see the "Deleted Successfully" message in the lightbox and are taken to the $redirect_url URL from the meta_refresh() function. That's exactly how things currently work...except that the user never leaves the page they were on. The same is true if a user votes in a poll -- when they click the Submit Vote button, they see the "Your vote has been cast" message in a lightbox, and are taken to the $redirect_url URL from the meta_refresh() function. This will be true regardless of the style/extension, as long as the style/extension maintains the "ajaxify" support in the message_body.html and confirm_body.html templates. This is the benefit, and improvement, of using NOAJAX conditionals in templates.

My method goes one step further. If, for example, the user submits a form which contains an error, the error is displayed in a lightbox. You can see an example of this by going to my site (URL in my post profile) and clicking the "Contact Us" link at the bottom right of the index/home page. You'll be directed to a contact form, which is a custom version of the page to create a new topic. Now click either the Preview or Submit buttons. On a regular board, you would see a page refresh with error messages above the posting area. An error message that can be missed. On my board, you will see error messages in a lightbox. And again, these messages will be displayed properly independent of style/extension due to the NOAJAX conditionals in the templates. If you want, feel free to add a subject and post text to test out the "ajaxified" preview and submit actions.

6. Documentation...you are 100% correct. If this were something you wanted to pursue, I would write the necessary documentation in whatever format you desire. But for "proof of concept", I see no reason to write beyond what is in my posts.

7. If that is what you believe, I respect your decision, and I thank you for taking the time to look through what I posted. However, I think your belief is mistaken, and I hope that (3) and (5) above demonstrate that.

User avatar
tbackoff
Registered User
Posts: 180
Joined: Sat Jun 12, 2010 3:25 am

Re: [RFC|Merged] AJAX

Post by tbackoff »

I apologize if this has been mentioned before (I tried looking, but couldn't find it). Does this include "mark topics/forums read"? I ask because if I click that and then click the link to return to where I was, the topics get marked as read. However, if I let it sit there and let it go away on it's own (not clicking the link), the topics may get marked as read, but the icon does not change colors. You can test this here.

Post Reply