I want to ask you to share your thoughts on an architecture for a new website we're implementing. I'm gonna share the project details and my plan and I hope that you will provide some feedback on how you would do it.
project:
Implement a website (application) with heavy integration with another system. Develop API for other system Website implementation contains loads of ajax functionality for displaying list, filtering lists, paging, sorting.
my plan:
Use Umbraco as web platform (doooh) Develop API as xslt extension and webservices that can be used with jquery (json, scriptable and all that)
Example:
Page that displays a list of results from other system via our API when loading page. The list should be sortable, filtered, sortable, pageable.
Also - the page is not public and therefore no considerations regarding google is needed. Since the site is javascript heavy, the user must have enabled javascript thus no fallback support is needed.
My implementation would be:
xslt extension that fetches data and returns an xpath iterator that is called on page load to display first set of data.
When filtering, paging or sorting we will ask for the same data via jquery/json.
Question:
What irritates me is that I have to develop to api methods for the same data: one that returns json and one that returns xml (xpath iterator).
How would u do it? How to avoid developing 2 methods for the same sheite?
Setup:
Umbraco website (4.0.x), sql server 2008, .net framework 3.5
Not sure I follow how the other system is accessed? Is the umbraco site going to be a web front to the system, or will umbraco call webservices that reside on the other system?
When you say API, who will be using it. Is it an API that needs to be used in systems that are not umbraco? Is Umbraco going to be exposing the API to other applications? Or is the umbraco site going to be using the API as well?
I would like to ask your question one level higher up in the workflow: why do you need to populate the data on the page via 2 different mechanisms? Apart from having the issue that you have to access the API from two different layers you also need to functionality to throw the data on the screen twice, which might prove to be even more of an effort than to double the API calls. In order to reduce this necessity (and the other one in question as well): how about populating the data just via JS/Ajax calls? E.g. in the $(document).ready() method make the initial call to the API to fetch the first batch of data in an asynchronous fashion, displaying a 'busy' graphic to the user (the data will load in fast enough probably so the user might not even see it); then make successive calls when the user sorts/pages/filters/etc to update the data.
If you can't do everything via JS as highlighted above I would probably not implement the API calls as XsltExtensions but as proper .Net controls. I read once in another post that although it is certainly possible to do that you actually create more processing by first getting the data into the Xslt and then transforming it. The additional benefit of using a .Net control to handle this is that you would definitely not have to implement the service methods twice, you can just use the one you have created for the ajax call and process it in your .Net control.
By the way you don't necessarily have to use json as data format for your $.ajax calls. Only yesterday have I implemented one that reads out xml. Haven't tried directly reading out an XPathNodeIterator return type of the web service though, it might work as well with a bit of tweaking when processing the response stream.
We're developing the api for the other system and Umbraco will be responsible for rendering the data exposed by this API. The unique thing is that we are developing the API and as such we can decide on how this should be designed.
Sounds like the main role of the API is to be able to perform CRUD operations on the other system.
I would probably separate the Umbraco specific stuff completely from the task of creating the API. I would create a class library project that handles all communication with the other system, and which exposes public methods/classes that represent the repositories that you would need to get data from on the other system.
The, from the umbraco web project, I would add a reference to the class library, and then build either xslt extensions or /base methods on top of that. With regards to JSON vs. XML, I think there are some libraries out there that will help you easily serialize your classes into either of them, giving you some freedom to focus on getting the data, and exposing it any way you like.
If you want to keep to one type of serialization, then you could just make the initial page view load data via ajax as well on the OnLoad event of the DOM. Then there is no need for xslt to render data for you.
Thanks for replying. I'm not sure if I need to populate the data on the page via 2 different mechanisms. I would like to avoid it. I'm tempted to do as you suggest - only populating the data just via JS/Ajax calls. From the developer point of view it would also mean half the api methods. I like that a lot :-)
As the system doesnt have to worry about Google indexing I'm only worrying about if pages loads as quicky as expected. Nothing beats cached xslt macros in development speed and performancewise.
This brings me to the usercontrol vs xslt macro - I would be surprised if the xslt macro should result in more processing. You mean performance hit?
Say we stick to developing the API as webservices. The webservices would be published from another server an would be a seperate vs project. If these where marked scriptable they could be called directly from jquery.
I'd do it with OData or WCF Data Services. I'm developing an app which also needs a CRUD-functionality API making for it, which will support both JSON and XML (SOAP) calls. The API's done with WCF Data Services (OData) using a Subsonic 3 data access layer, and then the MVC2 app just calls the necessary methods in the API.
DM me on Twitter and I can provide you with some of the templates I've got.
oData is certainly something I'd look into for future projects. I've no experience with oData nor WCF Data Services. I'll do a bit of reading on this tonight. Anyone else got any they want to share? oData? or WCF?
I totally agree that cached xslt macros are probably unbeatable in terms of performance. However you have a couple of caching options when using ajax calls as well, both on the client side as well as the web service side to speed the process up a bit as well. When implementing nice asynchronous calls it might not even matter at all as the client will be busy rendering the page during which the data will probably arrive.
With regards to the .Net control vs Xslt script discussion: I guess the thing is that there is just one more step to do when using XsltExtensions. The XsltExtension will retrieve the data from a web service, will process it and build it up so that an XPathNodeIterator can be returned. This will then be processed by the Xslt script to output the result. As opposed that the .Net control will connect to the web service as well and process the data, yet it would not need to build up the xml to return as it can directly display the results and they wouldn't have to be processed after the .Net code is finished. Pretty sure that the difference is minor and probably not noticeable on smaller sites, however on bigger sites with loads of users it might well have an impact.
I am using the concept of master template which contains the common header and footer that is displayed on all web pages. My header contains menu items which has level 1 submenu with related links. This page works fine when I view only master page that is on mouse over event all menu items are popped up. But when I use master as well as child template, menu items are not popped up on mouse over event.
Integration question - how would u do this?
Hi all,
I want to ask you to share your thoughts on an architecture for a new website we're implementing. I'm gonna share the project details and my plan and I hope that you will provide some feedback on how you would do it.
project:
Implement a website (application) with heavy integration with another system.
Develop API for other system
Website implementation contains loads of ajax functionality for displaying list, filtering lists, paging, sorting.
my plan:
Use Umbraco as web platform (doooh)
Develop API as xslt extension and webservices that can be used with jquery (json, scriptable and all that)
Example:
Page that displays a list of results from other system via our API when loading page. The list should be sortable, filtered, sortable, pageable.
Also - the page is not public and therefore no considerations regarding google is needed. Since the site is javascript heavy, the user must have enabled javascript thus no fallback support is needed.
My implementation would be:
xslt extension that fetches data and returns an xpath iterator that is called on page load to display first set of data.
When filtering, paging or sorting we will ask for the same data via jquery/json.
Question:
What irritates me is that I have to develop to api methods for the same data: one that returns json and one that returns xml (xpath iterator).
How would u do it?
How to avoid developing 2 methods for the same sheite?
Setup:
Umbraco website (4.0.x), sql server 2008, .net framework 3.5
Your thoughts will me much appreciated :-)
All the best
Jesper Ordrup
Not sure I follow how the other system is accessed? Is the umbraco site going to be a web front to the system, or will umbraco call webservices that reside on the other system?
When you say API, who will be using it. Is it an API that needs to be used in systems that are not umbraco? Is Umbraco going to be exposing the API to other applications? Or is the umbraco site going to be using the API as well?
Hi Jesper,
I would like to ask your question one level higher up in the workflow: why do you need to populate the data on the page via 2 different mechanisms? Apart from having the issue that you have to access the API from two different layers you also need to functionality to throw the data on the screen twice, which might prove to be even more of an effort than to double the API calls. In order to reduce this necessity (and the other one in question as well): how about populating the data just via JS/Ajax calls? E.g. in the $(document).ready() method make the initial call to the API to fetch the first batch of data in an asynchronous fashion, displaying a 'busy' graphic to the user (the data will load in fast enough probably so the user might not even see it); then make successive calls when the user sorts/pages/filters/etc to update the data.
If you can't do everything via JS as highlighted above I would probably not implement the API calls as XsltExtensions but as proper .Net controls. I read once in another post that although it is certainly possible to do that you actually create more processing by first getting the data into the Xslt and then transforming it. The additional benefit of using a .Net control to handle this is that you would definitely not have to implement the service methods twice, you can just use the one you have created for the ajax call and process it in your .Net control.
By the way you don't necessarily have to use json as data format for your $.ajax calls. Only yesterday have I implemented one that reads out xml. Haven't tried directly reading out an XPathNodeIterator return type of the web service though, it might work as well with a bit of tweaking when processing the response stream.
Hope that helps,
Sascha
Hi Morten,
Thanks for clearing up the mistakes.
We're developing the api for the other system and Umbraco will be responsible for rendering the data exposed by this API. The unique thing is that we are developing the API and as such we can decide on how this should be designed.
Best
Jesper
Sounds like the main role of the API is to be able to perform CRUD operations on the other system.
I would probably separate the Umbraco specific stuff completely from the task of creating the API. I would create a class library project that handles all communication with the other system, and which exposes public methods/classes that represent the repositories that you would need to get data from on the other system.
The, from the umbraco web project, I would add a reference to the class library, and then build either xslt extensions or /base methods on top of that. With regards to JSON vs. XML, I think there are some libraries out there that will help you easily serialize your classes into either of them, giving you some freedom to focus on getting the data, and exposing it any way you like.
If you want to keep to one type of serialization, then you could just make the initial page view load data via ajax as well on the OnLoad event of the DOM. Then there is no need for xslt to render data for you.
Hi Sascha,
Thanks for replying. I'm not sure if I need to populate the data on the page via 2 different mechanisms. I would like to avoid it. I'm tempted to do as you suggest - only populating the data just via JS/Ajax calls. From the developer point of view it would also mean half the api methods. I like that a lot :-)
As the system doesnt have to worry about Google indexing I'm only worrying about if pages loads as quicky as expected. Nothing beats cached xslt macros in development speed and performancewise.
This brings me to the usercontrol vs xslt macro - I would be surprised if the xslt macro should result in more processing. You mean performance hit?
Thanks
Jesper
Hi Morten,
Say we stick to developing the API as webservices. The webservices would be published from another server an would be a seperate vs project. If these where marked scriptable they could be called directly from jquery.
Thanks
Jesper
Hi Jesper,
I'd do it with OData or WCF Data Services. I'm developing an app which also needs a CRUD-functionality API making for it, which will support both JSON and XML (SOAP) calls.
The API's done with WCF Data Services (OData) using a Subsonic 3 data access layer, and then the MVC2 app just calls the necessary methods in the API.
DM me on Twitter and I can provide you with some of the templates I've got.
Best,
Benjamin
Hi Benjamin,
oData is certainly something I'd look into for future projects. I've no experience with oData nor WCF Data Services. I'll do a bit of reading on this tonight. Anyone else got any they want to share? oData? or WCF?
Thanks,
Jesper
Hi Morten,
I totally agree that cached xslt macros are probably unbeatable in terms of performance. However you have a couple of caching options when using ajax calls as well, both on the client side as well as the web service side to speed the process up a bit as well. When implementing nice asynchronous calls it might not even matter at all as the client will be busy rendering the page during which the data will probably arrive.
With regards to the .Net control vs Xslt script discussion: I guess the thing is that there is just one more step to do when using XsltExtensions. The XsltExtension will retrieve the data from a web service, will process it and build it up so that an XPathNodeIterator can be returned. This will then be processed by the Xslt script to output the result. As opposed that the .Net control will connect to the web service as well and process the data, yet it would not need to build up the xml to return as it can directly display the results and they wouldn't have to be processed after the .Net code is finished. Pretty sure that the difference is minor and probably not noticeable on smaller sites, however on bigger sites with loads of users it might well have an impact.
All the best,
Sascha
Hi all
I am using the concept of master template which contains the common header and footer that is displayed on all web pages. My header contains menu items which has level 1 submenu with related links. This page works fine when I view only master page that is on mouse over event all menu items are popped up. But when I use master as well as child template, menu items are not popped up on mouse over event.
Thanks,
Jesper,
With regards to OData http://our.umbraco.org/projects/backoffice-extensions/odata-for-umbraco
Regards
Isamil
is working on a reply...