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

Re: Ajaxify

Reply #15

https://github.com/emanuele45/Dialogo/commit/180ec736fa9e2c6a3cc5041ed78b46595421251e
https://github.com/emanuele45/Dialogo/commit/a716a27c97f0f9a72f9ccef76aee0b9813755b03

Another couple of commits to let the "notify" button work properly without page reload.

Disregard is on the way. :P
Bugs creator.
Features destroyer.
Template killer.


Re: Ajaxify

Reply #17

Quote from: TestMonkey –
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).

Re: Ajaxify

Reply #18

Quote from: groundup –
Quote from: TestMonkey –
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.
Last Edit: May 12, 2013, 02:12:43 am by TestMonkey
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Ajaxify

Reply #19

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...
Bugs creator.
Features destroyer.
Template killer.

Re: Ajaxify

Reply #20

Technically if you're deleting, you need to fix all the 'Reply #n' numbers on all the posts too, right?

Re: Ajaxify

Reply #21

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...

Code: [Select]
// 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;
    }

    call_integration_hook('integrate_view_exit', array(&$context, &$status_code, &$template, &$output);

    http_status_code((int) $status_code);
    die($output);
}

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
Last Edit: May 13, 2013, 12:58:10 am by groundup
Come work with me at Promenade Group

Re: Ajaxify

Reply #22

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.
Bugs creator.
Features destroyer.
Template killer.


Re: Ajaxify

Reply #24

We had to save something for 1.1. :P
Bugs creator.
Features destroyer.
Template killer.

Re: Ajaxify

Reply #25

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.

Re: Ajaxify

Reply #26

Yep, that looks quite the way it should work...
Bugs creator.
Features destroyer.
Template killer.

Re: Ajaxify

Reply #27

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.

Re: Ajaxify

Reply #28

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...
Bugs creator.
Features destroyer.
Template killer.