Removing projects from the core

[Aaron Powell]

I'd like to propose the removal of a few projects from the core Umbraco repository as they don't really belong as core features but they could be shipped as packages for the people who want to use them. Also these are features which aren't really that commonly used.

The projects are:

• LINQ to Umbraco
• This is pretty much superseded by the Razor features. This should be split out into a separate project on CodePlex (or any other source hosting) and it can evolve independent from the core product
• IronPython/ IronRuby macros
• These macro engines are already separate downloads for Umbraco so having them in a separate project (and an actual package to install) would seem a good idea

[Richard Terris]

I think something we can learn from MVC is the true separation of concerns and with that in mind could really revisit the core as you said.

As much that can be split into packages the better, making the basic shell of umbraco as simple as possible for those who don't want extra features

[munkimagik]

I second the removal of unnecessary projects from the core.

The more cruft that is in there, the harder it is to understand what is vital and what is effectively legacy.

LINQ to Umbraco and the Iron macros are both excellent candidates for removal.

T

On Wednesday, 13 June 2012 12:37:58 UTC+1, Aaron Powell wrote:

[Morten Christensen]

I agree that these two projects should be removed from the core and moved to separate repos.

I would suggest that they are moved to the Umbraco organization on Github, as we haven't had much success with maintaining Contrib projects on Codeplex. It also seems that barriers to entry are lower on github and projects more discoverable - but thats another discussion ;)

 

- Morten Christensen

[Aaron Powell]

Cool, I’m currently managing the pull requests but after that I could move them over unless someone else wants to take ownership of it

 

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/-/6RxDYoRFD-EJ.
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.

[Gareth Evans]

I agree. 

We could also look at removing the weblog/channels feature - replacing the current channels tab on a user with a new tree in the section.

That's probably a larger change as it requires changes to both the UI and the related code for this feature.

I know a few people use this feature but it is something that could definitely be shipped as a package.

Gareth

[Morten Christensen]

@Aaron I think we should just move the projects to the Umbraco organization on github (github.com/umbraco). I can put you on the list of contributors, so you can create the projects and commit the code if you like.

- Morten Christensen

[Aaron Powell]

Cool my github is aaronpowell

 

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: Thursday, 14 June 2012 12:04 PM
To: umbra...@googlegroups.com
Subject: Re: Removing projects from the core

 

@Aaron I think we should just move the projects to the Umbraco organization on github (github.com/umbraco). I can put you on the list of contributors, so you can create the projects and commit the code if you like.

--

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/-/cA8U7NsnqgkJ.

[Stephen Gay]

Any opinions on removing umbraco.Legacy?
Stephan

[Aaron Powell]

Delete it, it doesn’t compile so it makes no sense to have it any more

 

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 Stephen Gay
Sent: Thursday, 14 June 2012 10:31 PM
To: umbra...@googlegroups.com
Subject: Re: Removing projects from the core

 

Any opinions on removing umbraco.Legacy?
Stephan

--

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/-/AYQdhkWOxIoJ.

[Adam Shallcross]

No necessarily a package, but does anyone actually use the Translation section?

Should this not be removed altogether and added to the package repo if someone wants it?

Also, Canvas editing?  Its very flakey and is a possible candidate for removal, or indeed creating a separate project to make it actually work properly, unless this is to be a part of the UX project.

Cheers

On Friday, June 15, 2012 8:47:32 AM UTC+1, Aaron Powell wrote:

Delete it, it doesn’t compile so it makes no sense to have it any more

 

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 Stephen Gay
Sent: Thursday, 14 June 2012 10:31 PM
To: umbra...@googlegroups.com
Subject: Re: Removing projects from the core

 

Any opinions on removing umbraco.Legacy?
Stephan

--
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/-/AYQdhkWOxIoJ.
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]

We're using the translation feature on a big site with 32 countries. At least we've implemented a solution using it, but I don't know if the editors take advantage of it.

Canvas I have never used, and probably never will.

/Bock

[Dan Diplo]

