CodingXSLT/XML vs. JSON

 

Press Ctrl+Enter to quickly submit your post
Quick Reply  
 
 
  
 From:  Ally  
 To:  ALL
37750.1 

I am experimenting with some major changes on our site at work... I'd like to combine a gradual move to ASP.NET MVC with a switch to XML/XSLT instead of straight HTML. The reasons for this are numerous, and a number are organisational rather than technical, but I digress.

 

The point is that I want to be able to create XML views. Which I can- it works fine. But the intellisense doesn't. I can either get HTML intellisense, which includes the <% %> functionality but throws up millions of validation errors (because i'm not using <html> etc), or I can get the XML intellisense, which works great but doesn't understand the <% %> stuff.

 

Anyone know of a way that I can create some custom intellisense that'll use XML formatting but also understand <% %> brackets?

0/0
 Reply   Quote More 

 From:  THERE IS NO GOD BUT (RENDLE)  
 To:  Ally     
37750.2 In reply to 37750.1 
What is the reason for XML/XSLT? Wouldn't it be easier to work with the MVC framework and render HTML, XML or JSON dynamically?

Happy now?

0/0
 Reply   Quote More 

 From:  Ally  
 To:  THERE IS NO GOD BUT (RENDLE)     
37750.3 In reply to 37750.2 
Yes- once I take a step back I realise that this XML generation should probably be done in the controller- it just makes the code more fiddly with adding nodes, etc. rather than just typing a structure out.

The main reason to use XSLT is that we can do the transform on the client side, which is a huge bandwidth saver (cache the XSLT file, only change XML with each page). It's just a pain in implement- I'm trying to work out if it's too much of a pain.
0/0
 Reply   Quote More 

 From:  THERE IS NO GOD BUT (RENDLE)  
 To:  Ally     
37750.4 In reply to 37750.3 
In that case, have you considered an AJAXy site so you can just send JSON?

Happy now?

0/0
 Reply   Quote More 

 From:  af (CAER)  
 To:  Ally     
37750.5 In reply to 37750.3 
I agree with Rendle. Not that I'm by any means an expert on these matters, it just seems to me a nice way to do things - send the initial page+layout as HTML, then any data from then on as JSON (which has fairly minimal overhead) which you can insert into dynamically generated markup on the client side.
Caer
0/0
 Reply   Quote More 

 From:  Ally  
 To:  THERE IS NO GOD BUT (RENDLE)     
37750.6 In reply to 37750.4 

The big downer for that is SEO. Though of course, XSL'd pages aren't SEO indexable either, at least .NET has all the necessary shenanigans that allow me to do the transformation server side when necessary. I could write something that would allow it to consume the AJAX content, but figure it would be a larger body of work.

 

In any case, I've figured that the more efficient way to do this will be to make an XML document in the controller, then make the view itself the XSL file (with a little fiddling).

 

Hopefully I will be able to implement this sometime in the next two years...

0/0
 Reply   Quote More 

 From:  Ally  
 To:  af (CAER)     
37750.7 In reply to 37750.5 
As above, but congratulations on an insanely fast forum.
0/0
 Reply   Quote More 

 From:  af (CAER)  
 To:  Ally     
37750.8 In reply to 37750.7 

The way I plan to do my forum, the thread links will, if Javascript is not enabled, simply link to a new page that the server will render, in effect working like a regular non-AJAX page.

 

Fortunately both the AJAXy page and the static version both get sourced from the same post template, but even so it's still duplicating a lot of stuff so it's hardly optimal.

 

And thanks! Although I suspect a lot of that speed is down to the fact there's only about 6 threads, 6 users and 100 posts :D Whether it's still fast with a DB the size of Teh's, and the traffic to match, remains to be seen.

0/0
 Reply   Quote More 

 From:  Dan (HERMAND)  
 To:  af (CAER)     
37750.9 In reply to 37750.8 

Thought about generating a load of database content to check it out?

 

As for server load, not that Teh is slow, but I don't think we get a great deal of traffic - I bet you could simulate it with relative ease. Matt, what's our bandwidth use / hits like?

