Skip to main content
Home Forums Silverlight Programming Silverlight Controls and Silverlight Toolkit Why no PART_ convention for TemplateElement in Silverlight?
3 replies. Latest Post by anders.bursjoo on November 25, 2008.
(0)
anders.b...
Member
18 points
6 Posts
11-24-2008 7:00 AM |
In WPF there is a convention for TemplateElements in controls that distinguishes controls that must exist in a template from other controls. This means that if I edit a control template I know that all elements named PART_* must be in the template and all other parts I can remove or do whatever I like to.
Whene I looked in Silverlight Toolkit and the shipped controls there are no such standard, why? How should the user know which controls that must be in the template? I think it is sad that the framework doesn't look the same in all parts (yes I know that the Silverlight Toolkit is not in the framework, but realize that it will be a template and a teacher for many control developers). Is there a reason?
bryant
Star
9897 points
1,629 Posts
11-24-2008 10:46 AM |
Take a look at the TemplatePartAttribute. It allows you to specify the parts that can be templated.
JustinAngel
Contributor
4415 points
596 Posts
11-24-2008 2:41 PM |
Hi Anders,
Thanks for commenting on this issue.
Right now, the "PART_" convention does not exist in Silverlight and there are no plans (that i'm aware of) to bring it in.
The problem you're describing (read: "if I editor a control template") is more of a design-time tooling problem, than it is a runtime problem.The convention you're mentioning is a very low-tech way of saying "this is a template part". But in an Utopian Silverlight/WPF world, the tooling (Blend & Visual Studio) would be able to support those concepts out of the box. Luckily, There are some short terms plans on the tooling side to improve the templatepart experience.
In the meanwhile, feel free to open up a codeplex issue on this issue and suggest this change at: http://www.codeplex.com/Silverlight/WorkItem/Create.aspx If this issue gets enough community traction, we might follow up on it.
However, just to be clear, there is a major disadvantage at this point from doing that.Adding "PART_" to all template parts has some short term negative outcomes for all silverlight apps out there today. (because all tcustom emplates would just break)
11-25-2008 3:01 AM |
First: Yes I know about the TemplatePart attribute and I know that the functionality does not change because of the naming convention. I think that the problem is that the tools does not use this information today. As you wrote this will soon be implemented in Visual Studio and Blend but there are a lot of other tools. This brings us to my second opinion.
Second: I think this is a usability and design issue. If you read Framework Design Guidelines (K. Cwalina, B. Abrams) they have an important point when they say that the .NET Framework should "look the same" wherever you are. Therefore I think its a bad thing that Silverlight and WPF differs. A developer should recognize himself/herself when adopting a new area within the framework, and the framework code should be clear and readable. This is not a big issue and maybe I'm whining a little bit too much about this, but I think it is important that we create conventions for markup (XAML) in the same way that we use camelCasing and PascalCasing in e.g. C#. I have seen some unclear naming within the framework (in XAML), are there any conventions for naming and so on and do people use them?
Thanks for your replies guys! I did get an answer that made me realize that there will probably not be a PART_ in Silverlight but I also got a chance to say that I think it is sad that Silverlight/WPF differs and I think it is important to create conventions for writing XAML. This is not about the functionality of the code you write, it is about the usability and the experience for the next developer that will read and try to understand your code.