To use a friendly name do this:
ValidationRules.AddRule(
Csla.Validation.
You can find an example of using a friendly name in a custom rule method by looking at any of the rule methods in CommonRules. Note the use of the Shared/static helper method to resolve the property name value.
To use a friendly name do this:
ValidationRules.AddRule(
Csla.Validation.CommonRules.StringRequired, new Csla.Validation.RuleArgs("Name", "Project name"));
******************************
In VB the code in AddBusinessRules() looks like this:
ValidationRules.AddRule( _
AddressOf Validation.CommonRules.StringRequired, _
New Csla.Validation.RuleArgs("Name",
"Project name"))
Rocky
From: un7lg
[mailto:cslanet@lhotka.net]
Sent: Wednesday, July 18, 2007 10:01 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] is there a PropertyFriendlyName example?
To use a friendly name do this:
ValidationRules.AddRule(
Csla.Validation.CommonRules.StringRequired,
new Csla.Validation.RuleArgs("Name", "Project
name"));
******************************
For this part:
- Csla.Validation.CommonRules.StringRequired
I received an error message:
Argument not specified for parameter 'e' of 'Public Function
StringRequired(target As Object, e As Csla.Validation.RuleArgs) As Boolean'.
?
To use a friendly name do this:
ValidationRules.AddRule(I add AddressOf and it worked for me:
I am working on it right now J
Rocky
From: un7lg
[mailto:cslanet@lhotka.net]
Sent: Wednesday, July 18, 2007 10:13 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] is there a PropertyFriendlyName example?
Thanks Rocky,
I can't wait your next book regarding 3.0 new features added.
I really need it to make my life easier.
RockfordLhotka:
I am working on it right now J
Intellisense should be showing you the options for parameters of
the MaxLengthRuleArgs constructor:
ValidationRules.AddRule( _
AddressOf
Validation.CommonRules.StringMaxLength, _
New Validation.CommonRules.MaxLengthRuleArgs("Name",
“Project name”, 50))
From: un7lg
[mailto:cslanet@lhotka.net]
Sent: Wednesday, July 18, 2007 10:21 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] is there a PropertyFriendlyName example?
I do not want to be annoying, but how apply FriendlyName to
this rule?
ValidationRules.AddRule( _
AddressOf
Validation.CommonRules.StringMaxLength, _
New Validation.CommonRules.MaxLengthRuleArgs("Name",
50))
Intellisense should be showing you the options for parameters of the MaxLengthRuleArgs constructor:
ValidationRules.AddRule( _
AddressOf Validation.CommonRules.StringMaxLength, _
New Validation.CommonRules.MaxLengthRuleArgs("Name", “Project name”, 50))
I don’t know – there are several overloads for the constructor,
and the code I provided works. You do have to make sure Intellisense is showing
the correct overload for the parameters you want to pass or it can get
confusing. However, it will compile regardless.
Rocky
From: un7lg
[mailto:cslanet@lhotka.net]
Sent: Wednesday, July 18, 2007 11:00 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: is there a PropertyFriendlyName example?
Intellisense should be showing you the options for parameters of the MaxLengthRuleArgs constructor:
ValidationRules.AddRule( _
AddressOf Validation.CommonRules.StringMaxLength, _
New Validation.CommonRules.MaxLengthRuleArgs("Name", “Project nameâ€, 50))
yes, of course it did
In this part
Validation.CommonRules.MaxLengthRuleArgs("Name", “Project nameâ€,
50))
intellisense is not give me an option for FrienflyName, that is why I asked.
It tried to convert the 2nd arg to Integer and the 3rd one to String to be a
maxLenght and a Format args.
Rocky,
Just wondering if any thought was given to implementing friendly name as a attribute of the property and if so why not?
It's just we implemented the equivalent in v2 along with common rules based on attributes with very little code. For example heres a typical string property on one of our objects:
[Attributes.TextField(Description="Brief Description", MaxLength=50, Required=true)]
public string BriefDescription
Description is our friendly name and it being an attribute is available to other systems besides the rules engine (UI generator etc.), also no need to addrule for common rules like required, this is done automatically based on the Required attribute.
Justin
I'd like to hear the thoughts on this too. After all the numerous hours I've spent pondering and experimenting with this solution over the last few years, it seemed to always end up that, all things considered, it was just hard to beat the attributes approach like Justin described.
Rocky,
Just wondering if any thought was given to implementing friendly name as a attribute of the property and if so why not?
It's just we implemented the equivalent in v2 along with common rules based on attributes with very little code. For example heres a typical string property on one of our objects:
[Attributes.TextField(Description="Brief Description", MaxLength=50, Required=true)]
public string BriefDescription
Description is our friendly name and it being an attribute is available to other systems besides the rules engine (UI generator etc.), also no need to addrule for common rules like required, this is done automatically based on the Required attribute.
Justin
Not to put too fine a point on it, but where were you guys during the beta? I love this kind of lobbying for changes. But input like this would be much more useful coming during the pre-release and beta 1 cycle when I can incorporate the ideas into the framework.
I'll add the idea to the wish list and see if I get time to work in this area for 3.5 - though my focus on 3.5 is mostly on data access and not on validation so much.
I'd like to hear the thoughts on this too. After all the numerous hours I've spent pondering and experimenting with this solution over the last few years, it seemed to always end up that, all things considered, it was just hard to beat the attributes approach like Justin described.
Rocky,
Just wondering if any thought was given to implementing friendly name as a attribute of the property and if so why not?
It's just we implemented the equivalent in v2 along with common rules based on attributes with very little code. For example heres a typical string property on one of our objects:
[Attributes.TextField(Description="Brief Description", MaxLength=50, Required=true)]
public string BriefDescription
Description is our friendly name and it being an attribute is available to other systems besides the rules engine (UI generator etc.), also no need to addrule for common rules like required, this is done automatically based on the Required attribute.
Yeah sorry about that, think I was too busy sorting through Silverlight, SOA, Web 2.0, Sharepoint, Biztalk, Infopath, and figuring out which SKU of VS I needed to get during that time ;).
Seriously though I have mentioned it in the past (http://forums.lhotka.net/forums/thread/13607.aspx), but there was some definite hesitation here that some of it started fusing the UI into the BO, but when I saw friendly name added to the rules engine the first thing I thought of is how many times will that string be defined in code? Once for rules and at least one more time for the UI label, this is exactly why we made it an attribute. A bonus is of course the AddRule signature didn't have to change it just relfects internally to pick up the friendly name.
Justin
Not to put too fine a point on it, but where were you guys during the beta? I love this kind of lobbying for changes. But input like this would be much more useful coming during the pre-release and beta 1 cycle when I can incorporate the ideas into the framework.
I'll add the idea to the wish list and see if I get time to work in this area for 3.5 - though my focus on 3.5 is mostly on data access and not on validation so much.
Once for rules and at least one more time for the UI label, this is exactly why we made it an attribute. A bonus is of course the AddRule signature didn't have to change it just relfects internally to pick up the friendly name.
Justin
Yes we did run into this but it has not proved to be much of an issue. That is, why would an attribute change? Perhaps "required" can flip flop based on some other change? Doesn't that get into the realm of making two objects since thier behaivors are different?
We actually implemented a way to change attributes at runtime to experiment with. Basically the way we did it was our base objects implemented a GetPropertyAttributes method that does what Attirbute.GetCustomeAttributes does but caches the attibute objects within the instance. Then you can modify the returned attributes and the next time you GetPropertyAttributes it gives you the cached instance instead of constructing a new as Attirbute.GetCustomeAttributes would and therefore retains state from any changes made previously on that instance. This actually worked quite well but all code depending on attributes had to use the instance method instead of the static reflection method.
Justin
What about a dynamic changes during runtime of attribute if it needed?
That is, why would an attribute change?
Justin
What about a dynamic changes during runtime of attribute if it needed?
Ah yes user defined changes to business objects. Well our approach to that problem is still work in progress and lends itself to the attribute model, I will explain shortly.
It's really a matter of perspective. I wouldn't call the situation you described necessarily a "runtime" change exactly. That is someone other than a developer can change the business object but this is done infrequently compared the actualy usage of the object.
So we are actually using the built in codedom and dynamic code compiling and assembly load to let our users modify a business object through inheritance of the base objects we provide. That is there is a place in the app to submit source code which will be stored in the db, then read compiled and loaded dynamically by our app overlaying the base busnisses object with thier extensions to it. Also a simple designer to write the source code, so if they want to do something simple like add an extra property to a base object they need not know how to write c# (Think winforms designer and the code it generates).
So you see our solution nothing needs to change, the attributes still function without needing to change at runtime, however source code iteself can be modified and it is the one and only definition of the object. In your model you would have some design in .net code and yet another metalanguage to overlay U_String1 with the same attributes. This metalanguage is what in your solution, xml, sql tables, sql extended attributes?
Not exactly the easiest solution I know, I am not going to say we have a working solution yet, but .Net is really the first langauge I have developed in that this would even be possible without writing my own compiler.
Probably not the answer you where looking for, but in your case attributes in source code don't make sense as they are defined elsewhere already and you want to read them from this other source and applying them.
Justin
Lets assume that I have a properties(columns in my DB as well) of different types (such as string,boolean etc) and users of my app can use those fields if they want to provide some extra info about object.
So they define the FriendlyName to a U_String1 property, some validation rule and some criteria to it.
Is it possible to do such a things with an attribute to the property U_String1?
I would say at that point you've gone down a different path - or you have a different enough problem that you're looking for a different solution in the first place.
I've also given more consideration to the models where metadata is read at runtime lately. It has its advantages, for sure, and probably isn't all that hard to implement since you need a good designer for entering metadata in the code-generation paradigm anyway.
It does make me a little nervous though. A few years ago my employer failed miserably at an ERP solution (JD Edwards) implementation. One of the big root problems was the fragility of the incredible complexity required to support extensive end-user runtime capabilities like it had. It didn't perform very well either.
I understand where your coming from for sure. I can see these mistakes have been in other systems, where they are so user customizable that the the overhead of this whole new user runtime on top of the developer runtime destroys performance. Look at Microsoft CRM, it has two databases one for data the other for the metatdata of the data and you can pretty much design your own tables and relationships between them etc along with workflow and forms!
Bottom line though as we sell our products commercially is that while most of our customers work almost the same way, there are differences that must be accounted for to give them a working solution. custom reports, data import mappers, and customized data elements/screens are things we need to satisfy the market. Each of these has some dialect stored somewhere in the users data that they can modify.
We are treading lightly in this area, and will not release a solution that would let the user do anything too detremental to the application. At the same time we would rather not make yet another domain specific language that they use, instead they use the same one we do albiet with some control layered on top of it.
Justin
I would say at that point you've gone down a different path - or you have a different enough problem that you're looking for a different solution in the first place.
I've also given more consideration to the models where metadata is read at runtime lately. It has its advantages, for sure, and probably isn't all that hard to implement since you need a good designer for entering metadata in the code-generation paradigm anyway.
It does make me a little nervous though. A few years ago my employer failed miserably at an ERP solution (JD Edwards) implementation. One of the big root problems was the fragility of the incredible complexity required to support extensive end-user runtime capabilities like it had. It didn't perform very well either.
Early on I was hesitant to use attributes, because on a per-instance level the reflection could have become problematic. One of (if not the) slowest reflection operations is the retrieval of custom attribute values.
Now, with per-type rules, the cost of this reflection should be incidental, because it would only trigger once per type per appdomain.
However, my focus was on the existing approach. I'd seen some older posts on the attribute idea, but they didn't really come to mind as I was doing the 3.0 work and so I never considered using them.
It is also the case that it would be ideal for an attribute approach to accomodate any rule. That's a separate issue from the friendly name attribute concept - at least in my mind.
And I worry that UI developers would start to rely on those attributes as well, when they really should get the rule list as a set of rule:// URI values.
It is true that an attribute-based approach can be complimentary to what I've done so far. I can envision a new method, like:
ValidationRules.AddRulesFromPropertyAttributes()
(or something with a slightly shorter name <g>)
But the friendly name thing is now less fun, because I incorporated the concept into the RuleArgs constructor as a string. RuleArgs does not have enough information to reflect on the target object - remember that target is a separate parameter to the rule from the RuleArgs.
Also, you don't want to reflect to get the friendly name when the rule method is invoked, because that would result in way too much reflection. Instead, you really do want to get the friendly name when AddRule() is called.
So I could see this:
ValidationRules.AddRule(StringRequired, new RuleArgs("Name", ValidationRules.GetFriendlyName("Name")))
But that's kind of ugly too. Unfortunately, since RuleArgs doesn't know the target object type, it can't just do this automatically... I suppose it could be:
ValidationRules.AddRule(StringRequired, new RuleArgs(this.GetType(), "Name"))
Because that would give RuleArgs access to the right type information.
Sorry about being a bit snippy regarding the beta.
I have observed, over the past few years of doing this, that I get a lot of "beta" feedback after release.
This is not to diminish the wonderful feedback I do get during the beta process!! In 3.0 the WPF features wouldn't be nearly what they are without the help of several motivated individuals, and there'd be at least one really ugly WCF bug in there that I simply never saw myself, but resolved thanks to beta testing help!
But the reality is that I get more feedback after release, and that is sometimes a little frustrating.
I apologize for taking it out on you and this thread.
What about a dynamic changes during runtime of attribute if it needed?
In my view, dynamic changes should be handled by a custom rule. In other words, the rule method itself shouldn't change (you shouldn't be adding or removing rules at runtime), but rather the rule method should implement logic that handles the changing requirement.
Typically "dynamic changes" means things like property A must be less than property B. That's a custom rule.
Property A is required only if property B has some specific value. That's a custom rule.
The validation rule infrastructure is designed to follow this viewpoint.
What about a dynamic changes during runtime of attribute if it needed?
In my view, dynamic changes should be handled by a custom rule. In other words, the rule method itself shouldn't change (you shouldn't be adding or removing rules at runtime), but rather the rule method should implement logic that handles the changing requirement.
Typically "dynamic changes" means things like property A must be less than property B. That's a custom rule.
Property A is required only if property B has some specific value. That's a custom rule.
The validation rule infrastructure is designed to follow this viewpoint.
This is one reason we are taking the code generation approach, it's hard to beat the .net runtime for speed. Look at the System.Xml.Xsl.Runtime.XslCompiledTransform class, Turning the XSLT language into .Net code and compiling is faster than interpreting XSLT directly. This is what your doing, loading up a domain specific language and interpreting it when the object loads.
Of course sticking to your approach you could optimize out the DB access by caching the table based attributes in say a static property on your business class, so that the first time a BO is instanced in the app domain it reads from the DB after that it comes from the cache. But you must handle a Admin changing the attributes and cached versions still out there without those changes.
Then again perhaps the extra DB access is minor in the overall performance picture of your application.
Justin
This is what I do not like:
Everytime my object created, it has to go to this table to read defined virables to apply validation rules.
I don't know if there is any other way to handle this.
Any advices appriciated.
Well, first off, I apologize. Unfortunately I haven't had the time in the last year to be as involved as I used to be.
I didn't really mean it to sound like "lobbying for change" post-release. I don't think anything you've done prohibits continuing to implement or use the attributes functionality.
The question was more just out of curiousity as to the thoughts behind avoiding the attribute approach, if it was even a real decision in that sense. There have been several quite lengthy and thorough discussions of this attrribute approach over the last few years (mostly on the old forum, no doubt), so it's not like we're springing a new idea here.
I just wanted to second this sentiment as well. My inquiry was not really a lobby for change it was curiosity and perhaps hear some opinions on attribute based programming and if there are downsides to this approach that perhaps I am not seeing.
Justin
Well, first off, I apologize. Unfortunately I haven't had the time in the last year to be as involved as I used to be.
I didn't really mean it to sound like "lobbying for change" post-release. I don't think anything you've done prohibits continuing to implement or use the attributes functionality.
The question was more just out of curiousity as to the thoughts behind avoiding the attribute approach, if it was even a real decision in that sense. There have been several quite lengthy and thorough discussions of this attrribute approach over the last few years (mostly on the old forum, no doubt), so it's not like we're springing a new idea here.
Copyright (c) Marimer LLC