0/0
 Reply   Quote More 

 From:  af (CAER)  
 To:  Dan (HERMAND)     
37750.10 In reply to 37750.9 
Yeah I already made a thing on my local copy to generate a 100-post thread so I can work on the pagination (well, it'll be more like how Twitter used to work, with a 'More' button that just loads and appends more posts).
0/0
 Reply   Quote More 

 From:  Dan (HERMAND)  
 To:  af (CAER)     
37750.11 In reply to 37750.10 
I can't remember what it was I used, but as you scrolled down to the bottom of the page it started loading the subsequent posts. That was nice.
0/0
 Reply   Quote More 

 From:  af (CAER)  
 To:  Dan (HERMAND)     
37750.12 In reply to 37750.11 
Yeah that's the way Twitter (and Google Reader) works now.
0/0
 Reply   Quote More 

 From:  THERE IS NO GOD BUT (RENDLE)  
 To:  Ally     
37750.13 In reply to 37750.6 

OK, if you're doing MVC, then you do SEO (and improve accessibility generally, btw) by using jQuery to do progressive enhancement. So, you have your page layouts and you can render those to traditional HTML, but you can also get your controller methods to return JSON if the client asks for that in the request header.

 

On the page load of the initial page, you run a jQuery function to find all the links on the pages and replace them with AJAX requests for the JSON data which you can then render client-side (take a look at the new Templates plug-in for that while you're at it).

 

Since SE spiders don't implement Javascript, they'll get the old-style traditional HTML, as will Readers for the visually impaired.

 

Easy.

Happy now?

0/0
 Reply   Quote More 

 From:  af (CAER)  
 To:  THERE IS NO GOD BUT (RENDLE)     
37750.14 In reply to 37750.13 
jQuery really is lovely, isn't it?
0/0
 Reply   Quote More 

 From:  Ally  
 To:  af (CAER)     
37750.15 In reply to 37750.14 
MOOTOOLS RULES
0/0
 Reply   Quote More 

 From:  Ally  
 To:  THERE IS NO GOD BUT (RENDLE)     
37750.16 In reply to 37750.13 

I had considered that. But loading entire pages through JSON results in the URL being wrong unless you use one of those systems that appends a # into the URL, no?

 

Still, I'll bear it in mind, cheers. I'm still keen on XSL simply because it means zero change of one of the design people having access to backend code through <% %> tags. But that might just be my paranoia kicking in.

0/0
 Reply   Quote More 

 From:  af (CAER)  
 To:  Ally     
37750.17 In reply to 37750.16 

Could you not just have the Javascript append "&format=json" to the request URLs, then let your request handler deal with things depending on the presence of that parameter?

 

edit: that's how I plan on doing it, so if it's not good way, let me know so I can avoid any problems :D

0/0
 Reply   Quote More 

 From:  Ally  
 To:  af (CAER)     
37750.18 In reply to 37750.17 

Oh yes, you could. But the original page URL wouldn't change because you'd be loading content via AJAX. To get around this, people end up using URLs like:

 

http://www.mysite.com/#category/page

 

and change the part after the # dynamically. It's not a big issue (Facebook gets away with it quite nicely) but it offends my OCD tendencies.

0/0
 Reply   Quote More 

 From:  af (CAER)  
 To:  Ally     
37750.19 In reply to 37750.18 
Ohh yeah I see what you mean - I'd worried about that actually, and how to get around the problem of dynamic page changes not affecting the browser's history state.
0/0
 Reply   Quote More 

 From:  Ally  
 To:  af (CAER)     
37750.20 In reply to 37750.19 
There are some JS plugins (I've used ReallySimpleHistory before) that handle history state and such.

It's still a pain, though.
0/0
 Reply   Quote More 

Reply to All  
 

1–20  21–24

Rate my interest:

Adjust text size : Smaller 10 Larger

Beehive Forum 1.5.2 |  FAQ |  Docs |  Support |  Donate! ©2002 - 2024 Project Beehive Forum

Forum Stats