CODEWITHSUNDEEP
phpjqueryajaxjson
ngplayground
ngplayground

Reputation: 21617

Which is better practice? Getting HTML from Jquery Response

This is just a question as to find out what and how people do this, but

Say a user adds something to a list, when it's done, it runs the ajax below and updates the .user-stream-list 

$.ajax({
    url: "user-stream-list.php",
    success: function(data){
        $(".user-stream-list").html(data);
    }
});

but the user-stream-list.phpresponse for example is 

<li class='feed'><a href='http://www.theverge.com/rss/index.xml' data-fid='13' data-uid='15'><img class='favicon' src='https://www.google.com/s2/favicons?domain=www.theverge.com'><span class='title'>The Verge -  All Posts</span><span class='options'><span class='addcat' data-fid='13'>+</span><span class='delete'>×</span></span></a></li>

Would this be acceptable in web development? Or should I really be passing it through as json and sort it into html afterwards?

Upvotes: 2

Views: 102

Answers (4)

melc
melc

Reputation: 11671

I agree with bishop's answer, i think it depends on the architectural design of your system. If for example you want to use a js templating system, create a mobile device system, serve your data to other systems or something else that communicate with your back end then it is best to serve json from your server. However even if you choose to prepare HTML server side using php, which is very common and acceptable as others noted in this thread, it is best to separate the entities creating the data and the ones creating the html code/template in order to be flexible and have the best of both worlds in the future.

Upvotes: 2

Mark
Mark

Reputation: 1386

Answers to this question could be broad, and are very opinion based, however I'll give my 2 cents.

Since you tagged the question as PHP, I assume your application is primarily PHP based for the server side code. Since all of your views will be generated by PHP, I'd keep all templating on PHP's side. Why? Maintainability and clarity. Having to chase down different sources of view generation is time consuming and misleading. IMHO it's better to keep all of the logic in on one side/language, and something like client-side JavaScript should be used for things a server side language cannot do (AJAX, transitions etc.).

This approach will allow for a smarter (IMO) view generating, its also very clear and makes it easy to alter your templates/views (remember, you should be writing code with other people in mind).

Upvotes: 0

Dharman
Dharman

Reputation: 33238

If I understand you right you are worried if you should pass complete HTML code from the server or simple just the data. Well both approaches are good. It all depends on your needs and implementation.

For example you may want to add some inline styles to certain items in your list. You can generate that on the server side which would be much easier and send the whole HTML code. You may also want to add some microdata. Passing each of this parts separate as JSON would be unnecessary.

On the other hand you may already have premade HTML code and you only want to insert data into it. In this case passing the whole tag would be a waste of bandwidth.

There are also other factors you need to consider like: would it be faster to compile the data on server side or on the client side, do I need to save bandwidth or can I allow myself to send as long messages as I want?

In general try avoiding 2 things: sending large chunks of data and doing the same job twice.

Upvotes: 0

bishop
bishop

Reputation: 39354

Do what works for your particular problem. Good design finds compromise between the trade-offs. If you are on a tight deadline and you need something that works and it is easier to return HTML from PHP do it.

That said, you are generating the HTML programmatically on the server. You have same job if you pass JSON, the difference being the client generates the HTML. That is far more flexible for you, as you can generate different HTML in different contexts. Or not even HTML at all.

Designing to return a flexible data structure loosely couples your application components by affording reuse: the data structure remains agnostic to the caller's environment and the target presentation. This flexibility will serve your application well as it grows, and - in my opinion - the effort to design such an API early on is worth it.

Upvotes: 7

Related Questions