At CodeGarden we had an open space session about a code first approach for version 4, and a lot of people were talking about uSiteBuilder as the current solution, but also wanting a solution built into the core at some point, optimally by getting doctypes etc. entirely out of the db.
Until then, however, there is a lot of interrest in improving uSiteBuilder (and maybe the UmbraCodeFirst that was released at CodeGarden), to enable some of those benefits for forseable future.
Gathering up from our talks, and the conversation on twitter, this is what has been mentioned:
Merging the DataType support to the trunk (I've done that, just not comitted yet)
Removing the httpModule, and make a dashboard for running updates
Exporting existing items to .cs files (Exists already as 3rd party?)
Adding logging for enhanced traceability of what has been updated
I will commit what I have done so far on monday, when I get back to the office. Until then I thought we could have a discussion on what to build first, and who wants to be responsible for which parts, as well as a way to work simultaneously (branches pr feature?).
In my opinion there is a pretty crucial point missing from the list: Lazy loaded properties.
As uSiteBuilder works at the moment you can’t really utilize “Custom Type Convertors” (by subscribing to the ICustomTypeConvertor interface), when it comes to list of other nodes picked in the back-office, with pickers like the uComponent multi-node-picker etc.
Hitting any typesafe wrapped node will trigger getting all properties. If any one of these properties are node-pickers with a CustomTypeConvertor set up to convert e.g. a csv-string of node-ids to a List of specified DocumentTypes – all these, and all their properties, will be triggered as well.
Of course this is just the immediate problem, the lazy loaded properties should speed up performance for all usage where not absolutely all properties are used.
So we are working on uSiteBuilder again and plan to do that actively in future.
Moving to Mercurial is on our TODO list but even before we do that we can have other new people in the codeplex team. We welcome everyone who wants to join to let us know and we'll give them the access to the repository. It would also be good if we can find more people who are willing to test our commits before we release a new stable version of uSiteBuilder.
As for the future steps, it would be good if we all (people from this conversation and others who would like to join us) have a (Skype?) call, agree on who is doing what and then post that information somewhere on CodePlex. Let me know if that will be fine with you guys or if you would prefer to use this thread for now to agree on who is doing what.
@Morten - Why do you want to remove the HTTPModule?
Personally I think this is one of the great features as it allows you to use uSiteBuilder as part of your build cycle, rather than remove it completely, maybe it would be better to make it optional if some people do not want to use it in this way. Although I cannot see why you would not want your changes deployed automatically if you are deploying new code?
I am really looking forward to uSiteBuilder improvements and we would be happy to help contribute & test other changes, so please keep me in the loop.
@Chris - Let me clarify, as the one liner does not tell the whole story.
It's fine by me to have a setting that allows you to run the sync on every app startup. But the current implementation that starts by modifying the web.config file, to hook itself up is a bit hacky. I think there is a better way to wire that up, and make it an optional thing.
@Sasa - I think this thread will serve nicely as a starting point, rather than a Skype session where everyone needs to be present at the same time. Let's see who want's to pitch in, and the look at how to proceed.
I'm certainly up for continuing my contributions to this project, I think if we can keep it moving in the right direction it has potential to become the solution that either gets moved to the core at a later date or at least represents significant steps toward defining the features that people would like to see in the Core. I agree with Morten, Skype could be a little difficult so here is fine and perhaps if necessary we could setup a chat room somewhere and all agree a date/time to meet if required.
The idea of setting up clearly defined deliverables and breaking them out between contributors I think is the best way forward and probably going to allow for quicker releases. Not sure on other peoples views on this but I struggle with merges on SVN (or at least used to back when I used it last) so a move to Mercurial sooner rather than later would help me. Microsoft did offer some help in this regard when I wanted to convert one of my other repos so perhaps we can contact them to see if they will assist? If it is going to happen it needs to happen sooner rather than later I think before more people come on board and we are stuck into new developments.
@Morten - Instead of a HttpModule, can't "we" just hook the sync up by extending umbraco.BusinessLogic.ApplicationBase ?
@Sasa - I would like to help out - we use uSiteBuilder on all our project and have been for quite some time. Though my time spent on uSiteBuilder-development will be very limited and probably in my spare time. (If you're interested let me know).
Hi guys - I'm up for helping where I can as I am using uSiteBuilder on most of my Umbraco projects now.
FWIW I would love to see a 2-way sync process (so doctype changes via the UI are captured first - e.g. a PM wants to change property descriptions). If that is a pain even a way to remove property names/description sync would suffice in most cases.
Hopefully we can hear from Stephan Kvart - the dev of UmbraCodeFirst, as it looks like a very similar solution and I'm sure he can bring some good ideas to the table!
I don't know if I have anything useful to add, there are already a bunch of good devs on this project. I haven't looked at uSiteBuilder, so I can't really say what we've done similarly or differently. UmbraCodeFirst was really something I just threw together in order to achieve a few goals.
I wanted to have a single-point-of-contact between my front- and back-end, i.e. and abstraction on top of the Document- and Node API's, this was accomplished through what I have called the ModelFactory (I like the factory pattern, and I like consistency).
My approach currently forces a usercontrol-only approach, because that's my style of writing sites. I haven't used xslt in quite some time, and although Razor macros are really useful, that is just a different syntax when you have a typed model. I rarely use Macros in my templates, as a code-first approach doesn't really work if macros need to be pre-registered in order to work. Macros are great for inserting into the RTE though!
The in-line preview I demoed briefly at CodeGarden is just one of the many benefits of using a single-point-of-contact, but a lot more work is needed before I'm satisified.
I might sound like I'm aiming for Hive now, but I really think that abstractions are the way to go. We need to have abstractions in the core, so that we can implement our own data providers for the different aspects of Umbraco, ideally, nothing but content goes in the database. In the mean time, we'll have to provide these abstractions ourselves, by building wrappers for the different API's.
In my opinion, there's really not much we can do about this, as long as there is a tight coupling between the different building blocks and the underlying storage facility.
My approach to developing code-first, is that the client is never allowed to add functionality, hence I have no need for the editing functionality in Umbraco. Yes, this might seem like a blunt approach to my clients, but it's in my experience the only way to reliably deliver stability and maintainability to a long-term project. With tight iterations and a stable delivery process, the same end result can be achieved as letting your client go cowboy in their installation.
My post might not be very coherent, but I'm writing this in a few free minutes between cooking dinner and putting my kid to bed. I'd be happy to continue this discussion though, as uSiteBuilder clearly has the advantage in adopters over UmbraCodeFirst. Our common goal is after all to have solid code-first approach in Umbraco 4, not who gets the Karma points :)
We’ll summarize here what we’ve read in this thread so far and what our thoughts are on that.
Regarding migration to Mercurial, we've submitted a request to the CodePlex team and asked them to help us migrate the project to Mercurial (that’s how it goes with CodePlex). We’ll keep you updated on the progress there and I would suggest you don’t make any new commits to the current repository until the migration is done.
Here is the current work that we are doing on the project:
Disabling of sync on application start. We already started with work on this feature. You will be able to disable sync on application start by adding a parameter to appSettings section of your web.config files. This feature will be useful for frequent changes on your projects when you are not making changes in assets that are being synced.
Improvements of performance of the sync process. We found a few improvement points and are working on improving performance of the framework.
Here is the list of the features that we would like to see in the future releases of uSiteBuilder and which were proposed by other people:
Lazy loading of properties of document types.
Adding logging for enhanced traceability of what has been updated.
Here is the list of the features built since the last release (committed to the repository but not fully tested yet and not in the latest release):
Support for DataTypes – implemented by Simon Dingley and merged to trunk by Morten Bock Sørensen.
Support for MediaTypes – implemented by Simon Dingley
Regarding the HTTP Module approach, the first release of uSiteBuilder didn’t use that approach. In the first release we had a class which inherits from Umbraco’s Global class – that way we were able to do the sync on application start event. The problem with that first approach was that too many times people forgot to include our “Global.asax” file and then the sync process didn’t work. After a number of reported cases we decided to implement a different solution. We tried using the approach with inheritance of umbraco.BusinessLogic.ApplicationBase but that didn’t work because we couldn’t start with the sync early enough. We tried other things as well but didn’t find any other workable solutions given the current architecture of Umbraco CMS. If Umbraco core would be modified to run special types of plugins on application start then we could have a nice (non-hack) solution but even then, the solution would not work for the current and older version of the CMS. So if anyone has a better idea just let us know.
For people that would like to contribute by implementing new features, please choose a feature from the above list or propose one if you don’t see it in the list and you would like to see it as part of uSiteBuilder. Please also post here what you are going to work on and what your expectations are on completion of your work.
It’s great to hear that other people are willing to help with the work on uSiteBuilder!
We would loose support for websites running on .NET 2.0 (3.5). We built tens of websites ourselves in .NET 2.0 using uSiteBuilder and I believe there are others who did that as well. So this .NET 4.0 feature is still not an option.
We need a mechanism to intercept each request. It is not enough to just run sync on the first request (when application gets started). On first request we start sync but if the sync can't be completed because of a bug, we will show an error message. On each subsequent request we have to check if the sync was done successfuly and if not, to show the same error message. Otherwise, if we would not be showing the error message all the time, your website would go into a non-stable state where your document types in DB are not in sync with your document types in DLLs and you would not even be aware of the issue.
@Barry, you don't have to be added as a team member to be able to download the latest source; you only have to be added as a team member in case you want to commit changes to the repository (let me know if you would like to do that at some point). To download the latest source just go to the "Source Code" tab of the codeplex project, select the latest revision and then click on the "Download" link. Here is the link to the latest revision at this point: http://usitebuilder.codeplex.com/SourceControl/changeset/changes/91906. Regarding BitBucket, we already asked the CodePlex team to migrate repository to Mercurial and they replied to us today saying that someone got assigned with that task within their team. We'll keep you posted on the progress there.
@Sasa, fair enough. I understand the need for a 2.0 approach, but I still don't like that the dll will add itself to the web.config file on startup, instead of that being an install task. I would liek to try and think if there is some other way to acheive the same goal. As far as I can tell, the goal is:
1. Installation by simply copying a dll 2. Complete migration before any website requests are served (What is the "non stable state" example?) 3. .Net 2.0 compatibility
By the way, the approach of having to hook in before anything is served on the website, how does that work on load balanced environments? What is the best practise? Shut down site => upgrade on one server => Turn site on again?
@Morten, of course, if you find a better solution let us all know.
Regarding the "non stable state" - if sync of a new field doesn't complete successfully and you use that field on a template then you could see different kinds of strange errors on that template (or accross the website if you used the field on the main template); for example, you could have an "object reference not set to..." exception, you would not know what the cause of the issue is and it would be quite hard to understand that the sync of uSiteBuilder failed at some point in past. In our oppinion, having our exception thrown on each request and with a detailed error message is the best solution - you will imediatelly notice the issue and someone will have to fix the issue fast.
Regarding the sync in load balanced environments, you are right, that's what we would suggest as well since we didn't build any special support for sync in the load balanced environments.
@everyone, migration to Mercurial is done. Here are the new access details:
Just to say, I've been using this project for a few days now and I think it's a great addition to Umbraco - I can already see the benefits of using it on a multiple developer project.
Following the news that 5 has been retired I'm looking forward to seeing where uSiteBuilder goes. :)
1) Any reason that uSiteBuilder is still using the “deprecated” umbraco.presentation.nodeFactory.Node and not umbraco.NodeFactory.Node ?
I’m asking because we often utilize the UrlName property (only found) on the umbraco.NodeFactory.Node, and therefore made changes locally to use the umbraco.NodeFactory.Node throughout uSiteBuilder so we could add the UrlName on the DocumentTypeBase as well.
2) On another note – another thing I did (as i was editing for local use) was remove the redundant NiceUrl property, as it does the same as the Url property… Just to clarify, taken from the Umbraco Source:
public int Id { get { if (!_initialized) initialize(); return _id; } }
public string Url { get { return library.NiceUrl(Id); } }
public string NiceUrl { get { return library.NiceUrl(_id); } }
The only difference is that NiceUrl takes the id from the private backfield of the property, bypassing the initialize-function (which in some rare case could render the property useless) … anyway – never going to happen with uSiteBuilder – but should uSiteBuilder set a better example than Umbraco it self, by removing such a redundant property ?
Would love to be added to the commiters list for this one :)
I was banging the drum about uSB at CodeGarden pretty loudly as we've had such fun using it and I wanted to see it moved forward to make it even better. So glad you've moved to Mercurial. We had a patch we submitted on the old SVN code which appears to have disappeared, would be nice to get that sent in as a pull request for you. It simply allowed you to set the Alias name via attributes for cases when you already had a site manually set up that you wanted to use uSiteBuilder with via Rich Greens awesome/yet ugly exporter :) As it was uSB was set to auto guess the Alias each time which makes sense from a "clean slate" angle but not if a site is already half built.
Additionally we've been using the ContentHelper class in our Razor scripts so we get intellisense, this has worked out well (blog post in the making there) however we can't use the "switch off sync" flag as it kills off ContentHelper, something to look into there I think.
Might I suggest we create a Trello board with all the little jobs and issues that people can work through so we don't all end up working on the same thing?
@Sasa, it would be nice if there was a little information about how to contribute. I just created a pull request that fixes a showstopper bug in uisitebuilder. Is there someone I should contact, or just wait until someone sees the request?
You did it all correctly - you made a new fork, made the changes, pushed them and then made a pull request. We received your pull request, reviewed the changes that you've made and will soon accept them.
We are just going to try your changes a bit and will then accept and push your changes to the main branch.
Thank you for doing a good job! I'm sure the community will appreciate it as well.
Follow up from CodeGarden
At CodeGarden we had an open space session about a code first approach for version 4, and a lot of people were talking about uSiteBuilder as the current solution, but also wanting a solution built into the core at some point, optimally by getting doctypes etc. entirely out of the db.
Until then, however, there is a lot of interrest in improving uSiteBuilder (and maybe the UmbraCodeFirst that was released at CodeGarden), to enable some of those benefits for forseable future.
Gathering up from our talks, and the conversation on twitter, this is what has been mentioned:
In my opinion there is a pretty crucial point missing from the list: Lazy loaded properties.
As uSiteBuilder works at the moment you can’t really utilize “Custom Type Convertors” (by subscribing to the ICustomTypeConvertor interface), when it comes to list of other nodes picked in the back-office, with pickers like the uComponent multi-node-picker etc.
Hitting any typesafe wrapped node will trigger getting all properties. If any one of these properties are node-pickers with a CustomTypeConvertor set up to convert e.g. a csv-string of node-ids to a List of specified DocumentTypes – all these, and all their properties, will be triggered as well.
Of course this is just the immediate problem, the lazy loaded properties should speed up performance for all usage where not absolutely all properties are used.
I've just checked in the current state of my changes on codeplex.
https://usitebuilder.codeplex.com/SourceControl/changeset/changes/91906
Hi Morten and Steffen,
Last week we heard about the decision of Umbraco core team to retire v5 and I posted a message after that: http://our.umbraco.org/projects/developer-tools/usitebuilder/usitebuilder-support/32367-When-you-moving-to-Mercurial.
So we are working on uSiteBuilder again and plan to do that actively in future.
Moving to Mercurial is on our TODO list but even before we do that we can have other new people in the codeplex team. We welcome everyone who wants to join to let us know and we'll give them the access to the repository. It would also be good if we can find more people who are willing to test our commits before we release a new stable version of uSiteBuilder.
As for the future steps, it would be good if we all (people from this conversation and others who would like to join us) have a (Skype?) call, agree on who is doing what and then post that information somewhere on CodePlex. Let me know if that will be fine with you guys or if you would prefer to use this thread for now to agree on who is doing what.
Regards,
Vladan and Sasa
@Morten - Why do you want to remove the HTTPModule?
Personally I think this is one of the great features as it allows you to use uSiteBuilder as part of your build cycle, rather than remove it completely, maybe it would be better to make it optional if some people do not want to use it in this way. Although I cannot see why you would not want your changes deployed automatically if you are deploying new code?
I am really looking forward to uSiteBuilder improvements and we would be happy to help contribute & test other changes, so please keep me in the loop.
Cheers,
Chris
@readingdancer
@Chris - Let me clarify, as the one liner does not tell the whole story.
It's fine by me to have a setting that allows you to run the sync on every app startup. But the current implementation that starts by modifying the web.config file, to hook itself up is a bit hacky. I think there is a better way to wire that up, and make it an optional thing.
Hope that clears it up a bit.
@Sasa - I think this thread will serve nicely as a starting point, rather than a Skype session where everyone needs to be present at the same time. Let's see who want's to pitch in, and the look at how to proceed.
I just want to say, this thread makes me happy. Yay for a code first approach! Yay for improving usitebuilder! Really looking forward to this.
I'm certainly up for continuing my contributions to this project, I think if we can keep it moving in the right direction it has potential to become the solution that either gets moved to the core at a later date or at least represents significant steps toward defining the features that people would like to see in the Core. I agree with Morten, Skype could be a little difficult so here is fine and perhaps if necessary we could setup a chat room somewhere and all agree a date/time to meet if required.
The idea of setting up clearly defined deliverables and breaking them out between contributors I think is the best way forward and probably going to allow for quicker releases. Not sure on other peoples views on this but I struggle with merges on SVN (or at least used to back when I used it last) so a move to Mercurial sooner rather than later would help me. Microsoft did offer some help in this regard when I wanted to convert one of my other repos so perhaps we can contact them to see if they will assist? If it is going to happen it needs to happen sooner rather than later I think before more people come on board and we are stuck into new developments.
@Morten - Instead of a HttpModule, can't "we" just hook the sync up by extending umbraco.BusinessLogic.ApplicationBase ?
@Sasa - I would like to help out - we use uSiteBuilder on all our project and have been for quite some time. Though my time spent on uSiteBuilder-development will be very limited and probably in my spare time. (If you're interested let me know).
Exporting items to .cs files can be done by using http://our.umbraco.org/projects/developer-tools/usitebuilder-import
The code is hairy as hell but it works, feel free to take whatever you need and re-use (the SQL queries should be useful if nothing else)
Rich
Hi guys - I'm up for helping where I can as I am using uSiteBuilder on most of my Umbraco projects now.
FWIW I would love to see a 2-way sync process (so doctype changes via the UI are captured first - e.g. a PM wants to change property descriptions). If that is a pain even a way to remove property names/description sync would suffice in most cases.
Hopefully we can hear from Stephan Kvart - the dev of UmbraCodeFirst, as it looks like a very similar solution and I'm sure he can bring some good ideas to the table!
I don't know if I have anything useful to add, there are already a bunch of good devs on this project. I haven't looked at uSiteBuilder, so I can't really say what we've done similarly or differently. UmbraCodeFirst was really something I just threw together in order to achieve a few goals.
I wanted to have a single-point-of-contact between my front- and back-end, i.e. and abstraction on top of the Document- and Node API's, this was accomplished through what I have called the ModelFactory (I like the factory pattern, and I like consistency).
My approach currently forces a usercontrol-only approach, because that's my style of writing sites. I haven't used xslt in quite some time, and although Razor macros are really useful, that is just a different syntax when you have a typed model. I rarely use Macros in my templates, as a code-first approach doesn't really work if macros need to be pre-registered in order to work. Macros are great for inserting into the RTE though!
The in-line preview I demoed briefly at CodeGarden is just one of the many benefits of using a single-point-of-contact, but a lot more work is needed before I'm satisified.
I might sound like I'm aiming for Hive now, but I really think that abstractions are the way to go. We need to have abstractions in the core, so that we can implement our own data providers for the different aspects of Umbraco, ideally, nothing but content goes in the database. In the mean time, we'll have to provide these abstractions ourselves, by building wrappers for the different API's.
In my opinion, there's really not much we can do about this, as long as there is a tight coupling between the different building blocks and the underlying storage facility.
My approach to developing code-first, is that the client is never allowed to add functionality, hence I have no need for the editing functionality in Umbraco. Yes, this might seem like a blunt approach to my clients, but it's in my experience the only way to reliably deliver stability and maintainability to a long-term project. With tight iterations and a stable delivery process, the same end result can be achieved as letting your client go cowboy in their installation.
My post might not be very coherent, but I'm writing this in a few free minutes between cooking dinner and putting my kid to bed. I'd be happy to continue this discussion though, as uSiteBuilder clearly has the advantage in adopters over UmbraCodeFirst. Our common goal is after all to have solid code-first approach in Umbraco 4, not who gets the Karma points :)
//S
Hi everyone,
We’ll summarize here what we’ve read in this thread so far and what our thoughts are on that.
Regarding migration to Mercurial, we've submitted a request to the CodePlex team and asked them to help us migrate the project to Mercurial (that’s how it goes with CodePlex). We’ll keep you updated on the progress there and I would suggest you don’t make any new commits to the current repository until the migration is done.
Here is the current work that we are doing on the project:
Here is the list of the features that we would like to see in the future releases of uSiteBuilder and which were proposed by other people:
Here is the list of the features built since the last release (committed to the repository but not fully tested yet and not in the latest release):
Regarding the HTTP Module approach, the first release of uSiteBuilder didn’t use that approach. In the first release we had a class which inherits from Umbraco’s Global class – that way we were able to do the sync on application start event. The problem with that first approach was that too many times people forgot to include our “Global.asax” file and then the sync process didn’t work. After a number of reported cases we decided to implement a different solution. We tried using the approach with inheritance of umbraco.BusinessLogic.ApplicationBase but that didn’t work because we couldn’t start with the sync early enough. We tried other things as well but didn’t find any other workable solutions given the current architecture of Umbraco CMS. If Umbraco core would be modified to run special types of plugins on application start then we could have a nice (non-hack) solution but even then, the solution would not work for the current and older version of the CMS. So if anyone has a better idea just let us know.
For people that would like to contribute by testing the new features, please download the source from codeplex, build it and report any found issues here at http://our.umbraco.org/projects/developer-tools/usitebuilder/usitebuilder-support.
For people that would like to contribute by implementing new features, please choose a feature from the above list or propose one if you don’t see it in the list and you would like to see it as part of uSiteBuilder. Please also post here what you are going to work on and what your expectations are on completion of your work.
It’s great to hear that other people are willing to help with the work on uSiteBuilder!
Regards,
Vladan and Sasa
A note on a cleaner way of doing the http module:
http://blog.davidebbo.com/2011/02/register-your-http-modules-at-runtime.html
It requires no entries in web config.
Can I be added to the repo please so I can download and test the latest version with datatype support and sync switching?
Also I'd like to echo Pete's comments re getting the source into BitBucket so we can all get involved and help make uSiteBuilder even better!
@Morten, there are two issues with that approach:
@Barry, you don't have to be added as a team member to be able to download the latest source; you only have to be added as a team member in case you want to commit changes to the repository (let me know if you would like to do that at some point). To download the latest source just go to the "Source Code" tab of the codeplex project, select the latest revision and then click on the "Download" link. Here is the link to the latest revision at this point: http://usitebuilder.codeplex.com/SourceControl/changeset/changes/91906.
Regarding BitBucket, we already asked the CodePlex team to migrate repository to Mercurial and they replied to us today saying that someone got assigned with that task within their team. We'll keep you posted on the progress there.
Cheers. For anyone else the correct link of the latest version (omitting the full stop) is http://usitebuilder.codeplex.com/SourceControl/changeset/changes/91906
Will send you a request if I find something I can commit from BitBucket.
@Sasa, fair enough. I understand the need for a 2.0 approach, but I still don't like that the dll will add itself to the web.config file on startup, instead of that being an install task. I would liek to try and think if there is some other way to acheive the same goal. As far as I can tell, the goal is:
1. Installation by simply copying a dll
2. Complete migration before any website requests are served (What is the "non stable state" example?)
3. .Net 2.0 compatibility
By the way, the approach of having to hook in before anything is served on the website, how does that work on load balanced environments? What is the best practise? Shut down site => upgrade on one server => Turn site on again?
@Morten, of course, if you find a better solution let us all know.
Regarding the "non stable state" - if sync of a new field doesn't complete successfully and you use that field on a template then you could see different kinds of strange errors on that template (or accross the website if you used the field on the main template); for example, you could have an "object reference not set to..." exception, you would not know what the cause of the issue is and it would be quite hard to understand that the sync of uSiteBuilder failed at some point in past. In our oppinion, having our exception thrown on each request and with a detailed error message is the best solution - you will imediatelly notice the issue and someone will have to fix the issue fast.
Regarding the sync in load balanced environments, you are right, that's what we would suggest as well since we didn't build any special support for sync in the load balanced environments.
@everyone, migration to Mercurial is done. Here are the new access details:
Just to say, I've been using this project for a few days now and I think it's a great addition to Umbraco - I can already see the benefits of using it on a multiple developer project.
Following the news that 5 has been retired I'm looking forward to seeing where uSiteBuilder goes. :)
I might as well ask here…
1) Any reason that uSiteBuilder is still using the “deprecated” umbraco.presentation.nodeFactory.Node and not umbraco.NodeFactory.Node ?
I’m asking because we often utilize the UrlName property (only found) on the umbraco.NodeFactory.Node, and therefore made changes locally to use the umbraco.NodeFactory.Node throughout uSiteBuilder so we could add the UrlName on the DocumentTypeBase as well.
2) On another note – another thing I did (as i was editing for local use) was remove the redundant NiceUrl property, as it does the same as the Url property…
Just to clarify, taken from the Umbraco Source:
public int Id{
get
{
if (!_initialized)
initialize();
return _id;
}
}
public string Url{
get { return library.NiceUrl(Id); }
}
public string NiceUrl{
get { return library.NiceUrl(_id); }
}
The only difference is that NiceUrl takes the id from the private backfield of the property, bypassing the initialize-function (which in some rare case could render the property useless) … anyway – never going to happen with uSiteBuilder – but should uSiteBuilder set a better example than Umbraco it self, by removing such a redundant property ?
Would love to be added to the commiters list for this one :)
I was banging the drum about uSB at CodeGarden pretty loudly as we've had such fun using it and I wanted to see it moved forward to make it even better. So glad you've moved to Mercurial. We had a patch we submitted on the old SVN code which appears to have disappeared, would be nice to get that sent in as a pull request for you. It simply allowed you to set the Alias name via attributes for cases when you already had a site manually set up that you wanted to use uSiteBuilder with via Rich Greens awesome/yet ugly exporter :) As it was uSB was set to auto guess the Alias each time which makes sense from a "clean slate" angle but not if a site is already half built.
Additionally we've been using the ContentHelper class in our Razor scripts so we get intellisense, this has worked out well (blog post in the making there) however we can't use the "switch off sync" flag as it kills off ContentHelper, something to look into there I think.
Might I suggest we create a Trello board with all the little jobs and issues that people can work through so we don't all end up working on the same thing?
Cheers
Pete
Yes I also had the supress sync web.config key killing ContentHelper issue. Trello boards sounds like a great idea Pete.
Created a public Trello board with my quick idea on it, feel free to add to it :)
https://trello.com/board/usitebuilder-developement/5003f2079e5caa8f323f7c1d
Pete
@Sasa, it would be nice if there was a little information about how to contribute. I just created a pull request that fixes a showstopper bug in uisitebuilder. Is there someone I should contact, or just wait until someone sees the request?
A few pointers would be most welcome.
Hi Michael,
You did it all correctly - you made a new fork, made the changes, pushed them and then made a pull request. We received your pull request, reviewed the changes that you've made and will soon accept them.
We are just going to try your changes a bit and will then accept and push your changes to the main branch.
Thank you for doing a good job! I'm sure the community will appreciate it as well.
Regards,
Sasa
@Pete, I like the idea of the Trello board that you've made and will use it.
is working on a reply...