I have been trying to read up on XAML namespace and the use of xlmnr and it has been kind of fuzzy. Either it is too technical, or too simplistic.
My question is a little similar to a question asked here, but my question has more to do with the x part attached to it.
So:
Does the xmlns:x, mean a secondary namespace? i.e. the non-default one? Can I have more than one, and if so what order does the search for the right class go in? This of course assumes that xmlns is the default one.
What about the meaning of and difference of attaching x:name as opposed to name to a tag?
Edit:
Turns out, I think I completely misunderstood it. There is no search hiearchy like C# using statement, or java's import. The xmlns:<name> is more like a way to define a name that you can access a whole tree of classes. The x on the other hand is a conventional way to define XMAL related stuff, but is not a requirement.
Can anyone confirm?
The use of XML namespaces in XAML is necessary because of the underlying XML technology used.
xmlns:x indeed creates a second namespace named x. You can reference attributes, etc from it using x:....
If you had simply use name instead of x:name it would have referenced the default namespace.
You can have as much namespaces declared in your XAML as needed.
The standard x namespace exposes common XAML features - basically a mapping of various things that are implemented in code to give them meaning in the XAML context. In the case of x:Name (not x:name - case matters) the XAML compilation process creates a code-behind field based on the x:Name value. The non-x Name property is an attribute representing the Name property on the WPF FrameworkElement base class, which in most cases works the same way as setting the x:Name, and you can't assign both on the same element. See this question for more info.
To the first part of your question: you can change the x to whatever you want, but shouldn't to maintain consistency, and can also (and will in practice) add other xmlns: declarations, primarily to access additional feature implemented in code. For example, if you work in Blend you will often see a xmlns:d added which contains a bunch of designer specific properties. Any code that you need to reference, like data types, converters, etc. will generally use an xmlns: with clr-namespace and assembly specified to map to the .NET namespace in the code: i.e. xmlns:local="clr-namespace:WpfApplication1"
Related
What does xmlns:dc mean in C# WPF XAML code? Can't find anything on it. Is it directory context? Domain controller?
Sorry for missing context.
I know xmlns is just xaml name space, but i want to know what dc stands for, like what does it mean?
xmlns:dc="clr-namespace:SomethingHere;assembly=SomethingHere"
"dc" is an arbitrary prefix - it is used to reference the namespace as a short hand way, but can be anything you like.
Here's the explanation by the guy who thought it up:
http://www.xml.com/pub/a/1999/01/namespaces.html
dc would just be the namespace of a control you're trying to use, so if you wanted to use a control called ThisControl that was inside the assembly "clr-namespace:SomethingHere;assembly=SomethingHere" you would need to use dc:ThisControl in the xaml.
Working with Cytoscape I have found that xmlns:dc refers to XLM Namespace(xlmns) and the Dublin Core(dc) metadata standard:
https://www.dublincore.org/specifications/dublin-core/dcmi-terms/
When exporting xgmml from cytoscape, part of the xml refers to http://purl.org/dc/elements/1.1/ which redirects to the url above.
Example:
<graph id="78" label="TAPBPL" directed="1" cy:documentVersion="3.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:cy="http://www.cytoscape.org" xmlns="http://www.cs.rpi.edu/XGMML">
Is there a compelling reason to change a generic class name, as "inherited" from a Project Templete? I have this code in my new project, which was created from a (self-created) template:
// REPLACE: Change the name of this class, if desired, to something like "<formName>VisualWebPart"
public partial class VisualWebPart : UserControl
IOW, the comment is mine, but now I wonder: do I really need to change "VisualWebPart" to "DPlatypuswebPart" or so? It won't really make any difference if the Sharepoint site has multiple disparate pages with the same class name, will it? Or will it?
As to the argument for clarity ("which VisualWebPart?!?"), all the coder (me, probably) has to do is to cast his peepers up a few degrees to see the Solution name or the namespace, which are unique.
Note: My preference (if feasible) to just use the same class name in every project derived from the Project Template is for simplicity's sake: so I don't have to do a global search-and-replace, and possibly have some "invisible"/behind-the-scenes files that reference this name not get updated. IOW, I'm shaking in my coding booties that I may open a rat's nest or can of worms by getting too persnickety about names.
OTOH, I'm afraid that not changing the name could end up problematic. Which fear is (most) justified?
A theoretical question now.
As I understand methods are used to implement some sort of behavior and properties are used to retain some state of the object.
I found that XContainer.Nodes() as well as XElement.Attributes() are implemented as methods, not properties. And, IMHO, other methods that should be implemented as properties: XNode.ElementsAfterSelf(), XNode.ElementsBeforeSelf() XNode.NodesAfterSelf() and so forth.
So, everything that returns IEnumerable of something is implemented as method (not property) in Linq to XML.
What is the reason for that? I mean does it serve some specific case or it's just a mistake like for example String.Split() method, that returns char array instead of more expected IEnumerable<char>?
To quote Microsoft "Choosing Between Properties and Methods":
In general, methods represent actions and properties represent data. Properties are meant to be used like fields, meaning that properties should not be computationally complex or produce side effects. When it does not violate the following guidelines, consider using a property, rather than a method, because less experienced developers find properties easier to use.
Consider using a property if the member represents a logical attribute of the type.
For example, BorderStyle is a property because the style of the border is an attribute of a ListView.
Do use a property, rather than a method, if the value of the property is stored in the process memory and the property would just provide access to the value.
You can also read on "Properties vs Methods" here
I like this explanation from that last link
The operation is expensive enough that you want to communicate to the user that they should consider caching the result.
I really don't know much about attributes in general in C#, I've seen them in use in a lot of different ways/places but I don't think I see the importance of some of them. Some definitely have importance because they provide a noticeable function, such as [Serializable]. Yet, others don't seem so important, such as one my coworker uses to mark properties with [DataMember].
I suppose my question is, what are attributes and how are they useful? Is there a way to create my own attributes and how can I tell if fields/methods/classes/whatever have particular attributes or what values are set in those attributes?
what are attributes?
Attributes enable you to embed information about a type or method in the metadata which describes that type or method.
You typically want to use attributes to describe facts about the mechanism of the type or method rather than the meaning of the type or method. For example, suppose you have a type Employee. A fact about the meaning of Employee is that it is a kind of Person, that an Employee has a Manager, and so on. A fact about the mechanism of Employee is that it can be the target of data binding, or it can be serialized to disk, or whatever. An employee cannot be serialized to disk, but the class Employee can be. Attributes let you separate information about the technical details from the semantic model.
Is there a way to create my own attributes?
Yes. Create a class which extends Attribute. By convention you want to name it "FooAttribute". If you do so you can use either the [Foo] syntax or the [FooAttribute] syntax at your discretion.
How can I tell if fields/methods/classes/whatever have particular attributes or what values are set in those attributes?
Use the GetCustomAttributes method on the reflection objects.
Where should I read for more information?
Start with the attributes tutorial:
http://msdn.microsoft.com/en-us/library/aa288454(VS.71).aspx
And then read all of chapter 17 of the C# specification.
Attributes are a means by which you can associate metadata with types in .NET. This allows you to check for a type and get information about it that's separate from the "runtime" information of the type.
This can be very useful. You mentioned [Serializable], but other simple examples include many of the System.ComponentModel types, such as Description, which is used by the property grid to "describe" properties when you work with them in the designer. Since the "description" of a property isn't really related to the behavior of the type in a program (at runtime), it doesn't belong in the class. However, it's very handy when you go to edit a control in a visual designer, for example, to see a description (or category, etc) of a property. Attributes are the means by which this is handled.
I think the answer to the following question will provide you some insight to your questions.
How do attribute classes work?
Here is a repost of the answer I provided.
Attributes are essentially meta data that can be attached to various pieces of your code. This meta data can then be interogate and affect the behaviour of certain opperations.
Attributes can be applied to almost every aspect of your code. For example, attributes can be associated at the Assembly level, like the AssemblyVersion and AssemblyFileVersion attributes, which govern the version numbers associated with the assembly.
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
Then the Serializable attribute for example can be applied to a type declaration to flag the type as supporting serialization. In fact this attribute has special meaning within the CLR and is actually stored as a special directive directly on the type in the IL, this is optimized to be stored as a bit flag which can be processed much more efficiently, there are a few attributes on this nature, which are known as pseudo custom attributes.
Still other attributes can be applied to methods, properties, fields, enums, return values etc. You can get an idea of the possible targets an attribute can be applied to by looking at this link
http://msdn.microsoft.com/en-us/library/system.attributetargets(VS.90).aspx
Further to this, you can define your own custom attributes which can then be applied to the applicable targets that your attributes are intended for. Then at runtime your code could reflect on the values contained in the custom attributes and take appropriate actions.
For a rather naive example, and this is just for the sake of example :)
You might want to write a persistence engine that will automatically map Classes to tables in your database and map the properties of the Class to table columns. You could start with defining two custom attributes
TableMappingAttribute
ColumnMappingAttribute
Which you can then apply to your classes, as an example we have a Person class
[TableMapping("People")]
public class Person
{
[ColumnMapping("fname")]
public string FirstName {get; set;}
[ColumnMapping("lname")]
public string LastName {get; set;}
}
When this compiles, other than the fact that the compiler emits the additional meta data defined by the custom attributes, little else is impacted. However you can now write a PersistanceManager that can dynamically inspect the attributes of an instance of the Person class and insert the data into the People table, mapping the data in the FirstName property to the fname column and the LastName property to the lname column.
As to your question regarding the instances of the attributes, the instance of the attribute is not created for each instance of your Class. All instances of People will share the same instance of the TableMappingAttribute and ColumnMappingAttributes. In fact, the attribute instances are only created when you actually query for the attributes the first time.
C# provides a mechanism for defining declarative tags, called attributes, which you can place on certain entities in your source code to specify additional information. The information that attributes contain can be retrieved at run time through reflection. You can use predefined attributes or you can define your own custom attributes.
http://msdn.microsoft.com/en-us/library/aa288059%28v=VS.71%29.aspx
I have seen the following code:
[DefaultValue(100)]
[Description("Some descriptive field here")]
public int MyProperty{...}
The functionality from the above snippit seems clear enough, I have no idea as to how I can use it to do useful things. Im not even sure as to what name to give it!
Does anyone know where I can find more information/a tutorial on these property attributes?
I would be also interested in any novel / useful tasks this feature can do.
The functionality from the above
snippit seems clear enough,
Maybe not, as many people think that [DefaultValue()] sets the value of the property. Actually, all it does to tell some visual designer (e.g. Visual Studio), what the code is going to set the default value to. That way it knows to bold the value in the Property Window if it's set to something else.
People have already covered the UI aspect - attributes have other uses, though... for example, they are used extensively in most serialization frameworks.
Some attributes are given special treatment by the compiler - for example, [PrincipalPermission(...)] adds declarative security to a method, allowing you to (automatically) check that the user has suitable access.
To add your own special handling, you can use PostSharp; there are many great examples of using PostSharp to do AOP things, like logging - or just code simplification, such as with automatic INotifyPropertyChanged implementation.
They are called Attributes, there is a lot of information in msdn, e.g. http://msdn.microsoft.com/en-us/library/z0w1kczw.aspx
In general they don't "do" anything on their own, they are used by some other code that will use your class. XmlSerialization is a good example: XmlSerializer (provided by Microsoft as part of the framework) can almost any class (there are a number of requirements on the class though) - it uses reflection to see what data is contained in the class. You can use attributes (defined together with XmlSerializer) to change the way XmlSerializer will serialize your class (e.g. tell it to save the data as attribute instead of an element).
The ones in your example is used by the visual designer (i.e. MS Expression Blend and Visual Studio designer) to give hints in the designer UI.
Note that they are metadata and will not affect the property logic. Setting DefaultValue for instance will not set the property to that value by default, you have to do that manually.
If you for some reason want to access these attributes, you would have to use reflection.
See MSDN for more information about designer attributes.
We use it to define which graphical designer should be loaded to configure
an instance of a specific type.
That is to say, we have a kind of workflow designer which loads all possible command
types from an assembly. These command types have properties that need to be configured,
so every command type has the need for a different designer (usercontrol).
For example, consider the following command type (called a composite in our solution)
[CompositeMetaData("Delay","Sets the delay between commands",1)]
[CompositeDesigner(typeof(DelayCompositeDesigner))]
public class DelayComposite : CompositeBase
{
// code here
}
This is information is used in two places
1) When the designer creates a list of commands, it uses the CompositeMetaData
to display more information about the command.
2) When the user adds a command to the designer and the designer creates
an instance of that class, it looks at the CompositeDesigner property,
creates a new instance of the specified type (usercontrol) and adds it
to the visual designer.
Consider the following code, we use to load the commands into our "toolbar":
foreach (Type t in assembly.GetExportedTypes())
{
Console.WriteLine(t.Name);
if (t.Name.EndsWith("Composite"))
{
var attributes = t.GetCustomAttributes(false);
ToolboxListItem item = new ToolboxListItem();
CompositeMetaDataAttribute meta = (CompositeMetaDataAttribute)attributes
.Where(a => a.GetType() == typeof(Vialis.LightLink.Attributes.CompositeMetaDataAttribute)).First();
item.Name = meta.DisplayName;
item.Description = meta.Description;
item.Length = meta.Length;
item.CompositType = t;
this.lstCommands.Items.Add(item);
}
}
As you can see, for every type in the assembly of which the name ends with "Composite",
we get the custom attributes and use that information to populate our ToolboxListItem instance.
As for loading the designer, the attribute is retreived like this:
var designerAttribute = (CompositeDesignerAttribute)item.CompositType.GetCustomAttributes(false)
.Where(a => a.GetType() == typeof(CompositeDesignerAttribute)).FirstOrDefault();
This is just one example of how you might be able to use custom attributes,
I hope this gives you a place to start.
These attributes customize the design time experience.
http://msdn.microsoft.com/en-us/library/a19191fh.aspx