https://groups.google.com/forum/#!topic/umbraco-dev/DcSsIzALDYs

In bold..

Do’s:

• Discuss how Umbraco is structured (what projects exist, their purposes, etc)
• Discuss the code (why did you do it that way, I think I see a bug in the code, etc)
• Discuss why a feature exists
• Discuss design decisions (why isn’t that extensible, why is that extensible, why isn’t that method public)
• Search the list first to ensure you're not starting a duplicate thread
• If a discussion spawns a new idea spawn a new thread so that the topic doesn't get muddled

Don’t (this will see a thread locked):

• Ask about a problem implementing Umbraco, that’s what our.umbraco is for
• Raise bugs, use issues.umbraco
• Raise feature requests, use issues.umbraco
• Start off-topic discussions not related to Umbraco
• Perform marketing/ self-promotion

Really don’t (this will see you banned):

• Spam
• Abuse, flame or insult other members
• Continuously violate the "don'ts"
• Be generally disruptive

Sebastiaan, please do not suspend me from the forum for this, but I don't think I made it clear that the problem was an example that brought attention to a design issue. What the example seems to give attention to is the fact that nobody in the entire universe will ever be able to use an Angular service as a .NET property. Your comment still does not explain how my topic was unrelated to the design of Umbraco.

I actually did look at the rules before posting both items. You will also notice this in the DOs:

• Discuss how Umbraco is structured (what projects exist, their purposes, etc)
• Discuss the code (why did you do it that way, I think I see a bug in the code, etc)
• Discuss why a feature exists
• Discuss design decisions (why isnt that extensible, why is that extensible, why isnt that method public)
• Search the list first to ensure you're not starting a duplicate thread
• If a discussion spawns a new idea spawn a new thread so that the topic doesn't get muddled

You are mentioning subjects that relate directly to the source of Umbraco, not your usage of that source code. I'm assuming you did not build Umbraco from source and altered it to do what you want it to do. If so: don't do that, you should use the extension points.

I AM using the extension points.

That's precisely the problem: It is impossible to use Umbraco in the desired way because the source code will not allow it. This is the problem, and that is why I feel that it is justified to discuss this in the developer group.

Indeed, that is precisely the problem. The Google group is there to talk about Umbraco's source, not about using it's extension points.

But we're talking about an issue with a huge problem scope. What's you're telling me is that it is impossible for any Umbraco node with a custom data type to be treated like a delegate (when that object derives its value from an Angular service provided as a package). Is this true?

I am building from your Nuget package in VS.

No idea, I have not actually looked into your original problem, I have just identified that it's about your usage of the extension points which is not a subject for the mailing list. Hopefully the community will have some insights into your problems with using Umbraco.

That is why you are assuming that it is a problem independent from the source code. Ultimately, every single Umbraco node would be affected because it applies to how the Umbraco node tree's properties are recognized in your entire namespace.

So, can the node properties represent actions or not?

If not, then how can I build Umbraco from source in a way that will allow me to use the node properties as delegate objects in .NET?

I just want to mention that Sebastiaan and I discussed this matter, both apologized to the other, and Sebastiaan responded with this item in the discussion group: How not to react AKA #h5is.

is working on a reply...