Elk Development => Feature Discussion => Topic started by: TestMonkey on December 12, 2012, 09:29:04 am
Title: Ajaxify
Post by: TestMonkey on December 12, 2012, 09:29:04 am
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?
Title: Re: Ajaxify
Post by: IchBin on December 12, 2012, 04:50:59 pm
/me would love quick reply ajax
Title: Re: Ajaxify
Post by: Antechinus on December 12, 2012, 05:44:34 pm
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
Title: Re: Ajaxify
Post by: emanuele on December 14, 2012, 08:07:51 am
Save draft button? Polls preview? Collapsing/expanding of categories? Notify, mark as read, disregard, etc. buttons?
Title: Re: Ajaxify
Post by: Antechinus on December 14, 2012, 03:05:06 pm
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.
Title: Re: Ajaxify
Post by: Feature Cat on December 15, 2012, 10:20:31 pm
/me likes this, and regrets not having started this topic itself.
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.
Title: Re: Ajaxify
Post by: FF / MFG on December 16, 2012, 07:38:47 am
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
Title: Re: Ajaxify
Post by: TestMonkey on December 17, 2012, 02:12:47 am
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
Title: Re: Ajaxify
Post by: emanuele on May 10, 2013, 10:18:18 am
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)?
Title: Re: Ajaxify
Post by: Joshua Dickerson on May 10, 2013, 01:56:53 pm
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.
Title: Re: Ajaxify
Post by: Joshua Dickerson on May 10, 2013, 01:58:41 pm
You could even start to build it as a RESTful API.
Title: Re: Ajaxify
Post by: TestMonkey on May 10, 2013, 03:35:24 pm
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.
Title: Re: Ajaxify
Post by: emanuele on May 10, 2013, 05:56:01 pm
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
Title: Re: Ajaxify
Post by: emanuele on May 10, 2013, 07:25:27 pm
Title: Re: Ajaxify
Post by: TestMonkey on May 11, 2013, 07:55:29 am
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.
Title: Re: Ajaxify
Post by: emanuele on May 11, 2013, 08:58:07 am
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.
It isn't a matter of different, you are saying the XML/JSON strategy might have more data. That is a horrible way to design it. The XML/JSON strategies would most likely have less data than the HTML.
In a well-designed MVC application, the controller would pass the variables that are needed to the view. Not through $context which holds everything. It becomes even easier at that point to create a XML/JSON strategy. If there is no template loaded, the output is an object of the variables passed. Menus, links, images, etc. don't get passed in to the view, they get grabbed via a view helper. In other words, what gets passed is on the data that is special for that page.
Since Elkarte doesn't have that and it probably won't for the foreseeable future, the next best thing is to use templates. Instead of doing echo 'some html here'; you do echo json_encode(array('topic_title' => $context['page_title'], 'messages' => $context['messages'], 'posters' => $context['posters'])); So each template builds the output variable. The same thing goes for the XML version. You don't even need two templates for XML/JSON. Use one template and call different functions based on the output strategy.
One more example: the action doesn't have a normal return value, it just redirects or returns an error. The XML/JSON strategy stops redirectExit(). It would return a HTTP status code like 404. It would return {error: "The topic you are trying to reply to doesn't exist"}. Say it was a success and you succesfully posted a reply. The HTTP status code would be 200 and you return {true} (or you could return the new post and pass that to a JS function that adds it to the page).
Title: Re: Ajaxify
Post by: TestMonkey on May 12, 2013, 01:46:29 am
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.
It isn't a matter of different, you are saying the XML/JSON strategy might have more data. That is a horrible way to design it. The XML/JSON strategies would most likely have less data than the HTML.
I am not saying the XML/JSON might have more data. I am saying they have less data, and/or different data than HTML. If I remember correctly off-hand, there are requests only handled by xml, which don't have a html equivalent.
ETA: ah, I see the origin of the misunderstanding. You consider 'strategy' is picked by the template only. I do not. It's picked by the dispatching/controller levels. Look at HTML: HTML is an output strategy (in your own wording here), and it's surely picked by dispatching/controller. Take a look at Ema's branch. He already designed it.
Otherwise we seem to be saying the same things using different words and grumbling on words alone. :)
QuoteSince Elkarte doesn't have that and it probably won't for the foreseeable future, the next best thing is to use templates. Instead of doing echo 'some html here'; you do echo json_encode(array('topic_title' => $context['page_title'], 'messages' => $context['messages'], 'posters' => $context['posters'])); So each template builds the output variable. The same thing goes for the XML version. You don't even need two templates for XML/JSON. Use one template and call different functions based on the output strategy.
One more example: the action doesn't have a normal return value, it just redirects or returns an error. The XML/JSON strategy stops redirectExit(). It would return a HTTP status code like 404. It would return {error: "The topic you are trying to reply to doesn't exist"}. Say it was a success and you succesfully posted a reply. The HTTP status code would be 200 and you return {true} (or you could return the new post and pass that to a JS function that adds it to the page).
Please take a look at Ema's way to do it now. (or when he PRs it) If there are improvements you see fit, suggest them there or add a PR to his branch. (or after we take in stuff). I'm not sure, but it might be useful to review how we do with return codes/redirectexit stuff.
Title: Re: Ajaxify
Post by: emanuele on May 12, 2013, 06:37:51 pm
Okay, buttons-wise, I think the most interesting right now to make ajax are approve/unapprove and delete. The first should be relatively easy, the second implies fetch a new message with all the theme crap. A bit more difficult...
Title: Re: Ajaxify
Post by: Arantor on May 12, 2013, 07:05:02 pm
Technically if you're deleting, you need to fix all the 'Reply #n' numbers on all the posts too, right?
Title: Re: Ajaxify
Post by: Joshua Dickerson on May 13, 2013, 12:52:46 am
The way emanuele is doing it works but in the end it is going to be a lot of duplicitous code. I would also say that you should make it possible for more formats in the future and thus make a start to a real view...
// I am writing this in the reply window so it might be broken. function viewExit(array $context, $status_code = 200, $template = false) { call_integration_hook('integrate_pre_view_exit', array(&$context, &$status_code, &$template));
switch ($GLOBALS['context']['output_strategy']) { case 'json': $output = empty($template) ? json_encode($context) : loadJSONTemplate($template, $context); break; case 'xml': // This obviously requires another function to create a XML map $output = empty($template) ? xml_encode($context) : loadXMLTemplate($template, $context)); break; }
As soon as I wrote it I wanted to rewrite it but I don't feel like doing it in the post window. The point of the $template is to allow you to change the setup of the $context. The same thing would be done with HTML.
I used a switch, but I would prefer to have a DIC with functions for each strategy. More strategies could be serialized (PHP, igBinary, etc), YAML, Protobuf, INI, custom for debugging, or anything. You don't want to put how your output is handled in every controller.
EDIT: added a gist - https://gist.github.com/joshuaadickerson/5566246
Title: Re: Ajaxify
Post by: emanuele on May 13, 2013, 05:21:45 am
Quote from: Arantor – Technically if you're deleting, you need to fix all the 'Reply #n' numbers on all the posts too, right?
Yep, that too.
Title: Re: Ajaxify
Post by: ahrasis on November 26, 2013, 02:59:49 pm
Testing whether this quick reply ajax is implemented here.
Edited: So it is implemented. Great!
Title: Re: Ajaxify
Post by: emanuele on November 26, 2013, 03:26:52 pm
We had to save something for 1.1. :P
Title: Re: Ajaxify
Post by: Xarcell on November 27, 2013, 01:12:13 pm
I have mixed feelings about the Ajax Quick Reply. Xenforo has it and it causes problems if you post before reading all of the messages. Ajax Quick Reply only seems smooth if your at the last post, or you don't see your reply ajaxed when not on the last post.
Xenforo shows a notification when you Ajax Quick Reply saying there are X amount of messages, would you like to see them. ::)
In my opinion, I only see it working well if when you Ajax Quick Reply, you don't see your post and you never leave from where you at when not posting at the last post. For example, there are 4 pages of posts, and I'm on page two. If I Ajax Quick Reply on that page(saying quoting someone), then when I post I just get a notification saying "posted", and I don't leave from where I'm at(obviously), but I also DON'T see my reply unless I scroll to the end of page 4. Seeing my post applied on page two(but not really), just causing confusion. People at Xenforo still poptart about it and it's been over a year, hence adding the notification saying there are x unread posts in that topic left, which doesn't really seem to lessen the confusion.
Title: Re: Ajaxify
Post by: emanuele on November 27, 2013, 02:01:00 pm
Yep, that looks quite the way it should work...
Title: Re: Ajaxify
Post by: ahrasis on December 01, 2013, 12:03:25 pm
So there is a problem when we are trying to use ajax reply when we are not in the last page.
May be can simply add this:
"With Quick-Reply you can write a post when viewing a topic. And if you posted while you are at the last page, you can see your written post without loading a new page. You can still use bulletin board code and smileys as you would in a normal post."
Or, can try to set quick reply to be hidden except if on the last post / page.
Title: Re: Ajaxify
Post by: emanuele on December 01, 2013, 03:52:00 pm
I would love to be able to "quick-reply-while-reading-the-topic" instead of have to always remember where I am, so a message (green? :P) at the end of the page with "your reply has been posted [[here]]" would work for me.
But, I think there is even more: endless scrolling. I think it could be nice to have that too in 1.1 but combine all these together may be tricky...