Here's a wacky thought...

[Richard Terris]

I saw / heard in the keynote that some of the best packages are to be built into the core, such as uComponents.

I'm not 100% convinced this is a great idea. I personally use uComponents and I think the majority do - but - for the minority of people who don't use it, should it be there taking up room?

A wacky idea I have - I use uSiteBuilder for all of my v4 apps, as I enjoy the code first approach, and really hate XSLT.

Razor is great too, but I feel this really should be used in conjunction with MVC.

So, V5 was supposed to deliver a more code first paradigm, why not learn from that and build a uSiteBuilder type library, where document types can be created in code - or add uSiteBuilder as part of the core?

Again, as with uComponents, I'm in 2 minds as to whether anything should be made part of the core, or left as optional plugins, but if this is the way we're going to go - let's think about uSiteBuilder too 

[Aaron Powell]

As a developer a code-first approach is a lovely idea but I’ve never used uSiteBuilder so I can’t really comment on whether that’s the best approach or not. But here’s another way to think about it, could we not make a way to take the document type structure out of the database?

I see one of the advantages that uSiteBuilder brings is the ability to source-control your document types, but it’s still some-what of a hack so maybe there’s an even better way.

 

(Just thinking out loud here)

 

Aaron Powell
MVP - Internet Explorer (Development) | FunnelWeb Team Member

http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | Github | BitBucket

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/h--0Wf5VeYQJ.
To post to this group, send email to umbra...@googlegroups.com.
To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/umbraco-dev?hl=en.

[Sebastiaan Janssen]

Agreed, uSitebuilder is absoluteluly great for productivity, but it does some whacky things on app pool startup and you have to be careful doing things in the right order. I LOVE the idea of getting macros/doctypes out of the db and onto disk though!

[Gareth Evans]

I was musing on something similar regarding for example, an XML structure which could represent a document type with tabs and properties (along with their data type definitions) and then an executable/class library that could be implemented as part of a build rule to apply the changes to a given umbraco instance.

This would be backwards compatible with the existing database-based document type storage and would also allow a code-first approach.

These XML files (i'm not a big fan of XML but it's a good way to store relational data in a text file) could also be code-first generated if required using some form of a fluent API.

While I disagree that uSiteBuilder should be part of the core, Aaron raises a point that it would be nice to source control your document types. 

Taking them out of the database is one way, but I personally feel they should be in the database - since they are the metadata that describes the schema/structure of the data that is stored in the DB.

Of course, uSiteBuilder does offer more than just source control/code first generation of your document types; it also provides strongly typed classes that map to those document types that you can use to query data as well as it's own inheritance structure for masterpages I believe.

In my opinion, This stuff definitely needs to remain external to core

Gareth

[Richard Terris]

But perhaps there is an opportunity to develop Umbraco class libraries in the style of uSiteBuilder?

If we're improving the core and learning from the best bits of V5 then code-first is really a strong thing for developers.

A lot of people are grumbling about ditching Umbraco in favour of other MVC CMS' but I'm wondering how much of that is because of MVC and how much is that they were looking forward to code-first approach that V5 was going to allow?

To unsubscribe from this group, send email to umbraco-dev+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/umbraco-dev?hl=en.

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.
To post to this group, send email to umbra...@googlegroups.com.

To unsubscribe from this group, send email to umbraco-dev+unsubscribe@googlegroups.com.

[Morten Bock Sørensen]

I too, had really been looking forward to source controllable developer items in V5, so I would very much like to see this sort of thing in V4.

Yesterday I did a bit of brainstorming on the options there are for this sort of feature, starting from "how would I like to define my doctypes", and I'd like to create an Open space discussion on this tomorrow at CG12.

The options I've considered so far are:

1.: Migration based. A bit like uSiteBuilder, where the doctypes stay in the DB as is, but adds the option to create those using code migrations. for example like:

[Migration(12345)
public class AddHomeDocType : Migration{

   public void Up(){

      Doctype.Create("Home");

      Doctype["Home"].AddProperty("Name","alias","datatype alias", etc...);

   }

}

2.: Code first. Creating C# classes marked with attributes, or somehow defined by convention. This would be great for .net developers to get the doctypes out of the database, and could co-exist with database or xml defined document types, for those (80%?) who prefer creating the doctypes through the UI. Having the doctypes defined in code, would also offer value to working with the data strongly typed, instead of key/value bags.

[DocType(alias = "MyType")]

public class MyType{

   [Property(DataType = "Number", alias ="someCount")] 

   public int Count {get;set;}

   [Property(DataType = "RichText", alias ="bodytext")] 

   public string BodyText {get;set;}

   [Property(DataType = "SomeCustom", alias ="myCustom", Converter = typeof(MyCustomDatatypeConverter))] 

   public MyCustomType Custom {get;set;}

}

3.: Xml defined. This would probably be the easiest one to start out with, but the biggest issue I have with xml is that it is not discoverable when writing it, in the same way that C# is in visual studio.

While we are talking code first, I think it is important to also remember all other dev type items in umbraco. DataTypeDefinitions, Macros, Masterpages. Being able to define it all from a CF perspective would be the best thing since sliced bread to me :-)

[Richard Terris]

I think if something like this is to be done, it should be the best option rather than the easiest.

"code-first" option to me would be the best and uSiteBuilder have definitely provided us with a great jumping-off point.

Unfortunately I can't be at CG12 - as the guys all know the trouble I went to but was beaten by the passport office!

But I'd love to be involved in the discussion on this topic in particular.

If you get your open space chat up and running, could you let me know the outcome afterwards?

[Gareth Evans]

If you go with an XML based option, it's light to implement, portable; doesn't require compiliation and can be source controlled.

It's definitely my preference.

The strongly typed classes could be generated as .cs files and written to app_code from the XML by a specific tool, should people want this feature.

These classes could implement properties that were mapped to the document type definition but also inherit from DynamicNode to get the benefit of what that class provides.

I believe if we were to have an XML schema then the XML would be discoverable, though I may be wrong on this front? For example; web.config in visual studio.

If you want the full functionality of uSiteBuilder, we shouldn't provide that in core; e.g. merge the uSiteBuilder project in - only provide some feature set which is functional enough for the majority; at least in my opinion.

I'm not suggesting we go for the easiest option in terms of code, but a simpler option that is easier understood by non software engineers.

Gareth

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/HIp1Spi6Ot8J.

To post to this group, send email to umbra...@googlegroups.com.

To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.

[Aaron Powell]

I’m going to put this up for an open space as well tomorrow and I’ll make sure any notes back in this thread

 

Aaron Powell
MVP - Internet Explorer (Development) | FunnelWeb Team Member

http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | Github | BitBucket

 

--

