Hi Otis,

I'm curious if you can share with me how Data Annotations and Validations will work in V3? Do you know what version of Data Annotations will it be supporting?

You mean annotations and validations through attributes? In v3 we added a deep attribute and setting system, which uses a waterfall principle: you define them per element type at the project level, and every instance of such an element (e.g. a navigator, field, entity etc.) inherits these global defined attributes / settings (and for entities / valuetypes also interfaces and namespaces). You can then override these on the element level by unchecking a checkbox and specify new ones. The attribute definitions use macros, like $true, $length, $elementname etc., which are replaced at generation time with the real value, and in the format of the target language.

So for example, if you want to add to every field a validation on length by adding an attribute, e.g. [Validation(Length=10)] for a field with length 10, you can simply define on the project level an attribute with the format: Validation(Length=$length) and in C# it will look like: [Validation(Length=10)], and in VB.NET it will look like <Validation(Length:=10)> _

This way you can annotate anything to the elements you can define in the designer. As you can start at the global level of the project, it's easy to define these attributes in a general way. So it's also easy to define Datacontracts for WCF for example. Or whatever other attributes you want to add to the code generated.

Of course, there is room for improvement, like you want Length validations on string fields, and Precision validation on numeric fields for example. It's easy to add these in a simple plugin we're thinking about (as these are just strings).

We also have a cool search feature which can be used to add stuff to the elements: the search is actually an area where you define a piece of C#/VB.NET code which is then ran on the model INSIDE the designer. We're thinking about re-using this technology to offer a new form inside the designer for ad-hoc model manipulations, so users don't need plugins to do things. This feature will not be present at beta 1 time however, but we're thinking about it (we'll see what feedback brings and what people have to say about the designer in general ).

If you have other questions about this, shoot!

So within the tool you can now create attributes and apply them en-mass to all fields, this can be quite handy. When the Attributer data is generated is this stored directly in the XXXXXEntity?

• Can the tool allow you to create attributes enmass for the case of if the field is **not null **make it add a Required Attribute?
• Can all additional fields created by LLBL like isDirty by default have Scaffold(false) ?
• Can I add UIHint to them as well?
• Are these capably of being used with EntLib or Data Annotations as well?
• Can all Identity fields or timestampe fields be Attributed with Scaffold(false)
• In some cases as the default behaviour or perhaps a configuration to how some attributes are assigned by default?

Can I control when they are applied?

I'd best elaborate. Can I say that I don't want them applied at all during the onSave, or can I control which ones are used? Could I then extend that and say I have teirs of attributues and control which ones are applied. My reasoning is that in an enterprise system you have different roles, with different roles having different validation requirements. In most cases RoleB will have all the validation requirements of RoleA plus additional, but not always. Thus it would be bad to make a field that RoleA can't access as Required, and the converse of filling in that field so it doesn't cause an error for RoleA is also bad, as then it has to be cleared for when RoleB should populate it.

