Vibrant discussion about CSLA .NET and using the framework to build great business applications.
Hello, I see how the friendlyName can be obtained thru the static method in RuleArgs, and can be accessed on the validator method to assign the Description property on the "validator" method;
I would benefit if the friendlyName property could also be obtained at the time of displaying the BrokenRuleCollection on an BO, for instance dataBind-ing this collection to a dataGridView in UI.
my question is if it would be a good idea to implement the FriendlyName in the BrokenRule class and somehow pass it along from the RuleArgs class..., any suggestions are appreciated !!!
saludos!
Rocky
thanks Rocky !!
ReadOnlyChild: Hello, I see how the friendlyName can be obtained thru the static method in RuleArgs, and can be accessed on the validator method to assign the Description property on the "validator" method; I would benefit if the friendlyName property could also be obtained at the time of displaying the BrokenRuleCollection on an BO, for instance dataBind-ing this collection to a dataGridView in UI. my question is if it would be a good idea to implement the FriendlyName in the BrokenRule class and somehow pass it along from the RuleArgs class..., any suggestions are appreciated !!! saludos!
Hi Rocky,
Working on CslaActionExtender I have the same requisite: display the OriginPropertyFriendlyName. When I show the broken rules using ErrorWarnInfo object, I don't need to include the OriginPropertyFriendlyName as this controls shows next to the visual element and adding this friendly name would be just "noise".
Tiago Freitas Leal, CslaGenFork (Open Source CSLA code generator)
The broken rules collection is serialized with the object, so each broken rule object must be as small as possible. I have no problem adding a helper property the retrieves the friendly name, but I wouldn't want to store that value in the broken rule object itself.
Hi Tiago,
No - I do not believe that you should present the OriginPropertyFriendlyName. OriginProperty is more for internal usage and how the RuleEngine runs cleanup of validation rules before executing. IE: A rule can call AddXYZResult to set reult on other properties than the PrimaryProperty. These BrokenRule will always have another PrimaryProperty to which it should be displayed - but in these circumstances the OriginProperty is the PrimaryProperty for that rule and NOT the property that the message belongs to.
You should use PrimaryProperty and maybe add a Extension method to BrokenRule that gets the FriendlyName.
Jonny Bekkum, Norway CslaContrib Coordinator
Hi Rocky and Jonny,
As the property's FriendlyName is part of the BO, there is no point in duplicating that piece of information. My first approach was to try to get that value. When I found no method to do it, I turned to plan B and add it to the broken rule object.
I suppose that adding this method to BusinessBase.cs will do it
#region GetPropertyFriendlyName /// <summary> /// Gets a property's friendly name. /// </summary> /// <param name="propertyName">The name of the property.</param> /// <returns>The property's friendly name.</returns> public string GetPropertyFriendlyName(string propertyName) { var propertyInfo = FieldManager.GetRegisteredProperties().Where(c => c.Name == propertyName).FirstOrDefault(); if (propertyInfo == null) throw new ArgumentOutOfRangeException("propertyName"); return propertyInfo.FriendlyName; } #endregion
Due to some pressing family issues I have been unable to really look at this in depth until now.
The solution should be to take the GetManagedProperties method implemented today for the IManageProperties interface, and to make that public. That would allow UI components like CslaActionExtender to gain access to the IPropertyInfo objects for all registered properties.
The IPropertyInfo objects already have the friendly name as a property, along with other potentially useful information.
The only risk in this, is that external code can change the Index property, and if that occurs they'd introduce nasty serialization errors (and probably other errors). But the IPropertyInfo objects are normally already public and can be found using normal reflection, so I don't see this as an increased risk over today.
Hmmmmm,
Do we really want to make the entire IManagePoperties interface avalible publicly to external code?
internal interface IManageProperties { bool HasManagedProperties { get; } bool FieldExists(Csla.Core.IPropertyInfo property); List<IPropertyInfo> GetManagedProperties(); object GetProperty(IPropertyInfo propertyInfo); object ReadProperty(IPropertyInfo propertyInfo); P ReadProperty<P>(PropertyInfo<P> propertyInfo); void SetProperty(IPropertyInfo propertyInfo, object newValue); void LoadProperty(IPropertyInfo propertyInfo, object newValue); void LoadProperty<P>(PropertyInfo<P> propertyInfo, P newValue); List<object> GetChildren(); }
ReadProperty/LoadProperty/.... is at current version protected methods only and thus available to class and descendants.
PropertyInfo<T>.Index should marked with
[EditorBrowsable(EditorBrowsableState.Never)] int Core.IPropertyInfo.Index
No, absolutely not!
I am only suggesting making the GetManagedProperties method public so it is available through the interface and directly. Probably with EditorBrowsable(Advanced) to avoid some API clutter.
Do you mean editing
Csla.Core.BusinessBase
and replacing
List<IPropertyInfo> IManageProperties.GetManagedProperties()
by
/// <summary> /// Gets the managed properties collection. /// </summary> /// <returns>The managed properties collection.</returns> [EditorBrowsable(EditorBrowsableState.Advanced)] public List<IPropertyInfo> GetManagedProperties()
Regards
Well actually I was talking to Jason Bock on the way back from VS Live NY earlier this week and he had a good idea.
What they've done on his current project is to define a consolidated public IBusinessBase interface that exposes all the standard public methods from BusinessBase in one interface. They did this to make some mocking and testing scenarios simpler.
But even outside mocking/testing, the value of implementing this consolidated interface is that a UI framework component (like CslaActionExtender) would have easy access to all these elements through the interface - and without adding more elements to the default public interface of the object.
Interesting idea.
Are they allowed to submit the code to CSLA?
Did they include ALL public methods?
No, they can't contribute the code. But really, there's not much code to contribute, because all they did was define an interface against pre-existing methods/interfaces.
I think the only thing that wasn't easy was getting at the broken rules collection, because that's not part of an existing public interface. I think it probably should be part of some existing public interface though, so fixing that doesn't seem like a bad thing to me (ICheckRules perhaps?).
BusinessBase has BrokenRulesCollection as a virtual property and Interface does not accept properties.
But we could add a new method to ICheckRules as GetBrokenRules() and return that property.
/// <summary> /// Gets the broken rules for this object /// </summary> BrokenRulesCollection ICheckRules.GetBrokenRules() { return BrokenRulesCollection; }