Architectural approach for converting web app to Umbraco
Hello,
I'd like to ask how the pros would handle converting a pretty simple
CRUD web app to umbraco. It's a flat file of about 3000 records that
have about two dozen fields each. It's currently a simple .NET app using
DataGrids as the main viewing control, which I'm not crazy about (I'm
more comfortable in XSLT than .NET) but it's fine for the client.
Would you:
a. Just leave the data in its own tables and implement the datagrid
as a usercontrol on the public website, with access controlled by
membergroups, or
b. Import all records as umbraco nodes, managed through the backend
(probably using AutoFolders or the like to ensure that any one node list
isn't too huge), and build the presentation with XSLT. I'm a little
worried about sluggish performance in the backend with this many nodes.
Option B would require the creation of a doctype to mirror the existing table and then using CMSImport to pull in the records and create nodes based on the new doctype. This would also mean future records would need to be handled within the umbraco node structure.
The final decision is yours. If there is not a lot of records, I would recommend option B. For many records, stick with option A for ease of management.
The system shouldn't be effected by speed in either options.. it all depends on your server (web/database) muscle.
I'd say it depends on the data in your app, and how many records you are expecting. Umbraco nodes are great for web content because they have versioning and other "content" related features. If you don't need these features, I'd probably say stick with option A as you aren't really going to gain anything by converting it to nodes. You can still keep it in a seperate db table and integrate it into umbraco though by using something like DEWD (http://our.umbraco.org/projects/developer-tools/dewd), and you can always get SQL Server to return results as XML and then handle them via XSLT (you'll just need o create a custom XSLT Extension) if you want to replace the main viewing control.
I think these may offer you a good middle ground where you save yourself the pain of converting it over, but integrates it nicely, and allows you to extend it in to a form you are more comfortable dealing with.
Best of luck, and any questions on my suggestions, don't hesitate to ask.
Architectural approach for converting web app to Umbraco
Hello,
I'd like to ask how the pros would handle converting a pretty simple CRUD web app to umbraco. It's a flat file of about 3000 records that have about two dozen fields each. It's currently a simple .NET app using DataGrids as the main viewing control, which I'm not crazy about (I'm more comfortable in XSLT than .NET) but it's fine for the client.
Would you:
a. Just leave the data in its own tables and implement the datagrid as a usercontrol on the public website, with access controlled by membergroups, or
b. Import all records as umbraco nodes, managed through the backend (probably using AutoFolders or the like to ensure that any one node list isn't too huge), and build the presentation with XSLT. I'm a little worried about sluggish performance in the backend with this many nodes.
Andrew
Simplest approach would be option A.
Option B would require the creation of a doctype to mirror the existing table and then using CMSImport to pull in the records and create nodes based on the new doctype. This would also mean future records would need to be handled within the umbraco node structure.
The final decision is yours. If there is not a lot of records, I would recommend option B. For many records, stick with option A for ease of management.
The system shouldn't be effected by speed in either options.. it all depends on your server (web/database) muscle.
Hey Andrew,
I'd say it depends on the data in your app, and how many records you are expecting. Umbraco nodes are great for web content because they have versioning and other "content" related features. If you don't need these features, I'd probably say stick with option A as you aren't really going to gain anything by converting it to nodes. You can still keep it in a seperate db table and integrate it into umbraco though by using something like DEWD (http://our.umbraco.org/projects/developer-tools/dewd), and you can always get SQL Server to return results as XML and then handle them via XSLT (you'll just need o create a custom XSLT Extension) if you want to replace the main viewing control.
I think these may offer you a good middle ground where you save yourself the pain of converting it over, but integrates it nicely, and allows you to extend it in to a form you are more comfortable dealing with.
Best of luck, and any questions on my suggestions, don't hesitate to ask.
Matt
Thanks both, I think I'm staying with option A with the possible addition of the DEWD.
is working on a reply...