You received this message because you are subscribed to the Google Groups "Umbraco development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/HIp1Spi6Ot8J.

To post to this group, send email to umbra...@googlegroups.com.

To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.

[jbr...@gmail.com]

Sorry for not reading this entire topic, but what I'd would like to see is that I can use my code first objects in Razor. Something like this v5 feature request: http://issues.umbraco.org/issue/U5-259#comment=67-657.

Jeroen

On Thursday, June 14, 2012 3:59:29 AM UTC-7, Aaron Powell wrote:
> <span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">I’m going to put this up for an open space as well tomorrow and I’ll make sure any notes back in this thread</span></p>
> <span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"> </span></p>
> <span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">Aaron Powell</span><span style="font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">
> MVP - Internet Explorer (Development) | <a href="http://funnelweblog.com/" target="_blank">FunnelWeb Team Member</a></span><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">
>
> </span><span style="font-size:9.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black"><a href="http://apowell.me/" target="_blank">http://apowell.me</a> | <a href="http://twitter.com/slace" target="_blank">http://<WBR>twitter.com/slace</a> | Skype: aaron.l.powell | <a href="http://github.com/aaronpowell/" target="_blank">Github</a> | <a href="http://hg.apwll.me/" target="_blank">BitBucket</a></span><span style="font-size:9.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"> </span></p>
> <span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"> </span></p>
> <b><span lang="EN-US" style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> <a href="mailto:umbra...@googlegroups.com" target="_blank">umbra...@googlegroups.com</a> [mailto:<a href="mailto:umbra...@googlegroups.com" target="_blank">umbraco-dev@<WBR>googlegroups.com</a>] <b>On Behalf Of </b>Richard Terris
> <b>Sent:</b> Thursday, 14 June 2012 11:07 AM
> <b>To:</b> <a href="mailto:umbra...@googlegroups.com" target="_blank">umbra...@googlegroups.com</a>
> <b>Subject:</b> Re: Here&#39;s a wacky thought...</span></p>
>  </p>
> I think if something like this is to be done, it should be the best option rather than the easiest.</p>
>
> &quot;code-first&quot; option to me would be the best and uSiteBuilder have definitely provided us with a great jumping-off point.</p></div>
>
>  </p></div>
>
> Unfortunately I can&#39;t be at CG12 - as the guys all know the trouble I went to but was beaten by the passport office!</p></div>
>
>  </p></div>
>
> But I&#39;d love to be involved in the discussion on this topic in particular.</p></div>

>
> If you get your open space chat up and running, could you let me know the outcome afterwards?
>

> On Thursday, 14 June 2012 09:49:22 UTC+1, Morten Bock Sørensen wrote:</p>
> I too, had really been looking forward to source controllable developer items in V5, so I would very much like to see this sort of thing in V4.</p>
>
>  </p></div>
>
> Yesterday I did a bit of brainstorming on the options there are for this sort of feature, starting from &quot;how would I like to define my doctypes&quot;, and I&#39;d like to create an Open space discussion on this tomorrow at CG12.</p></div>
>
>  </p></div>
>
> The options I&#39;ve considered so far are:</p></div>
>
>  </p></div>
>
> <b>1.: Migration based</b>. A bit like uSiteBuilder, where the doctypes stay in the DB as is, but adds the option to create those using code migrations. for example like:</p></div>
>
>  </p></div>
>
> [Migration(12345)
> public class AddHomeDocType : Migration{</p></div>
>
>    public void Up(){</p></div>
>
>       Doctype.Create(&quot;Home&quot;);</p></div>
>
>       Doctype[&quot;Home&quot;].AddProperty(&quot;<WBR>Name&quot;,&quot;alias&quot;,&quot;datatype alias&quot;, etc...);</p></div>
>
>    }</p></div>
>
> }</p></div>
>
>  </p></div>
>
> <b>2.: Code first. </b>Creating C# classes marked with attributes, or somehow defined by convention. This would be great for .net developers to get the doctypes out of the database, and <i>could</i> co-exist with database or xml defined document types, for those (80%?) who prefer creating the doctypes through the UI. Having the doctypes defined in code, would also offer value to working with the data strongly typed, instead of key/value bags.</p></div>
>
>  </p></div>
>
> [DocType(alias = &quot;MyType&quot;)]</p></div>
>
> public class MyType{</p></div>
>
>  </p></div>
>
>    [Property(DataType = &quot;Number&quot;, alias =&quot;someCount&quot;)] </p></div>
>
>    public int Count {get;set;}</p></div>
>  </p>
>
>    [Property(DataType = &quot;RichText&quot;, alias =&quot;bodytext&quot;)] </p></div>
>
>    public string BodyText {get;set;}</p></div>
>
>  </p></div>
>
>    [Property(DataType = &quot;SomeCustom&quot;, alias =&quot;myCustom&quot;, Converter = typeof(<WBR>MyCustomDatatypeConverter))] </p></div>
>
>    public MyCustomType Custom {get;set;}</p></div>
>  </p>
>
> }</p></div>
>
>  </p></div>
>
> <b>3.: Xml defined.</b> This would probably be the easiest one to start out with, but the biggest issue I have with xml is that it is not discoverable when writing it, in the same way that C# is in visual studio.</p></div>
>
>  </p></div>
>
> While we are talking code first, I think it is important to also remember all other dev type items in umbraco. DataTypeDefinitions, Macros, Masterpages. Being able to define it all from a CF perspective would be the best thing since sliced bread to me :-)</p></div>
> <blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
> <blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
>
>  </p></div></blockquote></div></blockquote></div></div>
> --
> You received this message because you are subscribed to the Google Groups &quot;Umbraco development&quot; group.
> To view this discussion on the web visit <a href="https://groups.google.com/d/msg/umbraco-dev/-/HIp1Spi6Ot8J" target="_blank">https://groups.google.com/d/<WBR>msg/umbraco-dev/-/HIp1Spi6Ot8J</a><WBR>.
> To post to this group, send email to <a href="mailto:umbra...@googlegroups.com" target="_blank">umbra...@googlegroups.com</a>.
> To unsubscribe from this group, send email to <a href="mailto:umbraco-dev...@googlegroups.com" target="_blank">umbraco-dev+unsubscribe@<WBR>googlegroups.com</a>.
> For more options, visit this group at <a href="http://groups.google.com/group/umbraco-dev?hl=en" target="_blank">http://groups.google.com/<WBR>group/umbraco-dev?hl=en</a>.</p></div></div>

[danny...@gmail.com]

I'd love to see DocumentTypes out of the database (or, at least, in files that are two-way synched with the database). I much prefer editing templates, CSHTML scripts etc. in Visual Studio and it also makes deployment so much easier. Imagine if you could just FTP doctypes like you can other files?

