Proposal for Lists (ReadOnly and BusinessList)

Fabio posted on Saturday, September 23, 2006

Hi.
Fact: I like to work with ObjectBinding using BindingSource.

Actual scenario:
Our lists are inherited from BindingList and BindingList have public properties (getter and setter):
AllowNew, AllowEdit, AllowRemove.
Unfortunally BindingList don't use internally it's properties to know if an item can be added, removed or edited.

BusinessListBase and ReadOnlyBindingList are inherited from Core.ExtendedBindingList

ReadOnlyBindingList  have IsReadOnly property with public getter and setter .

Chapter 7 explain how use public static method for authorization in List.

From UI BindingSource have setter only for AllowNew. Navigators and other component use the BindingSource properties to know what are allowed.

Proposal:
To protect the lists and improve the capability to use BindingSource i think we can use the new modifier for the properties AllowNew, AllowEdit, AllowRemove in the Core.ExtendedBindingList.
For example:
        public new bool AllowNew
        {
            get { return base.AllowNew; }
            protected set { base.AllowNew = value;}
        }
Similar for the others properties.

In the Initialize() of our list we can put the code for properlly set the properties AllowNew, AllowEdit, AllowRemove (using Authorization for example).

Using new modifier we can have (on the fly):
        private bool _allowGetItem = true;
        public new T this[int index]
        {
            get
            {
                if (!_allowGetItem)
                    throw new Exception("Can't Getobj");
                return base.Items[index];
            }

            set
            {
                if (!base.AllowEdit)
                    throw new Exception("Can't Setobj");
                base.SetItem(index, value);
            }
        }

Result:
ObjectBindig work better.
ReadOnlyList don't have the "strange" behaviour, at run time, if you set AllowRemove or AllowNew (intent to set AllowNew cause a compile error).
Existing code still working (... so and so... depend on what somebody doing with it's own list... for example for me cause a little problem but ...)
Rocky can add some standard AuthorizationRule for collection too.

Any suggestion ?

Bye.
Fabio

xal replied on Saturday, September 23, 2006

I believe those properties are there so that databound controls know whether to allow those actions or not, but they don't limit what you actually can do with the list in code.
If you need to fully lock the list, you could use the read only list, and set IsReadOnly = true when appropiate. That won't actually stop you from editing the items, just adding / removing. To enable/disable editing of the items, you need to implement something in your actual items.
You could easily do that by creating a class that inherits from businessbase and overriding CanReadProperty and CanWriteProperty and returning false there if IsReadonly = True. Is readonly could be automatically changed in the items when you set IsReadonly= true in the collection.

Both editable and readonly collections inherit from ExtendedBindingList. ExtendedBindingList only adds a RemovingItem event that the standard BindingList doesn't have. (And no, ListChanged can't be used to know which item is being removed.)

The locking of getting items sounds interesting... Where would you use it and why?
Even if something like that doesn't make it into the framework, you could just implement that in your own base class and inherit your BOs from that (I know I'm just stating the obvious).


Andrés

Fabio replied on Sunday, September 24, 2006

Hola Andres... cuando vamos a tomar esa cerveza?
Well... now something serious..

xal:

Even if something like that doesn't make it into the framework, you could just implement that in your own base class and inherit your BOs from that (I know I'm just stating the obvious).

Yes... you know that i have something like 3 class before a concrete BO...

To the point:
Suppose that you are a freelancer and that you don't know who, when and for what somebody use the BO you have implement. Now suppose that I'm a user of your BO.
I had see a class on your assembly and i think i can use that class for something (note: i use PTracker and I know PT is only an example).
Like user of your class i can write this code:
            ProjectTracker.Library.ResourceList rl = ProjectTracker.Library.ResourceList.GetResourceList();
            rl.AllowEdit = true;
            rl.AllowNew = true;
            rl.AllowRemove = true;
            ProjectTracker.Library.ResourceInfo ri = rl.AddNew();
I can copile the code and, at run time, i recive an exception for AddNew.
So, IsReadOnly is protected but the other properties are some confused.... i can't set IsReadOnly but i can set AllowRemove and so on.
For Binding matter I, like user of your class, can set AllowEdit, and so on, and if I use an ObjectBinding navigator the buttons for adding, removing and editing a BO are enabled... this mean that you give me the option to have a "hunts the joker" effect in the front-end.
"hunts the joker" mean that the operator (user of the application) can click the add button and the action send him the message "you can't add!!".
These matters are only for preventing, an improper use of BO, at copile-time.

If you look on chapter 7 you can find
public static bool CanAddObject()
All "public static" method, mean that the user of your class can't use a BindingSource directly but he need prevent "hunts the joker" using specific methods... (you are optimistic, and your user must write some more code). Remember that the AddNew method is public in the BindingList and you can write a BoEditableList overriding AddNewCore and the user (user of your class) can use a BindingSource with Navigator and a grid (for example) without write "special" code to add new item.

xal:

The locking of getting items sounds interesting... Where would you use it and why?

I think that we can prevent something using the new modifier and, the implementation, can enable Rocky ("the Rock") to give us a standard per type rules for collection too (without the necessity to use static methods) for all BOLists.

I would like to have something more, like a IAuthorizationProvider and IBrokenRuleProvider to inject (by config or an IoC FW ;) ) a class to read Authorization and Rules from XML, DB and so on.... but this is another matter (step-by-step).

Bye
Fabio.

P.S. When i have an idea i post it, then the Rock maximize it.