(we are aware of these problems, yet have not found the cause of them nor how to fix them. They're a db timeout, while the db is at the same box. Sorry for this inconvenience -- Otis.)

quentinjs wrote:

Can I control when they are applied?

I'd best elaborate. Can I say that I don't want them applied at all during the onSave, or can I control which ones are used? Could I then extend that and say I have teirs of attributues and control which ones are applied. My reasoning is that in an enterprise system you have different roles, with different roles having different validation requirements. In most cases RoleB will have all the validation requirements of RoleA plus additional, but not always. Thus it would be bad to make a field that RoleA can't access as Required, and the converse of filling in that field so it doesn't cause an error for RoleA is also bad, as then it has to be cleared for when RoleB should populate it.

Attributes are static, you can't apply them or not when you wish - they are either applied or not. That said I think you might pull this off using custom validation attributes - here is one example: http://haacked.com/archive/2009/11/19/aspnetmvc2-custom-validation.aspx

HTH

True with Custom Attributes I could probably do it. In MVC 2 attributes are only static once they are bound which means you can load the attributes during the start up process. But once set they are set. There is even an approach to do that via XML. There is some discussion that that limitation could change in a future distant release... that just won't help me now.

Using the custom attribute as a wrapper data could be pulled from a database and validated that way based on the conditions at the time. I may have to look at that further once I actually make an application. As it would be cool to have a dynamic attribute. Or I could skip sleeping tonight and build it... ohhhh the tempation.

Thanks for reminding me again of that page.

And the reason for the mention of teirs was that I had not realized that Enterprise Attributes and Data annotation Attributes although looking the same, are not of the same family. Some times you have to wonder about a group that preaches DRY and then goes and creates an inferior wheel that can't even do all that the original wheel could. (I did actually inquire with a M$ developer but he did not know of a reason)

Sorry for the late reply, General Chat isn't monitored by queues so I missed it.

quentinjs wrote:

So within the tool you can now create attributes and apply them en-mass to all fields, this can be quite handy. When the Attributer data is generated is this stored directly in the XXXXXEntity?

The attributes are in the code, like you write them yourself, so as every other attribute. They're directly inside the generated entity class indeed, so no extra code

Can the tool allow you to create attributes enmass for the case of if the field is **not null **make it add a Required Attribute?

There are currently no expressions involved with this. However it's easy to add this with plugins. As our priority is first to get the beta finished, the plugin might not be ready at RTM, but we'll definitely add these kind of extras in a future version of v3.x (e.g. 3.1, 3.2), either directly or through a plugin.

Can all additional fields created by LLBL like isDirty by default have Scaffold(false) ? Can I add UIHint to them as well?

Don't know what you mean with Scaffold() ? The generated code is for .net 2.0 and usable on other platforms, as we otherwise have to maintain a lot of templates. An attribute that's defined in a 3rd party library isn't going to be added. You can define attributes on things you can define in the designer, so code which is in the runtime or templates (like IsDirty) isn't changeable with attributes. We do strive for adding attributes which hide more methods and properties from intellisense (and have already Browsable(false) on many properties) so using the code is easier.

Are these capably of being used with EntLib or Data Annotations as well?

You can add whatever attribute you want to entity classes, field properties, navigators, typed lists etc. so model elements which are generated into code. These definitions are in text, so there's no dependency.

Can all Identity fields or timestampe fields be Attributed with Scaffold(false)

Similar as your first request: there are no expressions yet, so this has to be done through plugins. As a plugin can traverse things easily it's a small thing to add a plugin which applies an attribute to a given element type and when a given set of rules is met.

In some cases as the default behaviour or perhaps a configuration to how some attributes are assigned by default?

Yes, that's possible. v3 works with frameworks, and every framework has a default set of attributes, settings etc. These are defined in a simple xml file. You can change these files and alter them to add different attributes or more or different default settings. You can also add more settings if you want with additional settings files.

Can I control when they are applied? I'd best elaborate. Can I say that I don't want them applied at all during the onSave, or can I control which ones are used? Could I then extend that and say I have teirs of attributues and control which ones are applied. My reasoning is that in an enterprise system you have different roles, with different roles having different validation requirements. In most cases RoleB will have all the validation requirements of RoleA plus additional, but not always. Thus it would be bad to make a field that RoleA can't access as Required, and the converse of filling in that field so it doesn't cause an error for RoleA is also bad, as then it has to be cleared for when RoleB should populate it.

The llblgen pro runtime framework doesn't use them, so it's strictly for external code, like WCF, UI frameworks and the like. So it's up to these frameworks if they use them.

Can all additional fields created by LLBL like isDirty by default have Scaffold(false) ? Can I add UIHint to them as well?

Don't know what you mean with Scaffold() ? The generated code is for .net 2.0 and usable on other platforms, as we otherwise have to maintain a lot of templates. An attribute that's defined in a 3rd party library isn't going to be added. You can define attributes on things you can define in the designer, so code which is in the runtime or templates (like IsDirty) isn't changeable with attributes. We do strive for adding attributes which hide more methods and properties from intellisense (and have already Browsable(false) on many properties) so using the code is easier.

If I take an entity and run it through a generic page generator in MVC that uses DataAnnotations, if a field is not decorated with Scaffold(False) then it will be displayed, thus all the working crap along with the actual fields is shown --- see http://msdn.microsoft.com/en-us/library/system.componentmodel.dataannotations.scaffoldcolumnattribute.aspx for the MSDN greek on this. What I have to do is generate the page, then take all the fields and manually place the scaffold(false) on it. As not all tables have the same field names, some of them change per table.

In case I didn't mention it before, there is also an Ordering attribute that is forthcoming, this will allow the fields to be ordered, will there be a mechanism to allow arrangement and ordering of the fields in LLBL ?

To confirm, from your comments you mentioned that the the built in LLBL validator methods will not be using these attributes at all. I would have thought that they would leverage these.

And if you give me your personal pager I'll make sure I beep you when new posts show up here ;-) Honest I will only use it for good!

quentinjs wrote:

Can all additional fields created by LLBL like isDirty by default have Scaffold(false) ? Can I add UIHint to them as well?

Don't know what you mean with Scaffold() ? The generated code is for .net 2.0 and usable on other platforms, as we otherwise have to maintain a lot of templates. An attribute that's defined in a 3rd party library isn't going to be added. You can define attributes on things you can define in the designer, so code which is in the runtime or templates (like IsDirty) isn't changeable with attributes. We do strive for adding attributes which hide more methods and properties from intellisense (and have already Browsable(false) on many properties) so using the code is easier.

If I take an entity and run it through a generic page generator in MVC that uses DataAnnotations, if a field is not decorated with Scaffold(False) then it will be displayed, thus all the working crap along with the actual fields is shown --- see http://msdn.microsoft.com/en-us/library/system.componentmodel.dataannotations.scaffoldcolumnattribute.aspx for the MSDN greek on this. What I have to do is generate the page, then take all the fields and manually place the scaffold(false) on it. As not all tables have the same field names, some of them change per table.

Properties in the base class like IsNew etc. can't have the attribute, as it would create a dependency on MVC, which is not what we can do.

You can add Scaffold(true) to entity field properties though. Not sure if MVC is designed that cleverly that you can tell it to scaffold only the properties which have the scaffold property (I expect it to have this, otherwise why have a boolean ctor flag?)

In case I didn't mention it before, there is also an Ordering attribute that is forthcoming, this will allow the fields to be ordered, will there be a mechanism to allow arrangement and ordering of the fields in LLBL ?

No, as fields have no order (properties don't have ordering either). This is typically something that is solved in layers consuming the code. Though you can add whatever property you like on any entity field, just not to the base class properties (which are uninteresting anyway, so MVC should just show the properties you annotate)

To confirm, from your comments you mentioned that the the built in LLBL validator methods will not be using these attributes at all. I would have thought that they would leverage these.

No because the attributes are in a library which we don't and can't reference. Furthermore, the validation logic itself is something that's actually code specific for the domain. Validation through attributes is also not something one should strive for (although MS has fallen for this pitfall a lot) as attributes are meta-data, and by using the attributes which are UI specific (for example), you tie the entities to that UI, while the validation should be inside the entity (i.e. through a validator).

We already have validation built in based on field aspects (string / array length, precision/scale on decimals), the rest is really code, not meta-data.

But you an annotate fields with these attributes if you like, they're just not used by the entity.

And if you give me your personal pager I'll make sure I beep you when new posts show up here ;-) Honest I will only use it for good!

heh Luckily I don't have any of these new gadget thingies