Code-first is a nice idea, but I think being able to have strongly-typed properties in Razor would be my first wish.

Also, whilst on the subject of doctypes, I'd love a way of being able to change the doctype of a page once it's been created. I know it has risks, but it is a *real* pain if you need to go back and change the doctype of a page, especially if it has children etc.

[munkimagik]

I'm very keen on getting doc types into source control and any other items that form the structure of an Umbraco site. As it would be great to be able to version control these and spin up blank versions of an Umbraco site without resorting to snapshots of dbs.

However one thing that needs to be considered is that not all people who create doctypes code first will use Visual Studio. Do we really want to make Visual Studio a dependency on creating Umbraco sites? I know you can write c# in a text editor if you want but if the process is optimised for users of Visual Studio then it effectively becomes "the" way to do it.

My preference is for a two way syncing, the LinqToUmbraco code generation was extremely useful, although not 2 way). Could we in some way take the code generation features of LinqToUmbraco and add a regenerate doctypes option. We don't have to do this every time the app pool starts up ala uSiteBuilder. But could have it as a build step or a button in the backend?

It would also be great to be able to change the doctype structure. When you work in an Agile way with Umbraco it can be seriously limiting not to have an easy way to refactor your doctypes. This is a different area entirely I guess.

Tim

[Darren Ferguson]

Tim,

I'm with you 100% - you *must* still be able to create doctypes in the backoffice IMHO.

I'd vote for serialisation to XML somehow as that has the advantage of being "human readable".

Maybe the code first approach just generates the XML that the back office also does?

D

[Simon Dingley]

With you on that idea however as discussed in the session there is still a risk associated with changes made through the UI not being brought back into the dev environment / source control.

Simon

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/gu2-mKRxgJIJ.
To post to this group, send email to umbra...@googlegroups.com.
To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/umbraco-dev?hl=en.

[Morten Christensen]

Tim and Darren,

There was an open space session at codegarden where we (the people attending the session) discussed code-first. The point about creating doc types from the backoffice was raised, and I think the discussions were quite good and I believe there was a general consensus about code-first should go and how it should be limited and at the same time respect the users who are not creating doc types using code. I'm not sure if Aaron already shared the notes from the session, but I'm sure he'll post a link here once its available online.

- Morten Christensen

[Aaron Powell]

Hey all,

 

We had an open space about this yesterday, the minutes are available here: http://umbra.co/minutes2012

 

Aaron Powell
MVP - Internet Explorer (Development) | FunnelWeb Team Member

http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | Github | BitBucket

 

From: umbra...@googlegroups.com [mailto:umbra...@googlegroups.com] On Behalf Of Morten Christensen
Sent: Saturday, 16 June 2012 2:07 PM
To: umbra...@googlegroups.com
Subject: Re: Here's a wacky thought...

 

Tim and Darren,

--

You received this message because you are subscribed to the Google Groups "Umbraco development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/dzJ_B7uPMV8J.

[Darren Ferguson]

Thanks Morten,

I've had a read of the session notes - I feel so strongly about back office doc type creation.

It is often how people get into Umbraco and figure out how it works - that was how I picked it up, open up the back office create doc types and then start dropping fields in to templates.

I didn't have visual studio at that time - I was doing a completely technology agnostic evaluation and Umbraco would've been dropped if I'd needed an IDE to get started.

[Sebastiaan Janssen]

I do hope nobody was suggesting doing away with the inline editors in the backoffice, as Darren said that is one of the big strong points of umbraco. 

I also think we're mixing two subjects here:

1. Doctypes out of the db and source controllable

2. Using doctype properties in a strongly typed way

Number 2 deserves a seperate discussion which I will start right now.

[Darren Ferguson]

Oh - and we also need to remember that doctypes can be included in packages and that should be maintained.

Imagine Umbraco without CWS!

[danny...@gmail.com]

One of the good points of V5 was the multiple doc-type inheritance. Worth thinking about how this could be achieved using file-based system. I can see how you can do it with OOP (inheritance) but how about XML? Can a file-based system maintain integrity (ie. you add a property to a master doctype file then how does it inherit)?

[Michiel van Oosterhout]

On Thursday, June 14, 2012 9:44:31 AM UTC+2, Aaron Powell wrote:

But here’s another way to think about it, could we not make a way to take the document type structure out of the database?

Absolutely, it has no business being in the database in the first place, and it's what makes working on an Umbraco site in a team so difficult. You need to use a shared database (so can't work remote without VPN) and you need to re-apply all changes in the live environment. I tried Courier, but it was not working out as I'd hoped (way too much bugs, and it doesn't fit a simple development style with Subversion).

But it can only work if every definition can be expressed in code, and that is more difficult. Last time I tried USiteBuilder didn't cover data types, so then you're still not closer to a solution for the workflow problems described above. 

[Barry Fogarty]

Really excited there is so much interest here in this topic!

My view is we should extend uSiteBuilder for now - Simon and Morten have worked on this recently to include Datatypes, a sync switch and it also already allows for using doctype objects in a strongly typed way in razor scripts.  Apparently the original devs (Sasa and a colleague from Vega) are back on board too due to v5 getting canned.

Moving doctypes out of the DB in the long run sounds great (as long as the Code First approach is compaitble with a UI-based coctype creation process) but is probably not realistic in the short/medium term.  When that time comes hopefully we can take a lot of learnings from this excersize into that.

[Richard Terris]

Could be the first time I've made a suggestion to "Umbraco" that's been taken semi-seriously :-)

Yay!!

[Darren Ferguson]

Hey Richard - great suggestion - is it possible to rename the topic to something other than "here's a wacky thought" though??

[Gareth Evans]

I personally disagree that it should be completely removed from the database.

The reasoning behind this is that it is the schema or metadata that describes what *is* in the database.

I've often written queries that select data from specific document types, or collect the "tree" of nodes, directly against the database, particularly when I need faster performance.

If we split the schema to an XML file (disk) and keep the data in the database, this severely limits database developer's ability to combine meta with data at a database level.

That said, I agree that we should have some mechanism whereby the document types are also synchronised to a disk file and reapplied potentially on demand (e.g. an executable/class library that applies them) or automatically if the API speed can be improved (this is why uSiteBuilder is slow at starting up)

Gareth 

On Tue, Jun 19, 2012 at 8:31 AM, Darren Ferguson <d...@darren-ferguson.com> wrote:

Hey Richard - great suggestion - is it possible to rename the topic to something other than "here's a wacky thought" thoughts??

On Monday, 18 June 2012 23:58:20 UTC+1, Richard Terris wrote:

Could be the first time I've made a suggestion to "Umbraco" that's been taken semi-seriously :-)

Yay!!

