A Java class has properties and methods for manipulating those properties. An ExtJS class has properties, methods and configOptions.
Conceptually, what is the difference between configOptions and properties? Why we need both?
As per my understanding…
configs - are passed in the constructor, which defines behavior of the class, configs should not be changed at run-time because it will not have any effect, suppose you need to specify a title for the panel then you can add a config e.g. { title : 'some title' } that will be used by panel to set title of the panel at render time, but after that, even if you try to change title, you can't alter the property by simply changing that config option.
properties - are used to store information which is useful for that class, this is normally not passed through constructor but should have getter and setter methods, you can change property at run-time (if setter method is defined) and class object should detect this change, there can be read only properties also which are modified by class object only we shouldn't change it all.
More Info
Sencha: Properties vs Configs, in the Ext 4 Documentation
My answer to this question is a little simplistic and idealistic. I'm afraid trying to give a full answer that covers all the subtleties is more likely to add to the confusion rather than clarifying the situation.
Config options are used to configure an object when it is created. Trying to set them as properties on the object after it has been instantiated will often have no effect.
Ext.create('Ext.panel.Panel', {
// config options go here
});
An object will have lots of properties but only the ones listed in the Properties section should be considered public properties. While there's nothing to stop you accessing the private properties you should only do it as a last resort, try to use the documented methods to manipulate them instead where possible.
// rendered is a public property used to indicate whether the panel has been rendered
if (panel.rendered) {
// could just do panel.el but that isn't a public property, so use getEl instead
var el = panel.getEl();
...
}
One reason why the lines get blurred is that objects generally copy their configs onto themselves like this:
Ext.apply(this, config);
This results in all the config options becoming private properties, at least initially. Internally classes can then manipulate those properties as appropriate but externally accessing those properties is a breach of encapsulation and should be avoided.
Related
It's come up several times that I have wanted to access a property of a component which is bound to another property. I've spent days trying to figure out how to do this and failed. Below is a simple example of what I'm trying to do.
TabView {
Component.onCompleted: console.log(style.frameOverlap)
// OR tvStyle.frameOverlap
style: TabViewStyle {
id: tvStyle
frameOverlap: 5
}
}
Nothing like this works. I'm completely baffled about how to access these members either statically or as an instance. Can someone please explain to me whether something like this is possible?
Thanks.
The short answer is that you need to write:
Component.onCompleted: console.log(__styleItem.frameOverlap)
The longer answer is that the 'style' property is a Component. Component is something that remembers a tree of declarations, and can create objects as needed. However, it does not expose that remembered declaration, so when you try to access the frameOverlap property, it's not there.
In theory, you can call style.createObject to create an object, and examine its properties, but that would create another unnecessary instance, so you can look at TabView.qml, notice that it creates an instance already using Loader, and stores that in a property called __styleItem, and so use the code I gave above.
Of course, accessing internal properties is not a particularly good idea, but might be OK in practice. Ideally, one should be able to instantiate TabViewStyle and bind the instance to the style property, with TabView figuring out whether it's Component or object, but I'm not sure it's possible.
Is there a possibility to change the visibility of the setter/getter from an attribute without changing attribute visibility?
e.g in Java I can say:
attribute: private
setter: protected
getter: public
That is very practic if I want to allow only in private scope changes, in protected scope I allow changes via setter (some checks and verifications in there) and in public scope you can only read.
In the classbuilder you can only change all of them together.
You can make the attribute public and change it to read-only in the persistence mapping - this will prevent the setter from being generated. You can change the attribute visibility in the class builder or the persistence mapping, which will affect both the setter and the getter. As far as I know, there are no other ways to affect the visibility. For a greater control, I'd recommend wrapping the persistence class - either in a separate class or by introducing a public getter-only interface whose methods defer to the generated getters.
Yes, it is possible. Just make use of this button.
And then change the visibility
I have a TextBlock and its Text property is bound to a ViewModel property. The binding is Oneway.
When I change the Text property of the Control from the xaml.cs the binding gets broken. If the binding is TwoWay I don't have this problem but the source property is updated too. Is it possible to have OneWay binding and change the target property value without braking the binding?
I suggest a workaround, like setting the Binding to TwoWay and ignore the update in the property. Something like this:
private string textValue;
public string TextValue
{
get { return textValue; }
set
{
:
}
}
Now the Property can no longer be set by the view.
Although no code is provided, this scenario typically occurs when you have bound a control to a view model and at a later stage your logic tries to update the value in the control programmatically.
You should not try to do this, that is define multiple sources of the value for a control. If you bind the control to a property on the view model, then to update the value in the control you should update the field in the view model.
If you were to set the value of a bound control programmatically at runtime so that it no longer matched the bound object value, when some other event causes the control binding to be re-evaluated, the value that you have provided programmatically would be overwritten again, you could easily end up with a scenario where the value you provided programmatically is never visible to the user.
In this scenario you should either:
Add a new property to the view model, bind this value to the control, then your program logic can set this value equal to the original property when the data is loaded, and updated when you need to
Not use bindings at all, always write to the control programatically that way you tightly control when the value is updated.
There is a workaround to this if you absolutely must have one. if you are using compiled bindings (x:Bind), then because the bindings are compiled it is possible to call SetValue on the bound dependency property at runtime and the previously compiled bindings will still be evaluated. However I advise against exploiting this because it makes your code a lot harder to follow and debug, when bindings are used, we tend not to look for code that directly addresses and sets control values.
Those are three concepts on Yii that I really don't get what should we use, on what scenarios?
Can anyone be kind enough to clarify those Yii elements, and on what situation should we use them?
In documentation of CForm one can read the following:
...we can divide a form
in two parts: those that specify each individual form inputs, and
those that decorate the form inputs. A CForm object represents the former part...
...and CActiveForm represents the latter.
In other words, CForm specifies elements of the form but CActiveForm (being a widget) renders it.
Looking at the source code we state that CForm can also render() itself and its rendering relies on and is wrapped by CActiveForm widget by introducing its configuration property activeForm, though rendering input elements and buttons is implemented by its own methods renderElements() and renderButtons() relatively. By default their implementations rely on classes using CHtml's static methods what is exactly the same (or almost exactly the same) what CActiveForm's rendering methods do. Of course, default behavior can be overriden by extending the class.
That's why it's the question of a taste which technique to use: CActiveForm widget alone combining form fields' and buttons' declaration with their representation in a view file by calling convenient (required) methods of CActiveForm instance or CForm class declaring form's input specifications in a separate configuration file and customizing its rendering by pointing at appropriate active form widget and/or by overriding default rendering methods. The latter technique allows to reuse a form in several actions easily and is no more than using form builder.
Check here for live examples of ActiveForm, CForm, et cetera. You can also see the live Model, View & Controller files.
When generating setters and getters in Eclipse one of the options is to use the getters and setters within the class rather than accessing the class members directly. Is this level of class internal encapsulation useful or is it taking a good idea one step too far?
DUPE: Should you use accessor properties from within the class, or just from outside of the class?
I think it's a good idea if you want the potential side-effects to occur - validation, logging etc. (In C# I'd like to be able to declare a variable and property and say that the only access to the variable is through the property.)
Occasionally you may well find you need to set the variable directly precisely because you don't want the side-effects. For instance, you may need to set two variables together, and both the "before" and the "after" states are valid, but setting either property individually would make validation blow up.
It can be useful, if you allow derived classes to re-define your getters. So, using getters even from inside the class will keep your design extensible.
In my opinion this is something that needs to be defined in the coding guidelines.
The short answer is "it depends" :)
Eric Lippert has an excellent article on Automatic vs. Explicit properties that deals with this issue, albeit from a slightly different angle.
Essentially, the question you need to ask is:
"From within the class, [are] the desired semantics of accessing this ... property different from the desired semantics of accessing the property from the outside?"
If the semantics are the same, your class should use its own properties. If the semantics are different, your class will need to directly manipulate the backing fields.
It's useful for example when you have setters which do extra actions like setting a dirty flag or notifying observers.
For getters you may instead of accessing a field compute a value when you change representation.
When you need to extend the getter/setter behavior of a class, it is useful have encapsulated fields (getters/setters instead of direct member access).
Yet in inheritance, it is conceptualy interesting to preserve the inners of your class, if its subclasses shouldn't be aware of its private stuff. So, sometimes the field is private to the implementation of a class, so that even the subclasses aren't aware of it.
I find that I do that at times - specifically when I require, or strongly anticipate that I'll require, some login around getting or setting (and the validation around them) of members.
I find that having private/internal properties does help in these cases.
But I certainly not do it for any memeber.
Latest .NET/VS really helps here as you can declare a property as such:
public string SomeProperty
{
get;
set;
}
and it effectively creates the memebr behind the scene. I know that doesn't help you, but I thought it might be of some interest :-)
If you want for this member to be databindable by either Winform or WPF, I believe that you need to declare it as a property. I'm about 95 percent positive that databinding requires a property (getter/setting syntax). I have a small wpf solution that demonstrates this, but I don't see a way to attach it here.
Here's the code: (built with VS 2008 SP1, targeting .net 3.5 - I used a WPF Project).
There are 2 items in the WPF project, the main window (window1), and the object that we are testing (DataObject)
There is a label on the window that is databound to the Name property in an instance of data object. If you convert the Name property to a field (remove the getter/setter), the databinding will stop working.
Window1.xaml:
<Window x:Class="WpfDatabinding.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Window1" Height="300" Width="300">
<Grid>
<Label Name ="Label1" Height="28" Margin="12,24,37,0" VerticalAlignment="Top" Content="{Binding Name}"></Label>
</Grid>
Window1.xaml.cs
using System;
using System.Windows;
namespace WpfDatabinding
{
/// <summary>
/// Interaction logic for Window1.xaml
/// </summary>
public partial class Window1 : Window
{
private DataObject ADataObject;
public Window1()
{
InitializeComponent();
this.ADataObject = new DataObject();
this.ADataObject.Name = "Hello!";
this.DataContext = this.ADataObject;
}
}
}
namespace WpfDatabinding
{
/// <summary>
/// Interaction logic for Window1.xaml
/// </summary>
public partial class Window1 : Window
{
private DataObject ADataObject;
public Window1()
{
InitializeComponent();
this.ADataObject = new DataObject();
this.ADataObject.Name = "Hello!";
this.DataContext = this.ADataObject;
}
}
}
DataObject.cs:
namespace WpfDatabinding
{
public class DataObject
{
// convert this to a field, and databinding will stop working
public string Name
{
get;
set;
}
}
}