In mvvm-light, it comes with two property-creation snippets: mvvminpc to create a 'normal' property; and mvvmpropa to create an attached property (aka dependency property). I just want to know if there is any guidance on what to take into consideration when choosing which one to use?
I've been also searching for a while on these property topics for MVVM light. Below is my understanding of the property snippets provided in MVVM light. There aren't really any cases where you would use one over the other because they are for different purposes.
Bindable Property - Bindable properties are created in your ViewModels to expose data which your view will display.
Examples include: Displaying a collection of Employees, or the selected employee information.
Dependency Property - View specific when it comes to the code snippet. These properties can be set to a constant value or use data binding for changes depending on the viewmodel data.
Examples include: A textblock control's "Text" property is a dependency property. The "Height" and "Width" properties are also dependency properties.
Attach Property - Also used more specifically for user controls. This property is added to a parent control. Child controls use these properties to behave a certain way within the parent control.
Example includes: a Dockpanel has a "Dock" (Attached Property Name) that isn't used by the Dockpanel itself. It is used by the children contained inside of it, the children will now be able to set the property: DockPanel.Dock="Top".
<DockPanel>
<TextBlock Text="{Binding EmployeeName}" DockPanel.Dock="Top" />
<Button Content="Click Here" DockPanel.Dock="Bottom" />
</DockPanel>
In the example code above:
The Bindable Property is the EmployeeName, which would be a public property in the viewmodel code.
The Dependency Property is the Text="" property of the textblock and the Content="" property of the button.
The Attach Property is the DockPanel.Dock property used in the Textblock and button, but is actually exposed by the Dockpanel itself. Notice that the Dockpanel doesn't contain any of the .Dock code, only the children do.
Dependency properties are recommended when you create UI components (controls, etc.): they have better time performances for binding.
Normal properties are used if you have business object or if you dont have/create UI controls.
Related
As my title says, I have a set property crash problem.
Here's the scenario:
I have created a simple custom ASP.Net server control that generates some text.
I wanted to give design-time property for that text so its style can be accessed by developers from the properties window.
All the properties in the properties window are working except the ones with the type System.Web.UI.WebControls.Style that I have created.
Here is my property:
[Bindable(true)]
[Category("Appearance")]
[Description("The style for the header")]
[Localizable(true)]
public Style HeaderTextStyle
{
get
{
Style s = (Style)(ViewState["HeaderTextStyle"] == null ? Styles.defaultHeaderStyle : ViewState["HeaderTextStyle"]);
return s;
}
set
{
ViewState["HeaderTextStyle"] = value;
}
}
Oh and Styles.defaultHeaderStyle is just a property from an internal class that returns a new Style.
Let me point that the hanging/crashing occurs only when I CHANGE the property, so it cannot be from the getter.
I won't paste my render control because the error occurs even when I'm not rendering anything.
What is it that causes this?
Thank you.
I found the answer to my problem.
You see, the Style class is a property that has sub-properties and it is called a complex property. Complex properties ( a property that has subproperties) need custom state management to use view state. The Style class need design-time attributes to enable persistence within the control's tags. So what I wrote in my original post will not work.
For complete explanation visit: Server Control Properties Example from MSDN
I managed to implement it using that example. I hope this will be useful to others out there.
I am having trouble wrapping my head around the spark skin class in relation to it's host component. Basically, from what I've seen with most every skin that comes in the Flex 4 framework they don't directly expose the properties that are dynamically being set in the host component. Instead, they define states that get exposed to the skin class to define when a component should look different. This is all fine and dandy when you have a very simple component with a standard set of states, but when you have twenty different properties (hypothetically) to set in your host component that should change how the skin looks it could get very complicated very fast.
The way that I've seen that they have used to get around this is by overriding the commitproperties and invalidate functions in the skin class, grabbing the values for the properties they want from there, and then setting them to a locally instantiated variable inside the skin class. This is fine, but I feel like that is just a patch workaround to it which makes things a lot more complicated than it needs to be.
HERE'S MY QUESTION:
Is there any way to directly expose a bindable property from the host component class so when you define your skin class it is directly ready to be read from? Let's say you have custom button with a boolean property of 'selected'. In the skin class, you want to add in a get and set function for the property 'selected' so you can perform some action upon your skin whenever it's set. How do you tell the skin class that this is an available property for you to work with from the host component?
This question exists at a very theoretical level. I'm not clear what you're trying to accomplish, nor what sort of properties you're setting on your component class. I suspect, there is an architecture problem if you have 20 properties and each one needs to correlate to a different skin states somehow.
However, I can try to answer your specific questions.
Is there any way to directly expose a bindable property from the
host component class so when you define your skin class it is directly
ready to be read from?
When building Flex MobileSkins, they recommend creating a property named hostComponent which gives the skin class a reference to the component class. MXML skins already have a similar property. If you're using a custom skin, this property is created automatically using the HostComponent metadata. Therefore from the skin class you can access properties on the component class using the hostComponent property.
Let's say you have custom button with a boolean property of
'selected'. In the skin class, you want to add in a get and set
function for the property 'selected' so you can perform some action
upon your skin whenever it's set.
I'm not envisioning the situation where you would want to do this. Generally you would not define any properties on the skin class which you intend to explicitly change on the instance of the skin class.
You could dispatch an event from the component class when the property changes. [This is very common]. Then listen for that event in the skin class using the hostComponent property and change things there.
There is also a way to access the skin class instance from within the component class. So you could change properties directly on the skin class using the skin property.
I wouldn't follow either approach without thinking it through. Ideally the component class and skin class should be encapsulated from each other; and each approach would provide dependencies.
When you affect a skin to a component, you can use metatags to store a reference to the skin part you actually use :
[SkinPart(required="false")]
public var resizeHandle:UIComponent;
Then, when overriding the partAdded and partRemoved methods, you will be able to set or unset whatever you want in these skin parts, from the basic properties to event listeners.
override protected function partAdded( partName:String, instance:Object):void
{
super.partAdded(partName, instance);
if (instance == resizeHandle) {
resizeHandle.addEventListener(MouseEvent.MOUSE_DOWN, resizeHandle_mouseDownHandler);
}
}
override protected function partRemoved(partName:String, instance:Object):void
{
if (instance == resizeHandle) {
resizeHandle.removeEventListener(MouseEvent.MOUSE_DOWN, esizeHandle_mouseDownHandler);
}
super.partRemoved(partName, instance);
}
Furthermore, since you have stored a reference to your skin parts, you can still access it whenever you want in your host component and update it. Am I clear ? :-)
I want to create a user control, which can be bound to some data given from outside the control (requirement A), and some XAML properties must be bound to properties of the control itself (requirement B).
Let's say that I have a data class named StudentData and a control named StudentControl. I'm using this control inside a DataGrid. I put the StudentControl in the grid with a DataGridTemplateColumn. I somehow bind the StudentData in the current cell to the control. This is requirement A. This StudentControl wants to specify if some of the controls inside it are editable or not. The best way to do this is exposing a property, like StudentControl.AreSomeControlsEditable. Then I can bind the IsEnabled property of those controls to this property. This is requirement B.
Here's my first idea. I bind the current StudentData to a DP of StudentControl, then, inside the StudentControl, I change the data context to the control itself:
<UserControl DataContext="{Binding RelativeSource={RelativeSource Self}}">
<TextBox
Content="{Binding Path=ExposedStudentData.Field1}" *reqA*
IsEnabled="{Binding Path=OtherProperty1}" /> *reqB*
</UserControl>
This way, I figured, the StudentControl gets the StudentData from outside, exposes this same StudentData and the other new properties (so the data and other properties are in one place now, not two), and then I can bind to these exposed properties in XAML (reqA+reqB are fulfilled at the same time). Except this doesn't work because of this bug. Basically, if I set the DataContext of the control to itself, then it gets set before the outer binding is applied. So if my binding path inside the cell is X, and then the data context changes, the binding engine will look for X in the new, self data context, and not the outer, grid data context.
Here's my second idea. I bind the current StudentData to the DataContext or a DP of the StudentControl. Then, to access other exposed properties of the StudentControl, I give a name to the UserControl and use ElementName binding:
<UserControl x:Name="self">
<TextBox
Content="{Binding Path=Field1}" *reqA*
IsEnabled="{Binding ElementName=self, Path=OtherProperty1" /> *reqB*
</UserControl>
This way, I figured, the current data context is the StudentData, and it's not changed, and I can bind to that with a simple path (reqA), and I can bind to the other exposed properties with the ElementName stuff (reqB). It works in basic scenarios, but not in a DataGrid, because of this bug. I'm guessing the problem arises when there are multiple controls with the same name in the visual tree.
I'm really starting to hate Silverlight, I started using it a month ago, and I already reported 9 bugs. Whenever I try to achive something other than a simple hello world application or something that Microsoft and everyone else seems to be using Silverlight for, I encounter a new bug. So what now, how would you bind to a data class given from outside the control and some other properties exposed by the control at the same time? Without, of course, setting up the bindings from code (which I'm doing now, but it's a nightmare with ListBoxes and DataTemplates) or not using binding at all.
I think your problem is with the DataContext and how it is inherited, as well as namescopes.
For the first, you should know that if a control doesn't specify its own DataContext, it will inherit that of its parent, and for ItemsControl derived controls, each Item will have its DataContext set to one of the data items in the ItemsSource collection.
For your second problem, if you're inside a DataTemplate, you're in a different namescope than outside of it. You can't access controls "by name" outside of a DataTemplate. What you can do here (for Silverlight 4 and below) is to traverse the Visual Tree yourself and look for the control you want. This, however, is going to become much easier and less painful with some new features in SL5, specifically the "FindAncestor" feature (which already exist in WPF).
Here's an article on MSDN about Namescopes in Silverlight. And here's another one about DataBinding which mentions how DataContext is inherited.
To achieve what you're looking for, I think this blog post should help you. It shows you how to implement "RelativeSource Binding with FindAncestor"-like behavior in Silverlight.
Hope this helps :)
On another forum, they told me to use MVVM. As it turns out, it can make my first idea a little better. Instead of binding my StudentControl to a StudentData, and then exposing this data and other properties, I should create a viewmodel, let's say StudentControlData, which contains a StudentData and additional properties required by the control. If I bind my control to this, then in the inherited data context of the control, I have access to all properties that I need. Now the only problem left is that inside a ListBox in my StudentControl, I lose this data context.
Lately i discovered MATE (for Flex development) and was wondering: how do i bind a property in a view (actually a navigatorcontent component) to another property in a class so that they stay in synchronization (meaning that whenever the property in the class changes the property in the view also changes).
So if we have a view called Target.mxml and a property targertProp how do we bind it to the class called SourceClass with property SourceProp?
Thanks in advance
For future use:
fiction has answered the question correctly.
Actually it should have been formulated this way!
<Injectors target="{Target}">
<PropertyInjector targetKey="targertProp"
source="{SourceClass}"
sourceKey="SourceProp"/>
</Injectors>
Of course SourceProp must be [Bindable]
Read my article below
http://vinothbabu.com/2010/03/21/introduction-to-mate-framework/
on how you use the Injectors Tag to play with. Its a very simple example. Let me if you were looking for something else.
In WPF it's possible to set a property of a custom control by either an attribute or by an inner property. Like this:
<custom:UserControl1 Text="My text here..."></custom:UserControl1>
Equals:
<custom:UserControl1>
<custom:UserControl1.Text>
My text here...
</custom:UserControl1.Text>
</custom:UserControl1>
In ASP.net the type of custom control property can be defined by the PersistenceMode attribute. At the moment I can only find a way to define a property either as an attribute or as an inner property.
Is there a possible way to set the custom control property like WPF on either way?
Thanks!
For Text, setting:
[
PersistenceMode(PersistenceMode.InnerProperty),
DesignerSerializationVisibility(DesignerSerializationVisibility.Content)
]
public string Text
For the property you want to appear that way will allow you do to the second option; however, alternatively, you probably also could specify it inline. If that's the only property that you use as a child element, you can also specify PersistenceMode.InnerDefaultProperty or EncodedInnerDefaultProperty (as it would be the default), that latter of which would encode it.
Realistically, you can't do everything like you can in WPF in ASP.NET; it's just not that fully supported in the designer as that wasn't it's intent. But primitive types you can define as an inner property with a content design serialization, and it should allow you to do both options.
HTH.