On Monday, 18 June 2012 23:50:04 UTC+1, Barry Fogarty wrote:

Really excited there is so much interest here in this topic!

My view is we should extend uSiteBuilder for now - Simon and Morten have worked on this recently to include Datatypes, a sync switch and it also already allows for using doctype objects in a strongly typed way in razor scripts.  Apparently the original devs (Sasa and a colleague from Vega) are back on board too due to v5 getting canned.

Moving doctypes out of the DB in the long run sounds great (as long as the Code First approach is compaitble with a UI-based coctype creation process) but is probably not realistic in the short/medium term.  When that time comes hopefully we can take a lot of learnings from this excersize into that.

--

You received this message because you are subscribed to the Google Groups "Umbraco development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/drMu3erOQnkJ.

[Richard Terris]

Good thinking - but I can't see any way of renaming the thread.

Does anyone know how?

[Gareth Evans]

Can't rename them because it would break threading for those of us who read by email ;)

--

You received this message because you are subscribed to the Google Groups "Umbraco development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/VkrWEH1jAjwJ.

[tim....@epiphanysolutions.co.uk]

I like the two way sync approach for DocTypes, that way either method is supported. I was thinking the other day about how you could move the DocTypes into config files fairly easily so that you could keep them in source control.

[steentottrup]

I believe if we were to have an XML schema then the XML would be discoverable, though I may be wrong on this front? For example; web.config in visual studio.

Very true, most people don't like XML because they have no idea what should be written where, but a schema can help out with that!

It should be pretty easy to store the document types on the file-system, you can always catch the "save" event. I did a small PoC 2(?) years ago, in the train home from CG10. It had been open session Friday, and we had been talking about deployment, source control and working in teams.

The other way around, when the application starts, you could compare the files on disk with the data in the database, and changes on the file-system could be caught by a file-system watcher I think?

[Simon Dingley]

On 19 June 2012 12:51, steentottrup <priva...@gmail.com> wrote:

It should be pretty easy to store the document types on the file-system, you can always catch the "save" event. I did a small PoC 2(?) years ago, in the train home from CG10. It had been open session Friday, and we had been talking about deployment, source control and working in teams.

The other way around, when the application starts, you could compare the files on disk with the data in the database, and changes on the file-system could be caught by a file-system watcher I think?

Currently uSiteBuilder causes a massive performance hit when the application recycles because of the work involved in synchronising changes to the database, I suspect that this can be optimised to a degree but the impact is significant enough even on relatively small sites and so for larger sites this can be a real issue. This is something that we may be able to look at as part of intended work on developing uSiteBuilder further.

[Dan Diplo]

On Tuesday, 19 June 2012 12:51:53 UTC+1, steentottrup wrote:

The other way around, when the application starts, you could compare the files on disk with the data in the database, and changes on the file-system could be caught by a file-system watcher I think?

There is also the FileSystemWatcher Class in .NET which, "Listens to the file system change notifications and raises events when a directory, or file in a directory, changes". Not sure what the performance penalty is, but I'm pretty sure it hooks into the underlying events that Windows uses all the time so is efficient.

[steentottrup]

That's the one I was thinking about. I've used this before, just not in a web-application.

I'm pretty sure the same is used for keeping an eye on web.config etc.

But.. not sure what impact it has in a web-application, it has to take a thread from somewhere and the IIS only have a limited amount of threads.

 

>Currently uSiteBuilder causes a massive performance hit when the application recycles because of the work involved in synchronising changes to the database

What happens? Are you comparing the XML node by node? Or just doing a checksum or?

[Timothy Beutels]

On Tuesday, 19 June 2012 14:21:30 UTC+2, Simon Dingley wrote:

Currently uSiteBuilder causes a massive performance hit when the application recycles because of the work involved in synchronising changes to the database, I suspect that this can be optimised to a degree but the impact is significant enough even on relatively small sites and so for larger sites this can be a real issue. This is something that we may be able to look at as part of intended work on developing uSiteBuilder further.

For v5 we solved this by using a cmdline app and deserializing on deploy by connecting directly to the db.

