Hi Rocky,
I was wondering if it might be possible to add this to a future version of CSLA. Right now all of the message descriptions are privately pulled from the resource file, but it would be nice if you could set the message description at the time of initializing the rule. The reason being is that there are times where I would want to use the common rule but don't want to use the standard message. A good example would be using the regex rule. Depending upon what regex i'm validating against I might want to display a different message rather than the generic regex message.
I know that I can just write my own versions of these common rules to do that, and I have, but I've had to rewrite these common rules every time a major version change comes out because rules are implemented a little differently each time.
I'm just thinking of an implementation where there is a MessageDescription public property exposed to the CommonBusinessRule class and in the execute method just check to see if the property is empty or not. If it's empty then fall back to pulling from the resource file, but if it has a value than output that value. And you wouldn't even need to alter the class constructors at all, since people could just use a class initializer to set the property.
Thanks for listening,
Mike
Hi Mike,
Having the Message available as a property on initialization would NOT enable localization as the resource files does.
A better option would be to supply a "resource" filename and "key" and have the rule fetch the string from the resource file.
BTW:This is how the DataAnnotation rules work.
Hi Jonny,
While your suggestion isn't a bad idea, couldn't a user just as easily make a call to the resource file and key to pull the value when they set the property? From my standpoint having the property would give users the flexibility to change the message whether they want to use localization or not.
Thanks,
Mike
I think you have to strike the balance between standards and useability within the framework - I think the resource filename/key option is a good idea as CSLA allows localisation, the supporting elements should all follow this same theme - and it's pretty much like using the standard rules.
I don't think implementing your own custom versions of these rules is much work and it's rare that the rules implementation completely changes
I would be very dead set against that. We localize within our app because it serves the dual purpose of localization but also customization. In fact this is why we can't use the commonrules either. The original suggestion was simple and to the point and made sense, why needlessly complicate it?
The original suggestion doesn't solve the problem in the general case. Specifically, on a web server being used by people from numerous countries, or on an app server being used by clients with different cultures.
Remember that the rule instances are created once and cached per AppDomain. So what you are suggesting would cause the rule to grab the description based on the culture of the first user to hit the server, and all other users would get that result regardless of their culture.
In our case we use codes for all text displayed in the UI and it's resolved at the UI layer just before being displayed to the user based on their language preferences. I'm not sure how else you would do it but if what you say is true then of course your system is equally broken in the same way.
Assuming that every user is going to speak the same language as the first person who logs in seems like a bad idea just on the face of it from a framework point of view. It's of course something that might be valid from the implementers point of view but wouldn't it be best to leave it up to them?
Of course in the end, no one is forced to use the CommonRules implementations. If they don't work for a specific application architecture or scenario that's just fine. If you stop and think about it, it is absolutely impossible for me to meet everyone's requirements.
And yet, just like Microsoft has now done with DataAnnotations, it is important for the framework to provide some implementation of the most basic validation rules because they are so common.
And the reality is that my existing implementations work for almost everyone. And if we make them support resource-based localization they'll support a whole lot more people without breaking existing users.
And anyone who finds that they don't fit well into a given application can replicate the rules in a couple hour's time, so there's a viable solution for everyone.
Yup, no way you can be everything to everyone. I was just putting in my 2c worth to add a differing point of view to the discussion.
It's your framework to do with as you wish.
From my point of view I see it as two options:
1) Leave it entirely in the hands of the implementer using the framework so they can use whatever system they wish while still enjoying the benefit of less code to write
2) Needlessly imposing a strict standard that won't work for everyone for seemingly no useful purpose other than in a tangential way Microsoft does it that way so of course it *must* be right. ;)
I think the important thing to understand is that the existing functionality of CommonRules won't be affected by whatever we do. This is not nearly important enough to break everyone who is using the rules today.
But we can easily add resource name properties to the rules so people can optionally provide their own resource files with their own resources, and (at least right now) I don't think we need to break existing functionality to make that happen.
Hi Rocky,
I apologize if I don't fully understand, but how would opening up the property break existing functionality? My thought was that if they filled in the property during initialization then use whatever they filled in, but if it was not set to anything then use the existing resource file for the message. So if a user didn't change anything about their rules, it wouldn't affect them.
And just one more question. How is this different than allowing users to put a string in as a friendly name for the property? Doesn't that functionality also bypass localization?
Also just as a sidenote, I hadn't used Microsoft's DataAnnotations before, but in looking at them, they actually allow for both solutions. The ability to set your own error message, or to pull from the resource file. So why couldn't CSLA follow the same practice and allow both?
I just want to also say, thanks for all the work you've put into the framework over the years, and that it has saved me a lot of time and effort for a multitude of projects, so I don't want to sound ungrateful, because I absolutely love using the framework. I just don't see how this small request is such a bad idea overall.
Thanks again.
I get the value of using localization and your reasons to implement the rule message description that way, but I really have to question whether localization is the general widespread case. For larger corporate global applications I see the use, but for small business use whether used in house or for targeting a single culture implementation, it just seems like overkill. Most of the apps I work on for clients fall into the latter category, so maybe i'm just disconnected from the general use case.
And I understand that it isn't that difficult to implement my own common rules, but i've had to update them a few times now since v2 across multiple apps, so I was just hoping this easy suggestion could ease the pain of recreating the wheel whenever I have to upgrade to the next version.
If customization using a resource file/key is the way it needs to be in the future then I guess that will at least take care of me having to recreate the common rules, but I guess I just don't see why it's a big deal to open up that property for users to inject their own messages if they understand the ramifications of the rules being cached per AppDomain in addition to the localized solution.
Thanks for listening.
This is a good suggestion. As Jonny indicates, we'd almost certainly copy the DataAnnotations solution to the problem, allowing you to provide resource key names so we could read resource strings - just like DataAnnotations.
I've added this to the wish list.
Copyright (c) Marimer LLC