Firstly: I'm a very seasoned PHP programmer in LAMP set-ups, both MVC based as well as non-MVC based.I am completely new to Umbraco and ASP.NET and have to realise a semi-large application that in PHP would typically be modelled using custom entities (for modelling educations, courses, clusters, etc. as well as the relationships between them). I hope I'm asking the right question in the right place, and if not, I hope someone can point me to the right place. :P
The context: For this particular application, the client demands an ASP.NET solution. Umbraco was chosen, and I think I've done a fair deal of reading up on a lot of matters, as well as being subscribed to UmbracoTV and having watched several tutorials. All comes across as a very nice platform, and I'm looking forward to doing the hands-on work, but... in order to do so in a way that I'm not shooting myself in the foot, I want to make one fundamental choice the right way, directly from the start. Towards that end, I've tried to see (Googled) what the general concensus is, and I'm still not 100% sure, so I'll just stick my neck out and ask it here. The site in question is a portal featuring general pages, as well as the
above mentioned "entity-based" data. Specific requirements have been
made as to SEO friendly URLs (and routes), relationships between the
various entities (and attributes that further detail them), execution
speed, navigation, and in short the whole shebang. As deadlines are
tight (gee, arent't they always in software development?) I'm looking
for a good start, with handy choices, and optimal usage of existing modules, tools and other plug ins.
The actual question/matter: Having read up on Umbraco and having watched several of the videos, I feel the proper "Umbraco way" to implement this application is not by custom modelling the entities in the DB and going from there, but rather modelling them as much as possible (hopefully that means "all the way"!) in the back-office as proper document-types. Towards this end, and keeping the above context in mind, would it be best to opt for the Webforms or MVC approach?
I myself am very tempted to go with the latter, but, when doing so, are all modules and existing tools etc. 100% compatible, or would that mean that only some of them will work, whereas I could perhaps use a lot more of those when going the Webforms way? As far as I can anticipate at this moment, there _may_ not be a very strict need for the MVC pattern (though it will probably help for the SEO optimised URL routing, and possibly for implementing the precise site layout), but perhaps you guys spot some points in the given context that trigger you to say: "definitely go with webforms", or "better to go with MVC".
As far as ASP.NET is concerned at this point in time it's still all new to me, so there will be a learning curve anyway (I do have several good books from the Apress line on the matter), and both concepts of making applications (of various scales) in MVC and non-MVC patterns are well known to me in PHP, but I haven't been able to find enough information online to make a definitive choice myself as to how to set out in Umbraco regarding this key decision.
As a side-note: I did see that switching from webforms to MVC doesn't appear to be all that complex, but I'd MUCH rather set out right from the start. As it is, I have Umbraco 6.1.6 installed (Visual Studio 2010 SP1, with SQLServer 2008 Express R2) on XP using Webmatrix 2, and it is presently a clean install, set to webforms rendering and provided with the "Business" starter kit.
What say you all? Should I start out using webforms, see if that works for my needs and only switch to MVC if there's a definite need to do so, or is it better to go for MVC from the start and take it from there? And... as asked above: what (if any) are the exact implications of this choice for compatibility with existing modules etc.?
Thanks in advance, and hope someone can give me some good answers/pointers,
I have worked on Umbraco since version 4.0.4 and our sites have moved from Webforms and XSLT to MVC and XSLT. It was quickly decided we would re-write our XSLT components as MVC Partials/MacroPartials piece by piece over the lifetime of our CMS, post upgrade, rather than trying to do it all at once. This meant we could concentrate initially on converting our webforms templates (masterpages) to MVC views and re-write our user controls to Partial views with Surface Controllers. The experience to date has been pretty smooth and the Umbraco team have done a great job in ensuring all of the technologies co-exist very well.
We've also seriously rolled back on the number of package extensions we use to ensure our upgrade path remains without road blocks! We've reached Umbraco v4.11.10 and intend to skip v6 and move straight to v7 as soon as it's available. On the subject of packages, the only package I'm aware of working with v7 is Umbraco Contour, third party developers are usually quick to update though. TIP: Avoid Courier (staging/live platforms) at all cost until the team sort the product out....it's a mess!
If you decide to use webforms (asp.net masterpages for your main templates), I would recommend you learn XSLT/XPath too. Whilst it's entirely possible to write all of your code in your templates (masterpages) you'll limit flexibility and re-usability. You can use the entire Umbraco API in XSLT and it's very, very fast at page rendering. The down sides are a steep learning curve and no further support for the language from Microsoft since v1 of XSLT, despite it moving to v2.
I cant give you any comparisons between Webforms and MVC because the technologies are completely different, you'll need to read up on the pros and cons of each one. Webforms were criticised a lot in the past for its lack of flexibility when using controls, but this has largely gone away since AJAX and later versions of the .net framework. Alternatively if you use XSLT you can write out pure HTML and these problems are avoided anyway.
From a personal stand point, I find Webforms is a framwork where you can throw something together very, quickly. Particularly if you're not too concerned about what it looks like visually.
With MVC, you'll find it much easier to integrate your code with some of the more sophisticated client side frameworks and you can build re-useable components in a single language ie Razor. Umbraco covers all the usual MVC stuff, Views, Partials as well as it's own mix of MacroScripts and MacroPartials. If you feel so inclined you can even completely Hijack Umbraco and build your own routes, models and views. Although thats a lot of work! It depends on how much heavy lifting you want to do.
There's probably little doubt MVC is the future and eventually Webforms will lose support from MS, something to bear in mind.
Thanks a lot for taking the time to write a nice and lengthy reply. I notice it isn't a definitive exclamation as to either MVC or Webforms, but there is some reading between the lines that does give some hints towards the former.
Firstly, your comment: "From a personal stand point, I find Webforms is a framwork where you can throw something together very, quickly. Particularly if you're not too concerned about what it looks like visually." The former part ('quick') is highly attractive for me, as the timelines are tight, a lot needs to be built and there's still the ASP.NET learning curve to overcome, but.. the latter part in that phrase is one of the things that worries me most about what I read regarding the webforms approach, as the design features a full-blown graphical layout, it will basically need to become pixel-perfect (or very close to that) matched to the graphical design. If you're saying that that will be an issue with the webforms approach, then I will not even consider going that way and definitely stick with the MVC approach.
The XSLT part that you mentioned is a thing I forgot to ask about (as I thought the same amount of usage of it would be required for either platform): I have got no working experience with that, so if the webforms approach 'requires' extensive XSLT knowledge/usage, and the MVC approach little or none, then that would be a BIG plus for opting for the MVC approach, as that basically eliminates having an additional learning curve for XSLT. I know that you don't precisely write it that way, and that you do mention using XSLT in the MVC approach too, it would still be interesting to know if overal spoken MVC solutions tend to use less XSLT than the typical webform solutions do.
Another highlight you mention is the re-usability of code: the site will feature a homepage and at least 8 different kinds of follow-up pages. The latter ones all have some parts in common, and other parts may be closely related between the various pages. If the MVC parts lend themselves better to being re-used in various pages, that would be another plus for the MVC approach.
That still leaves the question open with me if the various third party modules out there tend to be mainly webforms based solutions, or MVC based ones, but at least from what you write it seems that when in a position to make a clean start, it might be best to directly opt for the MVC approach.
I hope you (or someone else) can comment some more on it, particularly regarding the points written in this follow-up I wrote...
Thanks a lot again; tonight I'm going to make a start with setting up the various document types, and very soon after I'll have to make a choice between MVC and webforms. I hope I can get some more targeted input (like the follow-up you posted) that will be helpful in making the proper decision, in light of my context. ;)
Right some additional things worth considering.....
Umbraco (prior to its MVC implementation) was considered "designer friendly" despite being based on ASP.net (WebForms). This is entirely down to it's use of XSLT. XSLT allows a developer to effectively bypass WebForms altogether (server side controls) and frees the designer/developer to write 100% raw HTML! This is combined with complete access to Umbraco's API within the XSLT engine. The other advantage to using XSLT is it provides the ability to componentise sections of your site, lets say right hand modules, that would be otherwise difficult to do with just templates (nested master pages). As explained before though, you have to learn another language! Bear in mind you can still build true ASP.net components (user controls) and load them into the back office as macros in exactly the same way as you do with XSLT. But in general we only ever needed this when we required access to elements that would otherwise live outside of the CMS, or say you need a bunch of forms to do clever things with content. In all other cases XSLT is a better solution.
So in short if you go the WebForms route, you really should (for your own sanity) learn XSLT too!
In contrast MVC, whilst still working perfectly well with all the tech above including XSLT can be done entirely in Razor. It means you can discard XSLT altogether and build everything (including your components) in razor. So thats basically, your nested Views (templates), MacroScripts, Partials, Macro Partials...the whole shabam! The other advantage of working in MVC is you retain complete control of your HTML output because controls dont exist. You also get rid of the whole page lifecycle and event model....although most parts of the event model were awesome! But hey it's all client side these days, in a short space of time the emphasis is now on the browser rather than the server!
Either way you're in for a steep learning curve, I've found Razor incredibly frustrating at times but at least its a single syntax! XSLT at first glance looks easy, due to it resembling HTML (because its XML). But it's recursive nature can very quickly get you in a pickle and make things actually more difficult to follow than C#. It's also much harder to debug if you have access to VisualStudio.
Despite your worries over tight deadlines, my advice would be if you're starting out is always go with the newest, emerging technology rather than the older established technology. The biggest disadvantage you will find is a lack of support in the community and online....but in the long run it will be worth it!
Thanks a lot for your additional insight into this matter; I've heard enough to make up my mind: it will definitely become the MVC way then. I fully hear you in all of your advice, and at this time I'd rather have the learning curve of C# + Visual Studio, than the XSLT one (that is not to say that XSLT is not an interesting and useful technology, because I know it is, but at this point in time I'd rather not have that leaning curve on top of it too).
Well then, with that decision made for MVC (a thing which I yesterday evening was already pretty certain would happen), yesterday I did some reading up on how to best install it. At this moment in time I have an out-of-the-box installation (webforms) that was done on XP with Webmatrix 2, and was provided with the Business starter kit. The recommended method I have seen mentioned for installing/configuring it for MVC seems to be to create a clean new ASP.NET MVC 4 project from within Visual Studio, then to use Nuget to install Umbraco and then manually copy the proper files to the newly created project (all like described for example here: http://stackoverflow.com/questions/17521154/how-to-setup-umbraco-6-1-2-in-visual-studio-2012-with-mvc-enabled-to-use-in-tfs).
Now, a thing I was wondering about: in light of it already having been installed with Webmatrix using the Webforms rendering engine, but not yet having been provided with actual content for the application I need to make, would it in your opinion be best to delete all of that, and install it clean again from the start, using the VS + NuGet approach as mentioned above, or is it easier/better to just switch over the rendering engine in the installation I've already made?
On another note (please pardon the noob questions, but as I'm new to VS too, I'd rather ask some trivial things rather than making an incorrect start): when it is fully set-up, should all of the development work (best) be done from VS, or can it also be done partially through the Umbraco back-office (and still all be visible in VS too)? What I'd expect is that it's perfectly fine to define document types, add content, add media etc. through the Umbraco back-office, and that that is then readily available from within VS, without further ado. But... what if one edits/creates templates/views in the Umbraco back-office (e.g. for using the toolage to automatically insert Umbraco properties), does all of this still automatically get picked up uin VS? Same for the vice versa route: does everything that gets created in VS get picked up automatically in the Umbraco back-office? In short: do these two development environments work with 100% synergy, or does one explicitly have to make edits and new items "known" in the other environment?
Either way it plays out: one very important requirement is that the content editors who will be filling the site do not have to mess around with VS, and can make 100% usage of the nice mechanism that the Umbraco back-office provides in terms of just providing the content in nicely tabbed back-office pages, all set-up with proper document types (using the right properties), and also easily add media. It would highly surprise me if such were not the case, but I'd rather ask the seemingly obvious at this point in time than hitting some unpleasant surprise at a later stage...
Once I've got a pretty good idea as to how to most efficiently and quickly start (IOW: to 'go with the flow') I can make a good start and get on to the hands-on stuff and start creating the site's structure in terms of document types, etc.
First things first, as you're using VS, avoid using the backoffice editors wherever and whenever possible, you'll just get yourself very quickly into a pickle otherwise! I dont need to go into the pros and cons of VS, other than to say, it's one of MS's biggest assets and the latest version is incredibly sophisticated and I can't imagine why you would want to use anything else!
Some of the questions you're asking depend entirely on whether you intend to develop with others rather than being the sole contributor to your codebase. If you're the sole contributor, you can load up EVERYTHING into VS so thats all your code along with the Umbraco build itself.
If you intend to have code contributors things get complicated! You might then need to consider some form of source control either via one of the free paths or by Microsofts own Team Foundation Server. We use TFS for our projects as many contribute to the project(s).
Our method was to create a project which only contains the user contributed code, which you can push to any Umbraco build either locally or on a server using build scripts and publishing. Thats one way of doing it but there are many other ways.
We debug our projects by attaching the debugger manually to the IIS process on our local PC's. Again there are many ways you can do this, most recently via IISExpress.
As for getting started do a few test runs with starter kits to get a feel for how to put your types together, then run a build from scratch with nuget and go from there. That way you won't be left with a whole ton of cruft that your never use or isnt quite to your liking. The great thing about nuget is you can get builds up and running very quickly.
MVC vs. Webforms: impact on modules and examples?
Hi,
Firstly: I'm a very seasoned PHP programmer in LAMP set-ups, both MVC based as well as non-MVC based.I am completely new to Umbraco and ASP.NET and have to realise a semi-large application that in PHP would typically be modelled using custom entities (for modelling educations, courses, clusters, etc. as well as the relationships between them). I hope I'm asking the right question in the right place, and if not, I hope someone can point me to the right place. :P
The context: For this particular application, the client demands an ASP.NET solution. Umbraco was chosen, and I think I've done a fair deal of reading up on a lot of matters, as well as being subscribed to UmbracoTV and having watched several tutorials. All comes across as a very nice platform, and I'm looking forward to doing the hands-on work, but... in order to do so in a way that I'm not shooting myself in the foot, I want to make one fundamental choice the right way, directly from the start. Towards that end, I've tried to see (Googled) what the general concensus is, and I'm still not 100% sure, so I'll just stick my neck out and ask it here. The site in question is a portal featuring general pages, as well as the above mentioned "entity-based" data. Specific requirements have been made as to SEO friendly URLs (and routes), relationships between the various entities (and attributes that further detail them), execution speed, navigation, and in short the whole shebang. As deadlines are tight (gee, arent't they always in software development?) I'm looking for a good start, with handy choices, and optimal usage of existing modules, tools and other plug ins.
The actual question/matter: Having read up on Umbraco and having watched several of the videos, I feel the proper "Umbraco way" to implement this application is not by custom modelling the entities in the DB and going from there, but rather modelling them as much as possible (hopefully that means "all the way"!) in the back-office as proper document-types. Towards this end, and keeping the above context in mind, would it be best to opt for the Webforms or MVC approach?
I myself am very tempted to go with the latter, but, when doing so, are all modules and existing tools etc. 100% compatible, or would that mean that only some of them will work, whereas I could perhaps use a lot more of those when going the Webforms way? As far as I can anticipate at this moment, there _may_ not be a very strict need for the MVC pattern (though it will probably help for the SEO optimised URL routing, and possibly for implementing the precise site layout), but perhaps you guys spot some points in the given context that trigger you to say: "definitely go with webforms", or "better to go with MVC".
As far as ASP.NET is concerned at this point in time it's still all new to me, so there will be a learning curve anyway (I do have several good books from the Apress line on the matter), and both concepts of making applications (of various scales) in MVC and non-MVC patterns are well known to me in PHP, but I haven't been able to find enough information online to make a definitive choice myself as to how to set out in Umbraco regarding this key decision.
As a side-note: I did see that switching from webforms to MVC doesn't appear to be all that complex, but I'd MUCH rather set out right from the start. As it is, I have Umbraco 6.1.6 installed (Visual Studio 2010 SP1, with SQLServer 2008 Express R2) on XP using Webmatrix 2, and it is presently a clean install, set to webforms rendering and provided with the "Business" starter kit.
What say you all? Should I start out using webforms, see if that works for my needs and only switch to MVC if there's a definite need to do so, or is it better to go for MVC from the start and take it from there? And... as asked above: what (if any) are the exact implications of this choice for compatibility with existing modules etc.?
Thanks in advance, and hope someone can give me some good answers/pointers,
Olafo
Hi Olafo
I have worked on Umbraco since version 4.0.4 and our sites have moved from Webforms and XSLT to MVC and XSLT. It was quickly decided we would re-write our XSLT components as MVC Partials/MacroPartials piece by piece over the lifetime of our CMS, post upgrade, rather than trying to do it all at once. This meant we could concentrate initially on converting our webforms templates (masterpages) to MVC views and re-write our user controls to Partial views with Surface Controllers. The experience to date has been pretty smooth and the Umbraco team have done a great job in ensuring all of the technologies co-exist very well.
We've also seriously rolled back on the number of package extensions we use to ensure our upgrade path remains without road blocks! We've reached Umbraco v4.11.10 and intend to skip v6 and move straight to v7 as soon as it's available. On the subject of packages, the only package I'm aware of working with v7 is Umbraco Contour, third party developers are usually quick to update though. TIP: Avoid Courier (staging/live platforms) at all cost until the team sort the product out....it's a mess!
If you decide to use webforms (asp.net masterpages for your main templates), I would recommend you learn XSLT/XPath too. Whilst it's entirely possible to write all of your code in your templates (masterpages) you'll limit flexibility and re-usability. You can use the entire Umbraco API in XSLT and it's very, very fast at page rendering. The down sides are a steep learning curve and no further support for the language from Microsoft since v1 of XSLT, despite it moving to v2.
I cant give you any comparisons between Webforms and MVC because the technologies are completely different, you'll need to read up on the pros and cons of each one. Webforms were criticised a lot in the past for its lack of flexibility when using controls, but this has largely gone away since AJAX and later versions of the .net framework. Alternatively if you use XSLT you can write out pure HTML and these problems are avoided anyway.
From a personal stand point, I find Webforms is a framwork where you can throw something together very, quickly. Particularly if you're not too concerned about what it looks like visually.
With MVC, you'll find it much easier to integrate your code with some of the more sophisticated client side frameworks and you can build re-useable components in a single language ie Razor. Umbraco covers all the usual MVC stuff, Views, Partials as well as it's own mix of MacroScripts and MacroPartials. If you feel so inclined you can even completely Hijack Umbraco and build your own routes, models and views. Although thats a lot of work! It depends on how much heavy lifting you want to do.
There's probably little doubt MVC is the future and eventually Webforms will lose support from MS, something to bear in mind.
Regards
Martin.
Hi Martin,
Thanks a lot for taking the time to write a nice and lengthy reply. I notice it isn't a definitive exclamation as to either MVC or Webforms, but there is some reading between the lines that does give some hints towards the former.
Firstly, your comment: "From a personal stand point, I find Webforms is a framwork where you can throw something together very, quickly. Particularly if you're not too concerned about what it looks like visually."
The former part ('quick') is highly attractive for me, as the timelines are tight, a lot needs to be built and there's still the ASP.NET learning curve to overcome, but.. the latter part in that phrase is one of the things that worries me most about what I read regarding the webforms approach, as the design features a full-blown graphical layout, it will basically need to become pixel-perfect (or very close to that) matched to the graphical design. If you're saying that that will be an issue with the webforms approach, then I will not even consider going that way and definitely stick with the MVC approach.
The XSLT part that you mentioned is a thing I forgot to ask about (as I thought the same amount of usage of it would be required for either platform): I have got no working experience with that, so if the webforms approach 'requires' extensive XSLT knowledge/usage, and the MVC approach little or none, then that would be a BIG plus for opting for the MVC approach, as that basically eliminates having an additional learning curve for XSLT. I know that you don't precisely write it that way, and that you do mention using XSLT in the MVC approach too, it would still be interesting to know if overal spoken MVC solutions tend to use less XSLT than the typical webform solutions do.
Another highlight you mention is the re-usability of code: the site will feature a homepage and at least 8 different kinds of follow-up pages. The latter ones all have some parts in common, and other parts may be closely related between the various pages. If the MVC parts lend themselves better to being re-used in various pages, that would be another plus for the MVC approach.
That still leaves the question open with me if the various third party modules out there tend to be mainly webforms based solutions, or MVC based ones, but at least from what you write it seems that when in a position to make a clean start, it might be best to directly opt for the MVC approach.
I hope you (or someone else) can comment some more on it, particularly regarding the points written in this follow-up I wrote...
Thanks a lot again; tonight I'm going to make a start with setting up the various document types, and very soon after I'll have to make a choice between MVC and webforms. I hope I can get some more targeted input (like the follow-up you posted) that will be helpful in making the proper decision, in light of my context. ;)
Cheers!
Olafo
Hi Olafo
Right some additional things worth considering.....
Umbraco (prior to its MVC implementation) was considered "designer friendly" despite being based on ASP.net (WebForms). This is entirely down to it's use of XSLT. XSLT allows a developer to effectively bypass WebForms altogether (server side controls) and frees the designer/developer to write 100% raw HTML! This is combined with complete access to Umbraco's API within the XSLT engine. The other advantage to using XSLT is it provides the ability to componentise sections of your site, lets say right hand modules, that would be otherwise difficult to do with just templates (nested master pages). As explained before though, you have to learn another language! Bear in mind you can still build true ASP.net components (user controls) and load them into the back office as macros in exactly the same way as you do with XSLT. But in general we only ever needed this when we required access to elements that would otherwise live outside of the CMS, or say you need a bunch of forms to do clever things with content. In all other cases XSLT is a better solution.
So in short if you go the WebForms route, you really should (for your own sanity) learn XSLT too!
In contrast MVC, whilst still working perfectly well with all the tech above including XSLT can be done entirely in Razor. It means you can discard XSLT altogether and build everything (including your components) in razor. So thats basically, your nested Views (templates), MacroScripts, Partials, Macro Partials...the whole shabam! The other advantage of working in MVC is you retain complete control of your HTML output because controls dont exist. You also get rid of the whole page lifecycle and event model....although most parts of the event model were awesome! But hey it's all client side these days, in a short space of time the emphasis is now on the browser rather than the server!
Either way you're in for a steep learning curve, I've found Razor incredibly frustrating at times but at least its a single syntax! XSLT at first glance looks easy, due to it resembling HTML (because its XML). But it's recursive nature can very quickly get you in a pickle and make things actually more difficult to follow than C#. It's also much harder to debug if you have access to VisualStudio.
Despite your worries over tight deadlines, my advice would be if you're starting out is always go with the newest, emerging technology rather than the older established technology. The biggest disadvantage you will find is a lack of support in the community and online....but in the long run it will be worth it!
If you do get stuck you can always message me!
Good luck
Regards
Martin
Hi Martin,
Thanks a lot for your additional insight into this matter; I've heard enough to make up my mind: it will definitely become the MVC way then. I fully hear you in all of your advice, and at this time I'd rather have the learning curve of C# + Visual Studio, than the XSLT one (that is not to say that XSLT is not an interesting and useful technology, because I know it is, but at this point in time I'd rather not have that leaning curve on top of it too).
Well then, with that decision made for MVC (a thing which I yesterday evening was already pretty certain would happen), yesterday I did some reading up on how to best install it. At this moment in time I have an out-of-the-box installation (webforms) that was done on XP with Webmatrix 2, and was provided with the Business starter kit. The recommended method I have seen mentioned for installing/configuring it for MVC seems to be to create a clean new ASP.NET MVC 4 project from within Visual Studio, then to use Nuget to install Umbraco and then manually copy the proper files to the newly created project (all like described for example here: http://stackoverflow.com/questions/17521154/how-to-setup-umbraco-6-1-2-in-visual-studio-2012-with-mvc-enabled-to-use-in-tfs).
Now, a thing I was wondering about: in light of it already having been installed with Webmatrix using the Webforms rendering engine, but not yet having been provided with actual content for the application I need to make, would it in your opinion be best to delete all of that, and install it clean again from the start, using the VS + NuGet approach as mentioned above, or is it easier/better to just switch over the rendering engine in the installation I've already made?
On another note (please pardon the noob questions, but as I'm new to VS too, I'd rather ask some trivial things rather than making an incorrect start): when it is fully set-up, should all of the development work (best) be done from VS, or can it also be done partially through the Umbraco back-office (and still all be visible in VS too)? What I'd expect is that it's perfectly fine to define document types, add content, add media etc. through the Umbraco back-office, and that that is then readily available from within VS, without further ado. But... what if one edits/creates templates/views in the Umbraco back-office (e.g. for using the toolage to automatically insert Umbraco properties), does all of this still automatically get picked up uin VS? Same for the vice versa route: does everything that gets created in VS get picked up automatically in the Umbraco back-office? In short: do these two development environments work with 100% synergy, or does one explicitly have to make edits and new items "known" in the other environment?
Either way it plays out: one very important requirement is that the content editors who will be filling the site do not have to mess around with VS, and can make 100% usage of the nice mechanism that the Umbraco back-office provides in terms of just providing the content in nicely tabbed back-office pages, all set-up with proper document types (using the right properties), and also easily add media. It would highly surprise me if such were not the case, but I'd rather ask the seemingly obvious at this point in time than hitting some unpleasant surprise at a later stage...
Once I've got a pretty good idea as to how to most efficiently and quickly start (IOW: to 'go with the flow') I can make a good start and get on to the hands-on stuff and start creating the site's structure in terms of document types, etc.
Thanks again and cheers,
Olafo
Hi Olafo
First things first, as you're using VS, avoid using the backoffice editors wherever and whenever possible, you'll just get yourself very quickly into a pickle otherwise! I dont need to go into the pros and cons of VS, other than to say, it's one of MS's biggest assets and the latest version is incredibly sophisticated and I can't imagine why you would want to use anything else!
Some of the questions you're asking depend entirely on whether you intend to develop with others rather than being the sole contributor to your codebase. If you're the sole contributor, you can load up EVERYTHING into VS so thats all your code along with the Umbraco build itself.
If you intend to have code contributors things get complicated! You might then need to consider some form of source control either via one of the free paths or by Microsofts own Team Foundation Server. We use TFS for our projects as many contribute to the project(s).
Our method was to create a project which only contains the user contributed code, which you can push to any Umbraco build either locally or on a server using build scripts and publishing. Thats one way of doing it but there are many other ways.
We debug our projects by attaching the debugger manually to the IIS process on our local PC's. Again there are many ways you can do this, most recently via IISExpress.
As for getting started do a few test runs with starter kits to get a feel for how to put your types together, then run a build from scratch with nuget and go from there. That way you won't be left with a whole ton of cruft that your never use or isnt quite to your liking. The great thing about nuget is you can get builds up and running very quickly.
I hope this answers some of your questions :-)
Martin
is working on a reply...