Refresh the page or do a ridiculous amount of JQuery?

When a开发者_Go百科dding a comment to a page I have the option of either using location.reload(true); or executing a large amount of JQuery to dynamically add a DIV to the page. I already have code for interpreting the comments on the page itself when it loads so to have to duplicate it in JQuery not only adds to code duplication and confusion but also means when I want to change how the comments are parsed I have to change it in the PHP aspect of things and the JQuery aspect. Is it worth it or should I just refresh the page?

This is a "discussion" question, so although I'll think out loud with you, I am stopping short of declaring the "better" way to solve this problem.

1. Client/Server Coupling. You mention that you are worried about coupling between the client/server; that is for the jQuery solution, if you want to change something about the comments you'll have to alter both client and server logic. This is significant in terms of maintainability. If you foresee a significant re-design in the way comments are handled, you want to keep these concerns separated, and just re-load the page.

2. UI Flow Consideration. Does re-loading the page break the flow of your UI? If you are hosting a stateful web application, then this is a significant consideration. If you are hosting a standard blog/CMS-type application, re-loading the page probably isn't a big deal.

3. Amount of effort involved. How much time would it take to write this jQuery routine? An hour? A day? Looks like simply reloading the page is a quick, simple solution for a version 1.0; you can always make improvements later. Also consider the consequences of the decision, and how much effort any future changes will require.

The validity of this discussion, however, is only as valid as your design. It's often instructive to take a step back and look at your design. Why does this problem even exist? Is there a design change you could make to solve this problem before it even happened? Hmm...

-tjw

My approach would be to submit the comment to the server, and get an XML response with the contained HTML you use to display the comments. With the XML response you can use jQuery to append the new comment to the thread.

That portion of HTML can be generated with PHP the same way you do when reloading the page.

That way, you only modify PHP code.

I would say it depends, either you do everything with jquery/javascript, or you reload on changes. Pick a path, and structure everything to work with it. I personally prefer using jquery, so not only would I add the post with jquery, I would load all the posts with jquery.

It all depends on whether or not the difference will be noticeable enough that the cost to your users, for not doing it in js, will be higher than the gain you will have from it.

That is, if you care about your users experience as much as you do for you own convenience ;)

In the end, only you can answer this question, since the person it needs to be worth it to, is you.

Will your users prefer that you use javascript and update the page without a pageload: most likely yes.

There are several different options here depending on what exactly you need. One option is to do a full post and, sometimes, it is correct. In almost all cases it should be the default in the situation where javascript is not available (screen readers, for example). To that you can add (progressive enhancement) either the ability to do an AJAX request returning html, i.e., post back to a method that generates part of the page and simply replace it. If you design your page to incorporate this partial view when originally generated, you don't even have to duplicate code -- you just use it in a different way when called via AJAX. Alternatively, you can do an AJAX request returning data or manipulate the data on the client entirely on the client to update the view and only push any updated data back to the server. Which you choose is entirely dependent on the application and your preference. Based on your post, I'd suggest look at MVC frameworks that allow you to generate partial views as it seems that addresses your biggest concerns. It keeps the amount of javascript on the page small and focused on simply making requests and updating bits of the page, while leaving the formatting and data parsing on the server -- all accessed via AJAX as necessary.

It seems like there are two questions:

1. should you actually bother to use Ajax for this?
2. if you use Ajax, is there an approach to avoid duplicate code?

Question 1: I believe this isn't specifically a programming question: whether the Ajax is necessary depends on the requirements of your app and users (or client or manager or product manager-- probably not you). Does the refresh matter? Well, it can be a little smoother without-- and you can even animate it nicely. The good news: you have a "working version" and now you know how much work it will be to do the Ajax-- you can get a more informed estimate to those paying the $.

Question 2: My rule is to not write the same code twice-- even if you write it once in PHP and once in Javascript. This is what you are frustrated with. Here's my reasoning when I'm going through this:

You have your comment and you need to transform it to HTML. You can do this in one of two places: server or client (Javascript)-- and not both. Therefore...

• if you implement rendering the comments on the server, you should carry this through with Ajax architecture. Therefore, the Ajax response should not return XML or JSON, but should return and HTML segment that can simply be inserted into the DOM. You can share the same rendering code on the back end between initial page display and Ajax resonse.

• if you want to implement the rendering in Javascript, use the same rendering code when the page first renders as you do when are responding to Ajax requests. This is a little counter-intuitive to some people-- but really is the secret to avoiding duplication. Pick a standard "structured format" for the comments-- XML or JSON. Write a single function that knows how to render it to the page. Then you can use the same code to handle the Ajax business.

Which of these paths you choose depends on quite a few factors. If you have a public web site and care about the comments being picked up by search engines, technique 1 will be a little easier. If you are not so concerned with that, and anticipate lots of dynamic Javascript behavior, the latter option will serve you better.