Skip to main content ↑ ↓
Topic: Ajaxify (Read 15775 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Ajaxify

Y'know. Since I'm working now on our previews... I thought I could write this down.

What are the next candidates for an ajax bit of functionality?

Where is it missed? What are the messages to the user that could be sent over more smoothly for UX?
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Ajaxify

Reply #1 –

 IchBin would love quick reply ajax
Success is not the result of spontaneous combustion, you must set yourself on fire!

Re: Ajaxify

Reply #2 –

That would rock, providing it doesn't interfere with having the full editor for quick reply.

Oh and we can haz attachments innit? And preview on teh same page mit der ajax stuffz?

Oh and teh draggendroppy file uploadz. Kthnx. :D
Last Edit: December 12, 2012, 05:47:39 pm by Antechinus
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Ajaxify

Reply #3 –

Save draft button?
Polls preview?
Collapsing/expanding of categories?
Notify, mark as read, disregard, etc. buttons?
Last Edit: December 14, 2012, 08:10:23 am by emanuele
Bugs creator.
Features destroyer.
Template killer.

Re: Ajaxify

Reply #4 –

Those are good possibilities too. However, one thing to bear in mind IMO is load time. If the content is such that a normal page load wont be any slower than using AJAX, we should probably avoid the bloat. If using AJAX can actually save time, go for it.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Ajaxify

Reply #5 –

 Feature Cat likes this, and regrets not having started this topic itself.


Quote from: Antechinus – Oh and we can haz attachments innit?
And solve #issue attachmentz differently. 'Tis a bug.


Quote from: emanuele – Save draft button?
Collapsing/expanding of categories?
Notify, mark as read, disregard, etc. buttons?
Likes. As far as I can tell they really reduce load times, not expand them.

Collapse/expand categories: collapse should be immediate and you only need to notify the server, afaics. Save draft already has the implementation Spuds has made.
Last Edit: December 15, 2012, 11:37:47 pm by Feature Cat

Re: Ajaxify

Reply #6 –

Quote from: Feature – Collapse/expand categories: collapse should be immediate and you only need to notify the server, afaics. Save draft already has the implementation Spuds has made.
True. Though ajaxify only the collapse without the expand, would be a bit...lame? :P
LiveGallery - Simple gallery addon for ElkArte

test

Re: Ajaxify

Reply #7 –


Quote from: Feature Cat –
 Feature Cat likes this, and regrets not having started this topic itself.


Quote from: Antechinus – Oh and we can haz attachments innit?
And solve #issue attachmentz differently. 'Tis a bug.


Quote from: emanuele – Save draft button?
Collapsing/expanding of categories?
Notify, mark as read, disregard, etc. buttons?
Likes. As far as I can tell they really reduce load times, not expand them.

Collapse/expand categories: collapse should be immediate and you only need to notify the server, afaics. Save draft already has the implementation Spuds has made.

Quick test for quotes from Feature Cat
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Ajaxify

Reply #8 –

Question: what's the best way to handle these?
As a special case of the controller (i.e. if (isset($_GET['xml']))) or with their own "ajax" action (using the action_xmlhttp function and sub-actions)?
Bugs creator.
Features destroyer.
Template killer.

Re: Ajaxify

Reply #9 –

Quote from: emanuele – Question: what's the best way to handle these?
As a special case of the controller (i.e. if (isset($_GET['xml']))) or with their own "ajax" action (using the action_xmlhttp function and sub-actions)?
3 output strategies - HTML (default), JSON, XML. If ($query_string ends in .json) $output_strategy = json elseif ($query_string ends in .xml) $output_strategy = xml else $output_stategy = html

If output_strategy = json ? loadJSONTemplate($template); die(json_encode($output));

The JSON and XML templates would be the same - they would just build a variable that would get json_encoded/written as xml and then that gets output.

Re: Ajaxify

Reply #10 –

You could even start to build it as a RESTful API.

Re: Ajaxify

Reply #11 –

Quote from: emanuele – Question: what's the best way to handle these?
As a special case of the controller (i.e. if (isset($_GET['xml']))) or with their own "ajax" action (using the action_xmlhttp function and sub-actions)?
That... is a question. :D

Quote from: groundup – 3 output strategies - HTML (default), JSON, XML. If ($query_string ends in .json) $output_strategy = json elseif ($query_string ends in .xml) $output_strategy = xml else $output_stategy = html

If output_strategy = json ? loadJSONTemplate($template); die(json_encode($output));

The JSON and XML templates would be the same - they would just build a variable that would get json_encoded/written as xml and then that gets output.

Makes sense, but there's an issue: html/json/xml are not only output, they need data that the controller must compute and send. I don't think it's the same data... Specially right now, we do different things. Part of the strategy is to pick only some stuff to send, etc.

QuoteAs a special case of the controller (i.e. if (isset($_GET['xml'])))
How about, as method of the controller:
i.e. action_members_xml()
One (perhaps not great but ok IMO) way,
 
  • the dispatcher forwards to the "parent" action,
  • the if (isset($_GET['xml'])) forwards to action_members_xml().
Better...
 
  • the dispatcher makes the decision. For actions with xml, it forwards to the respective _xml() method.

Makes sense?

On a case by case basis, we can see how to do with those more complex cases, where the implementation of xml action is more deeply embedded in the "parent" action. i.e. they have some if isset(xml thingie), do something, then continue with the rest, then one more isset etc. I'd leave them alone atm, tbh. Just do differently with new ones.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Ajaxify

Reply #12 –

The action_blabla_xml is something I was considering too (a bit after I posted), yes (that in the end it's just a special case of the controller anyway :P O:-)).

Let me see what bugs I can write. :P
Bugs creator.
Features destroyer.
Template killer.

Re: Ajaxify

Reply #14 –

Thank you!! :)

Even if we'd continue with Xml controller, one day we'd have needed to stop anyway. It'd become fatter than Feature Cat, and that's saying something.
Better off, methinks, where the logic is (requests on members received by actions in a members-dedicated controller, requests on news received by actions in news-related controller, whatever). It's a request too.
The best moment for testing your PR is right after you merge it. Can't miss with that one.