The app (de)serializes to/from xml and supports multiple sources (eg. when a doctype was imported from a different source, it wouldn't get serialized again).

We planned to build a 'platform' and split that into multiple nuget packages.

The idea being you would just start a new project, nuget the base packages including base doctypes (eg. SEO, Navigation, ..), add custom functionality but retain the possibility of receiving updates from the base packages.

Since everything is 'deserialized' on deploy, there is zero impact on performance.

I'm not sure if this concept would work for v4 because of it's dependency on a web context.

It actually didn't work on v5 either because of this (I had to write some patches), so maybe we can make it work.

[Morten Bock Sørensen]

I do see your point about the data being described in the database. My question however is if you would not be able to create the same sql statements from your C# code, where you have access to the document types? Would you be doing that sort of queries without being in the context of Umbraco?

I would like to see a separation between the database document (just a key value store), and the editing interface for that (the document type). This would allow for a more flexible way of working with doctypes, where you could easily change a document from one type to another. In that case the doctype could of course be stored anywhere (also in the db), but the reference from document => type would be alias based, and not id based (which I think it is now?).

If this is done, the would however need to be a dashboard of sorts for "content refactoring", so if I rename a property on my doctype, I could move my DB data to that new property.

/Bock

To unsubscribe from this group, send email to umbraco-dev+unsubscribe@googlegroups.com.

[Gunnar Liljas]

I've worked quite a bit with EPiServer (*ducks*), which also stores its type meta data in the database. The open source library called PageTypeBuilder ( http://pagetypebuilder.codeplex.com/ ) is a very popular way of providing statically/strongly typed access to properties, and code based, version controllable type definitions. While EPi's architecture is a bit different from Umbraco's, there are quite a few concepts and ideas that could be brought over. It's very similar to uSiteBuilder's DocumentType stuff, but also tries to deal with migrations etc. And instead of storing state withing the type instances, it just uses the classes to create dynamic proxies which calls the underlying setters and getters. Not necessarily better, but different. Worth a look.

Regarding where to store the metadata, I have no strong objections to either the database or a file/separate files. It's storage. But, I really think that the type storage should be separated from the page data. Constructing inheritance chains, node factories etc. is complex enough as it is. If it's really important to e.g iterate over the available properties of a type, I guess the type system could project materialized definitions (the full inheritance chain) into the database, but that's a different thing,

/G 

[Webmonger]

David Conlisk and myself built something a little like this for defining a node structure in XML so when installing our socialfront package it would create nodes as we defined.

http://code.google.com/p/socialfront/

We've not do much with it since but it is with the help of Rich's uSiteBuilder Export package we could easilt convert it back to code.

+1 for uSiteBuilder - yeah it does some funny stuff but but the version we have turns the sync on start up off.

On Thursday, 14 June 2012 08:50:16 UTC+1, Gareth Evans wrote:

I was musing on something similar regarding for example, an XML structure which could represent a document type with tabs and properties (along with their data type definitions) and then an executable/class library that could be implemented as part of a build rule to apply the changes to a given umbraco instance.

This would be backwards compatible with the existing database-based document type storage and would also allow a code-first approach.

These XML files (i'm not a big fan of XML but it's a good way to store relational data in a text file) could also be code-first generated if required using some form of a fluent API.

While I disagree that uSiteBuilder should be part of the core, Aaron raises a point that it would be nice to source control your document types. 

Taking them out of the database is one way, but I personally feel they should be in the database - since they are the metadata that describes the schema/structure of the data that is stored in the DB.

Of course, uSiteBuilder does offer more than just source control/code first generation of your document types; it also provides strongly typed classes that map to those document types that you can use to query data as well as it's own inheritance structure for masterpages I believe.

In my opinion, This stuff definitely needs to remain external to core

Gareth

On Thu, Jun 14, 2012 at 8:44 AM, Aaron Powell <m...@aaron-powell.com> wrote:

As a developer a code-first approach is a lovely idea but I’ve never used uSiteBuilder so I can’t really comment on whether that’s the best approach or not. But here’s another way to think about it, could we not make a way to take the document type structure out of the database?

I see one of the advantages that uSiteBuilder brings is the ability to source-control your document types, but it’s still some-what of a hack so maybe there’s an even better way.

 

(Just thinking out loud here)

 

Aaron Powell
MVP - Internet Explorer (Development) | FunnelWeb Team Member

http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | Github | BitBucket

 

From: umbra...@googlegroups.com [mailto:umbraco-dev@googlegroups.com] On Behalf Of Richard Terris
Sent: Thursday, 14 June 2012 9:41 AM
To: umbra...@googlegroups.com
Subject: Here's a wacky thought...

 

I saw / heard in the keynote that some of the best packages are to be built into the core, such as uComponents.

I'm not 100% convinced this is a great idea. I personally use uComponents and I think the majority do - but - for the minority of people who don't use it, should it be there taking up room?

 

A wacky idea I have - I use uSiteBuilder for all of my v4 apps, as I enjoy the code first approach, and really hate XSLT.

Razor is great too, but I feel this really should be used in conjunction with MVC.

So, V5 was supposed to deliver a more code first paradigm, why not learn from that and build a uSiteBuilder type library, where document types can be created in code - or add uSiteBuilder as part of the core?

 

Again, as with uComponents, I'm in 2 minds as to whether anything should be made part of the core, or left as optional plugins, but if this is the way we're going to go - let's think about uSiteBuilder too 

--

You received this message because you are subscribed to the Google Groups "Umbraco development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/h--0Wf5VeYQJ.

To post to this group, send email to umbra...@googlegroups.com.
To unsubscribe from this group, send email to umbraco-dev+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/umbraco-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "Umbraco development" group.

[Matthew Bliss]

Here are my suggestions for an approach that I think would cover all the comments made here (and having typed that sentence I'm certain now to be proved wrong!) 

• Leave the existing back office interface to work as currently for creation/editing of doctypes+ in the browser (but have it also update the XML config file mentioned below behind the scenes)
• Add support for strongly typed c# code (in the uSiteBuilder style) which allows for defining doctypes+ in code and then referencing the properties of doctypes+ in masterpages and user controls within Visual Studio.
  
• Have the compiled strongly typed c# code update just the XML config file when first executed following a build rather than update the actual doctypes+ after each build (would overcome the time lag frustration many of us have found with uSiteBuilder).
• Add support for an XML config file that defines all doctypes+, this could be edited in notepad  (for those who want some version control in a file - not DB - but do not want to go the strongly typed / VS route) and perhaps even an addition to the backoffice UI (would allow for copying and pasting / quick editing of similar document types in the UI)
• Add an 'update' or 'sync' button to the back office UI which becomes enabled when the XML config file has been changed (by FTP upload, UI or compiled dll) allowing for controlled updating of the doctypes+ (would overcome the frustration many of us have found with uSiteBuilder, by making it a developer choice when to apply updates)

Where I have typed doctypes+ above I mean ideally a minimum of the following, otherwise full source control is not possible:

• Document Types (obviously)
  
• Templates (as per uSiteBuilder)
• Media Types
• Data Types
• Member Types
• Member Groups

[Shannon Deminick]

Will read more on this thread soon :) but just saw this comment and wanted to note that FileSystemWatcher does not support medium trust... The only way to monitor file change in med trust is to use a Timer which is not all that efficient.

[Shannon Deminick]

Hi all,

I unfortunately didn't attend the open space session and have not actually used uSiteBuilder, but I've read this thread (reasonably quickly) and here are my 2cents coming from an outsiders point of view that has no bias:

• Until v4 database schema is completely overhauled and the new low level business logic layer for it is created (which could take some time), we need to have doc types in the database.
• This doesn't mean that we can't have a sync process (which is what I assume uSiteBuilder does)
• An Xml format to me seams kind of silly since we're all talking about 'code-first' and working in Visual Studio. I would say defining your schema based on a class + attributes would be the way to go. Having support for both would seem kind of difficult and I don't see why we'd need multiple ways to define the same thing. Also, if you are already defining your schema based on a class, then this class is compilable and discoverable so 'could' be used one day for something to do with intellisense.
• The sync process wouldn't have any over head if we do the same thing we do in v5 for detecting plugin changes (which is exactly the process MVC uses to see if it needs to re-create its controller cache):
• We create a txt file containing a hash value of the stuff involved with defining the schema (whether this is class based or file based or whatever), this hash can be quickly generated by doing a quick scan
• At app startup we detect this hash, compare it to the hash stored in the file, if it has change, the sync process begins (which 'should' probably happen on a worker thread IMO)
• If no hash change is detected, nothing occurs

[Randy McCluer]

Big +1 to Shannon's ideas here. Getting some sort of code first in the next couple of releases of 4.x will go a long way to keeping my v5 work from going completely to waste. V5 almost had undocumented support for code first (if you queried with <YourType>) that we made widespread use of.

[Jesper Hauge]

I agree with Shannon that having both XML and classes seems a bit too much, also having a process with hash-checking at app startup seems to be a really smart idea.

Only question: Will this setup allow any kind of editing the doctypes from the Umbraco backend? I'm mostly thinking about adding doctype property descriptions and stuff like that.

Regards

Jesper Hauge

[Aaron Powell]

Minutes from the open space are here: http://umbra.co/minutes2012

 

-          I don’t think we need to take doc types out of the database

-          Exposing doc types through a factory would mean that any implementation could be used

o   Someone can make a code first, someone can make an xml based one

-          This has less breaking changes and IMO requires less work

 

Aaron Powell
MVP - Internet Explorer (Development) | FunnelWeb Team Member

http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | Github | BitBucket

 

--

You received this message because you are subscribed to the Google Groups "Umbraco development" group.
To post to this group, send email to umbra...@googlegroups.com.

To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/VCqudZsFzGwJ.
For more options, visit https://groups.google.com/groups/opt_out.

[Richard Terris]

Would it be insane to suggest having Umbraco "developer's edition"?

I see two main schools of people using Umbraco, those who are happy using the UI and those who work in Visual Studio.

A developers edition would allow things like more code-first approach to doc types

Or would this just be asking for trouble?

To unsubscribe from this group, send email to umbraco-dev+unsubscribe@googlegroups.com.

[Matthew Bliss]

Personally, the code first approach would be my preference (over XML) and having used uSiteBuilder in commercial projects my only frustration was that it does not extend further in the scope of elements that can be configured in code.

However I made the suggestion of an all inclusive approach that would also include XML because I can understand the reasoning of some who have expressed that preference. There are many users of Umbraco who are not back end developers but who would want to reuse doctype structures from project to project and XML fits the front-end developer way of thinking.

Umbraco has always been a CMS that can be used without writing a line of C# code and without ever opening Visual Studio and I believe there is compelling argument that this approach should should remain an option for those who are not back-end developers but are successfully using Umbraco. This would still be the case of course if a uSiteBuilder type interface was built into the core (without an XML option), but the backend UI would have to remain to keep the Umbraco open to all. 

[Morten Christensen]

Shannon,

I think you need to read through the replies a little less quickly :-P

Just to explain - the Xml format came into play when discussion whether to pull Document Types out of the database, so they can be versioned under source control when some kind of Code-First is implemented. If Document Types were to be taken out of the database to allow for them to be put under source control, which I believe would be implicit if Document Types were written in Code, then we need to also accommodate those that only use the backoffice or use a combination of the backoffice and Code-First to create Document Types - hence the idea to have some kind of Xml as a middle ground for creating Document Types through the backoffice or Code and allow them to be put under source control regardless of which approach you use as a developer.

I hope I covered the 3 major points (Code-first, DT in Source Control and Respect backoffice usages) of this discussion to give some insight as to where the Xml idea came from.

- Morten Christensen

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.
To post to this group, send email to umbra...@googlegroups.com.

To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.

[Scott Williams]

Is there any reason the backoffice couldn't just generate code-first classes files rather than xml?

Just to let people think about it, wouldn't code-first prevent multiple inheritance? c# being a single inheritance language after all.

Scott.

- Morten Christensen

To unsubscribe from this group, send email to umbraco-dev+unsubscribe@googlegroups.com.

[Morten Bock Sørensen]

On Tuesday, June 26, 2012 12:15:23 PM UTC+2, Scott Williams wrote:

Is there any reason the backoffice couldn't just generate code-first classes files rather than xml?

I see a big difference between "code-first" and "code-generation". Code-first would definitely be the most useful IMHO.

 

Just to let people think about it, wouldn't code-first prevent multiple inheritance? c# being a single inheritance language after all.

 It should be possible to use interfaces for this?

/Bock

[Barry Fogarty]

It should be possible to generate doctype classes via the UI, if the dev is not working in Visual Studio.  The UI would directly reflect the information stored in the doctype classes (and update them too).  These can be versioned by the dev and reused on other projects, if required.  Adding the XML layer in between just adds complexity IMHO. 

@Shannon your idea of comparing hashes makes a lot of sense for syncing.  But what this process actually do? (assuming the viewpoint that doctypes are removed from the DB).  Quite likely I am overlooking some crucial part, but I would have thought a system that updates the doctype classes directly from the UI would do away with the need to sync altogether (if we disregard different versions of the system  e.g. dev/live).   I guess the one obstacle will be the need to dynamically recompile the doctype classes at runtime, when a doctype is saved via the UI.

[Aaron Powell]

Yes

Because I can I sent this from my iPhone.

To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/11nwsGTbfVwJ.

[Aaron Powell]

Code generation is a horrible thing to write and maintain, this is from the perspective of having written three of them for Umbraco. 

You the have run-time compilation and a bunch of other things to take into account which can give you nightmares :p

Because I can I sent this from my iPhone.

To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/H2XFVhbX-xwJ.

[Gunnar Liljas]

Random thoughts...sorry if I'm restating stuff..

As far as persistence goes, storing the definitions in the database has one major advantage, transaction support. Makes a lot of sense for upgrades and package installations. Maintaining (importing/exporting) to a file based definition (or even better, one file per type) can be done anyway, preferably using the event system. Hmm.., you could even commit directly to source control when something changes (I'm conveniently ignoring the realities of merging..)

File based type definitions code by codegen'd, not necessarily by Umbraco, but by Visual Studio, using T4 templates or a custom file handler.

Coded types could be full citizens of the systems, with their own logic etc, but it's a bit scary to add behavior to data containers. The other option would be to have "dumb" classes which only serve as type definitions. They can still be used in macros etc., by using emitted proxies.

/G 
 

[Shannon Deminick]

So just gonna answer all of the previous comments after my last one, sorry its a bit long :)

• @Morten, I had read all of the details you mentioned so all good there :) 
• As for the XML middle ground is needed to remove DB dependencies here's my thoughts on that:
• The reason people want it out of the db is so that we can version control it, but that's it. Having it as XML poses other problems in that:
• In load balanced environments, when saving a doc type we will have to manually sync all nodes which is not really that nice
• Having the Doc types (actually and all data to do with the CMS) in one centralized place like a db makes far more sense in a load balanced environment and also allows us to cross query effectively with things like SQL, otherwise cross querying becomes painful ... on top of this is what @Gunnar mentioned with transaction support, etc...
• Someone mentioned that not everyone is a c# coder and that Umbraco has always been favorable to non-developers so we should allow XML definitions as well, but this seems strange. As a non-developer, they would use the UI, I really don't think a non-developer is going to want to manually create an XML structure to define a doc type... but i could be wrong there I suppose.
• I don't see a need to pull doc types or anything out of the db if we can version control it and that will come down to a sync process based on a code first approach and vice versa (... explanation below). This makes it really simple to have load balanced environments without trying to sync each node up with events or web services, etc... its all done for us already.
• If we can have all of the types/structures that we want to be version controlled, my vote is still to have this as class based, this includes all structures like macros, doc types, media types, member types, etc... But I know there are some worries about this:
• How does everything sync. I mentioned before how we sync up but what about down? So to answer @Barry's question, we can also create a hash of what is in the database at startup, this should be a quick query or two. If that hash has changed to the hash on the file system, then we need to sync down and do codegen
• Codegen as @Aaron mentioned is not really the funnest thing to do especially when using the .Net codegen libraries but because we know the limited amount of attributes that we would allow I think it would be feasible to codegen the files manually using strings, regex, whatever (which is i think what @Aaron settled on using in Linq2Umbraco). Not saying its a really easy task but I think the pros of codegen could be big (details below)