I'm all for removing Canvas. Nice idea, but I don't know anybody who uses it and, more importantly, codes to ensure it works.

Translation, whilst I admit I've never used it, is I imagine quite minimal in size?

[Chad Rosenthal]

I agree with removing canvas. 

My main reason for thinking this is that to try and speed up the download of pages and in trying to keep my html clean, I remove the <form runat="server"> from my templates. I found that on most of the sites, about 95% of the pages didn't need to do postbacks. Or if they did (aka search box in the top), I could do the same thing through javascript and straight html. Then I'd add the <form runat="server"> to the user controls that actually need it.

More importantly, if I felt there was a business case for it, then I'd change my mind. But so far, I found that clients (over 100 trained so far) have a really easy time understanding the back end as long as the developers set it up in an intuitive way. Not once did I have a client say that XYZ can do it on the page and we'd like that functionality.

As for translations:I think if we could find a way to port the v5 translation API done to v4 that would go a long way to helping v4. Considering that they were saying that you could use it as a standalone product (without the rest of the Umbraco dll's) this should be possible. I do think this needs to stay in the core as (I think) it effects the dictionary and running multiple sites. That being said, the whole send for translation functionality can probably be updated.

-C

[Stephen Gay]

On Wednesday, June 20, 2012 2:41:32 PM UTC+2, Dan Diplo wrote:

I'm all for removing Canvas. Nice idea, but I don't know anybody who uses it and, more importantly, codes to ensure it works.

And,  as far as I can tell, it does not work at all with Razor?

[thomas.k...@gmail.com]

I would like to see the Translation get "fixed" instead. If Umbraco is going to grow and compete this is an area that needs to be in the core. I really hope that the v5 i10n effort can be used in this way.

As for Canvas - to me it is just a "checkmark" when you need to sell the product, none of our customers really use it.

[Barry Fogarty]

I'd like to see it reworked, I often get asked for it 'so the CEO can make updates' - etc.  It would be pretty cool even if only textstring, textbox and RTE fields became editable.  Maybe re-imagined as part of the UX project.

As it is currently it should be removed, or at least changed so it has to be explicitly enabled via config - so we don't have to manually disable the 'Edit in Canvas' context item.

[eat...@gmail.com]

On Wednesday, June 13, 2012 1:37:58 PM UTC+2, Aaron Powell wrote:

> I&#39;d like to propose the removal of a few projects from the core Umbraco repository as they don&#39;t really belong as core features but they could be shipped as packages for the people who want to use them. Also these are features which aren&#39;t really that commonly used.
>
> </div>
> The projects are:</div>
> <ul><li><span style="line-height:normal">LINQ to Umbraco</span></li><ul><li><span style="line-height:normal">This is pretty much superseded by the Razor features. This should be split out into a separate project on CodePlex (or any other source hosting) and it can evolve independent from the core product</span></li></ul><li><span style="line-height:normal">IronPython/ IronRuby macros</span></li><ul><li><span style="line-height:normal">These macro engines are already separate downloads for Umbraco so having them in a separate project (and an actual package to install) would seem a good idea</span></li></ul></ul>
>
> </div></div>

I strongly disagree that linqtoumbraco should be split out. For our firm it is incredibly important, since that is integrated into our workflow. Using dynamicnode through razor is possible, but we only use it for the most trivial of macros. The lack of intellisense and compiler time error checking, plus some other quirks makes it pretty frustrating to work with. I've used dynamicnode for a year now and I still can't use it without having the cheatsheet nearby.

I think linqtoumbraco should instead get more focus, a lot of people are not even aware that it exists, and what you can do with it. Having statically typed classes that represent doctypes is just the best and easiest way of working with the nodes, although it could be even better than it is today.

[Niels Hartvig]

That it's removed doesn't mean you can't use it - even today it's just a separate assembly. But it's slow and un-updated and not the best candidate for future improvement IMHO.

+1 on removal.

[eat...@gmail.com]

On Monday, July 9, 2012 11:03:26 AM UTC+2, Niels Hartvig wrote:
>That it's removed doesn't mean you can't use it - even today it's just a separate assembly. But it's slow and un-updated and not the best candidate for future improvement IMHO.
>
> +1 on removal.
>

Are there any plans for some alternative then, or will the default way of working be dynamicnode in the plan ahead?

I recently introduced a couple of new developers to umbraco here, and showed them both dynamicnode and linqtoumbraco, and they both preferred linqtoumbraco and couldn't understand why anybody would want to use all the dynamics once they really "got" both ways.

I think, for the future, that having a more "code first" approach combined with static typing, as an alternative atleast, is really important. Hopefully this is an area in which our developers could contribute to the project, but we'll see.

[Niels Hartvig]

That *is* the plan moving forward (code first) to - among the good and convenient stuff it brings - solve the issue where people prefer static types.

/n

[Shannon Deminick]

I updated some issue or thread on this comment but can't find where regarding Linq2Umbraco :)

Anyways, the gist is: Linq2Umbraco is slow unfortunately. I say we keep it in the core code but distribute is as a separate download for now. I think it has a good opportunity to be the candidate for codegen and strongly typed objects but we really need to put some code analyzers to work to see where the bottle necks are at. I think if we solved those it could work really well. In fact as a developer, Id MUCH rather work with this than the dynamic implementation which has zero intellisense and never will and is entirely not discoverable. However, before we can push this kind of framework, it needs to be fixed because the performance of it is really aweful. 

So +1 for 'removal' of it from the distribution, but not from the source because we should fix it!

[Aaron Powell]

It can’t be fixed, it can only be rewritten :P

 

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 Shannon Deminick
Sent: Wednesday, 11 July 2012 4:13 PM
To: umbra...@googlegroups.com
Subject: Re: Removing projects from the core

 

I updated some issue or thread on this comment but can't find where regarding Linq2Umbraco :)

 

Anyways, the gist is: Linq2Umbraco is slow unfortunately. I say we keep it in the core code but distribute is as a separate download for now. I think it has a good opportunity to be the candidate for codegen and strongly typed objects but we really need to put some code analyzers to work to see where the bottle necks are at. I think if we solved those it could work really well. In fact as a developer, Id MUCH rather work with this than the dynamic implementation which has zero intellisense and never will and is entirely not discoverable. However, before we can push this kind of framework, it needs to be fixed because the performance of it is really aweful. 

 

So +1 for 'removal' of it from the distribution, but not from the source because we should fix it!

 

 

--

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/-/k9m-L-XfutIJ.

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

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

[Shannon Deminick]

Well there's definitely some stuff that can be salvaged like the codegen of classes. I have no idea how you built it but since it just leverages Linq2Xml surely it should perform ok if we looked at profiling it ? In any case, I'm sure there's code that can be saved moving forward?

[Aaron Powell]

The codegen is a series of strings that get formatted, not exactly brilliant code :P

 

For performance the problem is with the way it’s designed, when you access a collection it parses the entire XML looking for doc types that match the requested type and then it created classes from them. This is inherently slow as it’s a N-depth traversal up-front. After the first ‘.’ you are then working against LINQ to Objects and an in-memory collection so LINQ to Umbraco no longer does anything.

This *can’t* be fixed without a rewrite of the internals and doing that will probably break assumptions about the way it works (you’re only solution would be to turn it into an IQueryable implementation and then break down the expression tree and work against that, which I initially tried to do but there was no documentation at the time on how to build your own IQueryable-based API or working with expression trees).

 

I wouldn’t base any future code-first approach on LINQ to Umbraco.

 

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 Shannon Deminick
Sent: Wednesday, 11 July 2012 4:53 PM
To: umbra...@googlegroups.com
Subject: Re: Removing projects from the core

 

Well there's definitely some stuff that can be salvaged like the codegen of classes. I have no idea how you built it but since it just leverages Linq2Xml surely it should perform ok if we looked at profiling it ? In any case, I'm sure there's code that can be saved moving forward?

--

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