PTracker - Inconsistent approach to Declaring Properties... why? which is more CSLA Compliant?

ejlatstl posted on Wednesday, February 18, 2009

Greeting All,

In studying the PTracker example I noticed 2 different approaches to 'Declaring' Properties. The Resource Class is a good example:

Last Name:

private static PropertyInfo<string> LastNameProperty = RegisterProperty(typeof(Resource), new PropertyInfo<string>("LastName", "Last name"));

First Name:

private static PropertyInfo<string> FirstNameProperty = RegisterProperty(new PropertyInfo<string>("FirstName", "First name"));

So... I recognize that RegisterProperty is overloaded. In one case the first method parameter is to pass in the class of the parent class and in the other case there is just the PropertyInfo parameter.

DO I... need to include the 'typeof()' if the PropertyInfo that will be passed in is not going to be 'project unique'?

If so, is there any harm in always including the 'typeof()' parameter? (CodeGen... consistant is better!)

Thanks and Cheers,

RockfordLhotka replied on Wednesday, February 18, 2009

This is the ongoing challenge with ProjectTracker, as it serves two (well, three) purposes:

Show the various ways you can do things
Show the best way to do things
Allow me to test the various ways to do things

If you look at PTracker for only number 2 you'll be disappointed, because it is outnumbered by 1 and 3...

In general, you should avoid the typeof() parameter for RegisterProperty(). Why? Because it introduces bugs as you copy-paste code between classes. And who among us doesn't do that from time to time???

However, not all base classes are generic (CriteriaBase, CommandBase, CslaIdentity) and so they don't have the same overloads for RegisterProperty() and you must use the typeof() parameter.

It is likely that I'll add generic CriteriaBase and CommandBase classes in the future - specifically to solve this issue.

However, if you are using codegen and never writing this code by hand, then using the typeof() parameter seems fine to me. It is human error that causes the problem, so automated codegen should be fine.

nermin replied on Thursday, February 19, 2009

Interesting thing is that now there is a third way to register properties – which will come out in Csla 3.6.2 ( I hope). It can be seen if you get the latest Csla.Net code and PTracker code from Subversion:

private static PropertyInfo<string> NameProperty =

RegisterProperty<string>(p=>p.Name, "Project name");

private static PropertyInfo<SmartDate> StartedProperty =

RegisterProperty<SmartDate>(p=>p.Started);

The advantage of this approach should be getting rid of string constant used for property name, and a slightly shorter syntax.

From: RockfordLhotka [mailto:cslanet@lhotka.net]
Sent: Wednesday, February 18, 2009 11:28 AM
To: Nermin Dibek
Subject: Re: [CSLA .NET] PTracker - Inconsistent approach to Declaring Properties... why? which is more CSLA Compliant?

This is the ongoing challenge with ProjectTracker, as it serves two (well, three) purposes:

Show the various ways you can do things
Show the best way to do things
Allow me to test the various ways to do things

If you look at PTracker for only number 2 you'll be disappointed, because it is outnumbered by 1 and 3...

However, not all base classes are generic (CriteriaBase, CommandBase, CslaIdentity) and so they don't have the same overloads for RegisterProperty() and you must use the typeof() parameter.

It is likely that I'll add generic CriteriaBase and CommandBase classes in the future - specifically to solve this issue.

wrvasquez replied on Thursday, May 07, 2009

How can I do declare a Property RegisterProperty<SmartDate> ???

I have a code:

private static PropertyInfo<SmartDate> FechaNaciemientoProperty = RegisterProperty<SmartDate>(c => c.FechaNaciemiento);
public string FechaNaciemiento
{
get { return GetPropertyConvert<SmartDate, string>(FechaNaciemientoProperty); }
set { SetPropertyConvert<SmartDate, string>(FechaNaciemientoProperty, value); }
}

But I have an error:
Error 1 Cannot convert lambda expression to type 'Csla.PropertyInfo<Csla.SmartDate>' because it is not a delegate type C:\Wagner\CSLA.Net\BLL\Utpl.Syllabus.Library\Utpl.Syllabus.Library\Estudiante.cs 61 95 Utpl.Syllabus.Library

Why it is??

Thanks

slh4342 replied on Monday, September 07, 2009

I am seeing the same lambda expression error in 3.7

private static PropertyInfo CreateDateProperty = RegisterProperty(c => c."CreateDate"); //, "Create Date", new SmartDate());
public string CreateDate
{
get { return GetPropertyConvert(CreateDateProperty); }
set { SetPropertyConvert(CreateDateProperty, value); }
}
private static PropertyInfo LastUpdateDateProperty = RegisterProperty(c => c."LastUpdateDate", "Last Update", new SmartDate());
public string LastUpdateDate
{
get { return GetPropertyConvert(LastUpdateDateProperty); }
set { SetPropertyConvert(LastUpdateDateProperty, value); }
}