The end result could be a structured class defining each structure we'd like to have version controlled but more than that we could do this:

• We persist the codegen files (which also must be the convention) to something like: ~/App_Codegen, It cannot be ~/App_Code because anytime you change anything in there the app does a 'full' recycle (see blog post here for details about the different recycles: http://bit.ly/Hc9hef ) which will not be good when people are constantly saving doc types, etc...
• Each time one of these classes is updated/created or the appdomain is started we use the BuildManager to dynamically compile it (this is actually one line of code)
• The types for each structure are then loaded into the CLR which means everything about them is cached, but cached at the most optimized level as a c# type (no XML bloat), this could come in handy for many things. 
• We have real classes for each of these structures which means we 'could' one day do some crazy intellisense stuff with it, who knows
• developers like writing classes, not writing XML, plus if there's an error in the class the compiler will tell you so unlike XML
• These would most likely just be 'dumb' classes as @Gunnar mentioned but perhaps down the track a developer could add some cool custom functionality to this class which I think would be frickin fantastic. Think about things like:
• In your macro definition class, you could implement an interface like IRenderAware which you could implement a couple methods like OnRendering and OnRendered. 
• You could do something similar (if not the same but more) with a doc type

Sorry for the long reply :)

[Dan Diplo]

Shannon's ideas sound fantastic. If they can be pulled off it would make Umbraco mindblowingly amazing! The possibilities are endless! I guess you could use partial classes to extend the generated classes to add extra functionality (outside of the UI), too?

