What is the benefit of this package? What if you change the name of a document type and leave the assemblies in the bin? Are the document types recreated?
Maybe I'm not seeing the whole picture.. I just don't get it. Please explain it with a real world usage scenareo.
I had hopes that Umbraco 5 would be the way as this package describes. I saw a presentation where they talked about custom providers to hive(?) so it still might be possible. But from what I've seen is that the default will still be the same as it is now. ( I might be outdated didn't follow it very closely )
CRUD'ing doctypes and macros in a web interface makes sense if the majority of users ain't developers. For example: in a 'cms' like Wordpress it probably makes more sense to do everything in the back-end.
What I see (I might be wrong) on Twitter is that a lot of Umbraco sites are made by proffesional businesses for paying clients. You could just keep the content, media and user section in the Umbraco back-end and dump the rest. If you look at Ruby on rails or Django (I know these ain't cms) they have been doing this from the start. In .net you have N2 cms that does this too but ironicly their web-interface is really bad.
Anyway, like Matt and their website says there are a lot of benefits of doing things this way and I am going to give this package a go when I have more time.
@Ismail yea, I was wondering about custom datatypes. My thoughts on the later would be not to use it where you clients want to edit doctypes etc, and maybe even completley remove the trees to prevent editing (you could just set it in the db to not load the relevant trees, or remove permissions on sections if you can get away with closing down an entire section).
Thank you for trying our framework and for your comments!
About custom data types - those are not directly supported by our framework in a way that you can create data types through Visual Studio and have them deployed automatically. You must create your data type directly through browser in Umbraco as you always did. However, you can declare document type property in your class to be of that newly created data type as following:
[DocumentTypeProperty(UmbracoPropertyType.Other,
Tab = "My Tab",
OtherTypeName = "MyCustomDataType",
Description = "Text.")]
public string MyProperty
In this example you declared property 'MyProperty' which is of 'MyCustomDataType' data type. What I did in this example is tht I set property type to UmbracoPropertyType.Other and set OtherTypeName to name of that custom data type. Note that string value of MyProperty during runtime will contain actual value of this data type (usually xml).
Furthermore, instead of declaring property as string MyProperty you can declare it with your own .NET type (instead of string) if you build appropriate convertor (class that implements Vega.USiteBuilder.Types.ICustomTypeConvertor so that you don't hasle with xml every time when you use this property). But we'll explain that in some tutorial on our website.
I kind of understand what's going on.. buy why?
What is the benefit of this package? What if you change the name of a document type and leave the assemblies in the bin? Are the document types recreated?
Maybe I'm not seeing the whole picture.. I just don't get it. Please explain it with a real world usage scenareo.
I think it's pretty nicely summed up on their homepage:
http://usitebuilder.vegaitsourcing.rs/home
I had hopes that Umbraco 5 would be the way as this package describes. I saw a presentation where they talked about custom providers to hive(?) so it still might be possible. But from what I've seen is that the default will still be the same as it is now. ( I might be outdated didn't follow it very closely )
CRUD'ing doctypes and macros in a web interface makes sense if the majority of users ain't developers. For example: in a 'cms' like Wordpress it probably makes more sense to do everything in the back-end.
What I see (I might be wrong) on Twitter is that a lot of Umbraco sites are made by proffesional businesses for paying clients. You could just keep the content, media and user section in the Umbraco back-end and dump the rest. If you look at Ruby on rails or Django (I know these ain't cms) they have been doing this from the start. In .net you have N2 cms that does this too but ironicly their web-interface is really bad.
Anyway, like Matt and their website says there are a lot of benefits of doing things this way and I am going to give this package a go when I have more time.
My colleague Tim had a look at his and 2 bug bears:
@Ismail yea, I was wondering about custom datatypes. My thoughts on the later would be not to use it where you clients want to edit doctypes etc, and maybe even completley remove the trees to prevent editing (you could just set it in the db to not load the relevant trees, or remove permissions on sections if you can get away with closing down an entire section).
Matt
Hello guys,
Thank you for trying our framework and for your comments!
About custom data types - those are not directly supported by our framework in a way that you can create data types through Visual Studio and have them deployed automatically. You must create your data type directly through browser in Umbraco as you always did. However, you can declare document type property in your class to be of that newly created data type as following:
[DocumentTypeProperty(UmbracoPropertyType.Other, Tab = "My Tab", OtherTypeName = "MyCustomDataType", Description = "Text.")] public string MyPropertyIn this example you declared property 'MyProperty' which is of 'MyCustomDataType' data type. What I did in this example is tht I set property type to UmbracoPropertyType.Other and set OtherTypeName to name of that custom data type. Note that string value of MyProperty during runtime will contain actual value of this data type (usually xml).
Furthermore, instead of declaring property as string MyProperty you can declare it with your own .NET type (instead of string) if you build appropriate convertor (class that implements Vega.USiteBuilder.Types.ICustomTypeConvertor so that you don't hasle with xml every time when you use this property). But we'll explain that in some tutorial on our website.
Ooh, that .NET type is very interesting, looking forward to that tutorial!
is working on a reply...