The only thing I'm not sure of is if you go down the road of implementing multiple-inheritance for DocTypes then how will this work as C# classes (given, as has been mentioned, C# doesn't support multiple class inheritance). Morten, I believed, mentioned interfaces (which is the standard C# way), but of course these need to have concrete implementations to actually be useful. Thoughts?

[Scott Williams]

I think I'm struggling a bit with how this could be implemented so that things live in the DB and on disk. 

Just thinking of the situation where one person changes a doctype on disk and someone else changes the doctype on a different instance but pointing at the same DB how are we going to deal with this race condition?

The DB will want to sync the doctype down to disk and the file system want to sync it up at the same time. Who wins?

Scott.

PS I can't decide weather I'm over thinking this or not and it wouldn't be the problem I think it could be.

[Morten Bock Sørensen]

On Wednesday, June 27, 2012 4:46:01 AM UTC+2, Shannon Deminick wrote:

So just gonna answer all of the previous comments after my last one, sorry its a bit long :

I'm wondering if this discussion has turned too much towards implementation details, instead of figuring out what the "story" is for this feature? I propose that before deciding how to build it, we should be sure that we agree what we want it to do, and how we would like to work with it.

I would propose these stories:

1: I am a site builder using the Umbraco backoffice as my primary tool. When i am building a site, I want to be able to set up my document types through the backoffice UI.

2: I am a C# developer using Visual Studio as my primary tool. When I am building an Umbraco site, I want to define my document types in my code, in order to have strongly typed content. When I deploy my code to my umbraco dev/prod website, the types that i have defined will be available in the backoffice.

3: I am a web Developer using Webmatrix as my primary tool. I want to define my document types through the backoffice UI. I also would like to add my document types to my source control system of choice, so I can deploy my changes from development to my production site, without having to redo the changes through the backoffice UI.

I think those cover the three typical developer types using umbraco, and their typical needs. Would you agree with that, or am I missing something here.

Note: I think these stories could be elaborated much more for each type, and also include datatypes/macros etc.

/Bock

[Timothy Beutels]

On Wed, Jun 27, 2012 at 9:47 AM, Dan Diplo <danny...@gmail.com> wrote:

The only thing I'm not sure of is if you go down the road of implementing multiple-inheritance for DocTypes then how will this work as C# classes (given, as has been mentioned, C# doesn't support multiple class inheritance). Morten, I believed, mentioned interfaces (which is the standard C# way), but of course these need to have concrete implementations to actually be useful. Thoughts? 

Maybe we could use Dynamic Proxy/LinFu mixins.

This is just a thought, I'm not sure if this would be practical or even work.

First define the interfaces for each document type as 'partial' building blocks, using IPartialDocType:

• IPartialDocTypeA: IPartialDocType { MyDataTypeDefinition(:IDataTypeDefinition) Property1 }
• IPartialDocTypeB: IPartialDocType { ..; void SomeMethod(); .. }
• IPartialDocTypeC: IPartialDocType { ... }

The partial doctypes can be implemented, but don't have to if they only contain IDataTypeDefinition properties and no methods.

• PartialDocTypeB: IPartialDocTypeB { ...; public void SomeMethod() { .. } .. }

And finally, doctypes are interfaces themselves:

• IDocTypeA: IPartialDocTypeA, IDocType
• IDocTypeB: IPartialDocTypeB, IDocType
• IDocTypeC: IPartialDocTypeA, IPartialDocTypeB, IPartialDocTypeC, IDocType

Everything will be proxied (to allow data injecting/persistence): IPartialDocType or the implementation if available.

The IDocType's will be generated with mixins.

[Gunnar Liljas]

That's very true, Morten, and a good idea. I think we may also add:

4. I am a C# developer using Visual Studio as my primary tool, working closely with designers and editors. When I am building an Umbraco site, I usually want to define my document types in code, but occasionally the designers and editors also add and modify types, and I want our cooperation to be as smooth as possible.

/G

2012/6/27 Morten Bock Sørensen <mor...@mortenbock.dk>

--

You received this message because you are subscribed to the Google Groups "Umbraco development" group.
To post to this group, send email to umbra...@googlegroups.com.

To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/yWnsNsPwW38J.

[Randy McCluer]

I love the idea of code first, but think using in combination with package installation gives much more flexibility & power. I also allows versioning which helps with the whole "have my editors altered my doc types via the UI" issue. In v5, we were using the same techniques as DevDataset. We installed all the types as part of our core package & could have also used the install to check for necessary updates, data translation between versions, etc.

[Shannon Deminick]

I think the stories of @Morten and @Gunnar define all the circumstances, nice one!

I know I've been talking about a lot of potential implementation details but that's because once my brain starts working on a though it doesn't stop :P  The three stories mentioned above I still think can all be solved with a object/class definition < -- > db sync solution and not require anything to do with XML.

@timothy, there's been a chat about multiple inheritance here: https://groups.google.com/forum/#!topic/umbraco-dev/u7-AdjaE97c and I don't think we should think about it as such. Document types in v5 can just 'extend' each other really. If we start thinking about that a doc type can extend another one, we can remove the notion of multiple inheritance.

@scott I'm not really sure this race condition will occur, if so it will be very rare. I would hope that you wouldn't have a developer working on a multiple node load balanced site making changes to document types in the back office whilst another developer is making changes to a document type in code and then redeploying these changes. I guess it could happen though :) In any case, if you deploy the these files via FTP or whatever, then you'll need to restart the AppDomain because we won't be storing these classes in the ~/App_Code folder, we'll be storing them in a custom folder. If this condition happened the sync will only occur when the app is restarting so I suspect that the whatever file got put there latest (either by FTP or by codegen from the back office) prior to app restart will be synced back up.

[jbr...@gmail.com]

The roadmap is available, but I don't think I've seen any code first things yet. Did I miss it or do we might have to wait for v7 for that?

[Richard Terris]

I think it's one that has slipped under the radar.

Might need to kill this thread and start again, or flag it on issue tracker and link to this thread?

On Jul 13, 2012 1:01 PM, <jbr...@gmail.com> wrote:

The roadmap is available, but I don't think I've seen any code first things yet. Did I miss it or do we might have to wait for v7 for that?

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/BqmWT26RIVgJ.

To post to this group, send email to umbra...@googlegroups.com.
To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.

[Matthew Bliss]

Has the discussion here, for code first just become too complex? uSiteBuilder is a one way process of adding types and properties that are absent, no deleting of properties, no reverse syncing etc. and it works well, apart from the fact that it does not cover media types, data types etc. The limitation with uSiteBuilder then is that it is not possible to define an entire site in code only.

Maybe if the initial target of features in code first was prioritised and set lower it might it find it's way into the roadmap?

On Friday, 13 July 2012 13:03:33 UTC+1, Richard Terris wrote:

I think it's one that has slipped under the radar.

Might need to kill this thread and start again, or flag it on issue tracker and link to this thread?

On Jul 13, 2012 1:01 PM, <jbr...@gmail.com> wrote:

The roadmap is available, but I don't think I've seen any code first things yet. Did I miss it or do we might have to wait for v7 for that?

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/BqmWT26RIVgJ.
To post to this group, send email to umbra...@googlegroups.com.

To unsubscribe from this group, send email to umbraco-dev+unsubscribe@googlegroups.com.

[Morten Christensen]

Hi all,

Code first is not part of the road map for a couple of reasons. Firstly, we thought it would make more sense to get new public and low level apis in place before we start working at a code first solution, which would imply that it is scheduled later then the 6.1.0 release. From my point of view anything that is more then 6 months in the future is too far away to schedule anything meaningful. At this point in time we can't say for sure if the focus of the Core team will be UX improvements or if there is room for a code first solution in something like a 7.0.0 release.

The design of the new public api could very well have a huge impact on how code first would be possible to solve, so a base for code first might implicitly be part of the 6.0.0 release.

Code first might also be something that could be contributed by the community if anyone is up for taking on the work or collaborating on it.

All in all I think its too early to say, but its certainly not of the radar ;)

- Morten Christensen

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/WBiWrnXOXp0J.

To post to this group, send email to umbra...@googlegroups.com.

To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.

[mattbrailsford]

I think Matt is right. Code first is a very large feature, so breaking it down should make it more manageable and easier to fit into the roadmap.

Things to bare in mind with the roadmap though, is that not everything will get on to it straight away (especially when it needs a bit of planning first like this one does) and that also, the roadmap is still relatively short at the moment, I mean, its only spanning 7months, so in the grand scheme of things, that's not a huge amount of time.

Also worth bearing in mind, is that yea, while code first might not be on the list, certain things are like getting app trees / apps and macros out of the database, which in itself will make these things definable in code / xml and versionable, which IMO is the main thing. 

So don't be disheartened if you don't see everything on the list to start with. Things take time, and it's better to do logical things together, and many of the things that are planned will be setting the foundation.

[Richard Terris]

I have no problem with this.

If there was anyone more experienced than myself looking to collaborate on it, I would LOVE to get more involved.

As I've said to Niels and Seb - I'd love to contribute more than sarcastic comments :)

Anyone up for it?

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/bsMUZx-ynN8J.

To post to this group, send email to umbra...@googlegroups.com.

To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.

[Matthew Bliss]

Hi Morten & Matt,

Thanks for those explanations. I agree that it is much better to have the right foundation in terms of API before building in a code layer. I for one would much rather wait a little longer to then see a well structured solution that arrives in stages.

[Pete Duncanson]

uSiteBuilder has been mentioned already in this thread, I've not see the uSB boys on this list so not sure if they are monitoring it. They are super busy I know that much. Rather than start a fresh I think it might be worth building on top of the awesome work they have done?

There is a stack of stuff that could still be added to it, might be better than starting a fresh just yet and will give us some time for the new API's to come out etc.

Its on CodePlex and now in Mercurial so checking it out and adding stuff should be a breeze.

Pete

[Richard Terris]

Good point Pete - my initial suggestion was to involve them anyway or at least use what they'd built.

I guess we need to wait for a few new releases first?

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/eUTwN8nshXEJ.

To post to this group, send email to umbra...@googlegroups.com.

To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.

[Barry Fogarty]

Morten Bock and Simon Dingley have been contributing as well - they built custom datatype support into the latest changeset on CodePlex.  I am doing some testing on it at the moment, just as I use it on my side-project.

The source is available on Codeplex at http://usitebuilder.codeplex.com/SourceControl/list/changesets

There was a CG12 follow-up discussion on Our at http://our.umbraco.org/projects/developer-tools/usitebuilder/usitebuilder-support/32573-Follow-up-from-CodeGarden

A good few of us have been using it over the past year so it would be great to see it become the adopted code-first solution eventually.  In the interim it should be much simpler to keep this up to date as elements of Umbraco become definable in code/xml rather than as DB objects. 

[jbr...@gmail.com]

There is some more info about the V6 API(http://our.umbraco.org/contribute/releases/600/rfc/34773-Request-for-Comments-Public-API-IContentService) and development for that has already started. Does anyone know if code first support will be easier with this new API? Is there already some info about what will be part of V7?

[Morten Christensen]

I played around with some code first stuff in the POC of the new API, and I believe it will be fairly straight forward to implement something like uSiteBuilder as part of the Core. But its not yet planned for any future release, so I'd say its still pretty much up for community graps if anyone wants to have a go at creating native code-first.

- Morten