Tuesday, 30 March 2010

The Delphi Overflow Doc Wiki Initiative

A couple of days ago, I was reading Jim Mckeeth’s blog post about setting up a Delphi documentation wiki. Now while I admire Jim’s drive and determination about anything Delphi, and I like his idea, there’s one sentence I don’t agree with.

”At first I was thinking Embarcadero could hire a tech writer to copy edit the content from the questions into the Wiki, but that is just passing the buck.”

Any why shouldn’t Embarcadero properly document their own product? They are the ones making money from Delphi, aren’t they? I’m all for community input, but that shouldn’t let Embarcadero shirk their responsibilities. I guess Jim, like many others has just given up ever getting decent documentation, and taken matters into his own hands.

Hand’s up those who have given up on the F1 key when working in the Delphi IDE?

Sunday, 21 March 2010

Silverlight back from the dead.

Microsoft have probably just saved Silverlight. Their recent announcement of the Windows Phone 7 Series, and more importantly the development platform for that phone (Silverlight of course) means Silverlight is important now. I was always pretty sure WPF would become the defacto standard for desktop applications (and what with Visual Studio now being written in WPF, perhaps it will), but I couldn’t quite see a compelling reason behind Silverlight. Now there is one!

Have Embarcadero backed the wrong horse (again…)? They’re targeting the MAC with their next compiler. Probably because they think that is where the future is. Perhaps the future is with Seattle and not Cupertino!

They have Delphi Prism of course, and you can develop for Windows Phone using that. Having said that, no one has ever answered my question? Why should I use Delphi Prism and not C#? Now before I get a 1000 comments telling me that Pascal is easier to read than C#, I just want to say I agree. I love Prism! I wish I could use it every day. It’s awesome. Can I praise it anymore? I need a reason to use it though. One I can go to my boss with. I’d like to be able to go to him and say, “you know that project we were about to develop in C# (the one we decided to NOT use Delphi native Win32 for!), well I think we should use Delphi Prism because….”

If anyone can complete that sentence for me, I’d love to be able to use it. I wish Microsoft had approached Remobjects and partnered with them rather than Embarcadero. The only way my boss would agree to Delphi Prism would be if it sat along side C# and VB.NET in the default install of Visual Studio. That wouldn’t guarantee anything, but I’m sure the added exposure would garner quite a few new followers.

Saturday, 6 March 2010

More Attributes

Just got a comment from Mason Wheeler, that he prefers to use attributes to indicate a property to NOT serialise , rather than those properties to serialise. I quite like this idea, as it’s true that if you have quite a few properties to serialise, your class may get rather messy. My only problem with this is that the property name must then be the same as the column name. I guess not a major problem, but still. In a perfect world, you’d have two types of attributes. Those which came before properties, methods or fields and those which came after. Those which came before would work just like the class visibility sections. i.e. they apply to all properties, methods and fields until the next attribute, or section. Those attributes that came after a property, method or field, apply to that item only. thus I could write something like this.

public
[Persist]
property Id : Int64;[Key][ColName(
'Id')];
property FirstName : string read fname;[ColName(
'Name')];
property Surname : string read fSurname;
property Address : string read fAddress;
public
property FullName : string;
//not persisted


I’m not sure how difficult that would have been to parse.

Attributes

Last time, I demonstrated how I would like to decorate my class using attributes to declare the table and column names I eventually will use to persist the class. Here are the the declarations of the two attributes I used.
PersistentClassAttribute = class sealed(TCustomAttribute)
strict private
fTableName : string;
public
constructor Create(
const aTableName : string);
property TableName : string read fTableName;
end;


PersistentPropertyAttribute = class sealed(TCustomAttribute)
strict private
fColumnName : string;
fKey : Boolean;
public
constructor Create(
const aColumnName : string; aKey : Boolean = False);
property ColumnName : string read fColumnName;
property Key : Boolean read fKey;
end;


Both fairly simple. The important things to not is that both inherit from TCustomAttribute, and their constructors dictate the way I will use them. I’m not going to bother showing the implementation of either of these classes. Both are very similar, in that the parameters passed to the constructors are stored in the corresponding private fields.



Now we’ve got our attributes set up, and our class has been duly decorated. How do we access that information? Well, you’ll notice that the class which we wish to persist inherits from TPersistable. This class will take care of getting the information we need from the attributes. Let’s start with the class map information.



We’ll create a class procedure on TPersistable to load our classmap.





var
ctx : TRttiContext;
t : TRttiType;
p : TRttiProperty;
a : TCustomAttribute;
begin
ctx :
= TRttiContext.Create;
t :
= ctx.GetType(Self);
for a in t.GetAttributes do
if a is PersistentClassAttribute then
begin
fTableName :
= PersistentClassAttribute(a).TableName;
Break;
end;




Anyone who has seen any code associated with the new RTTI functionality will be familiar with this code. We use the RTTIContext to get to the class information. We iterate over all the attributes on the class until we get to the PersistentClassAttribute. We could do this every time we needed the class map information, but we’re going to do this once, and then cache the information. The next step would be to get the list of properties which we want to persist. We’ll add a few more lines to the procedure above.



class procedure TPersistable.LoadClassmap;
var
ctx : TRttiContext;
t : TRttiType;
p : TRttiProperty;
a : TCustomAttribute;
Prop : IPropertyMap;
begin
ctx :
= TRttiContext.Create;
t :
= ctx.GetType(Self);
for a in t.GetAttributes do
if a is PersistentClassAttribute then
begin
fTableName :
= PersistentClassAttribute(a).TableName;
Break;
end;

for p in t.GetProperties do
for a in p.GetAttributes do
if (a is PersistentPropertyAttribute) then
begin
if not fPropertyList.ContainsKey(UpperCase(PersistentPropertyAttribute(a).ColumnName)) then
begin
Prop :
= TPropertyMap.Create(PersistentPropertyAttribute(a).ColumnName, P.PropertyType.TypeKind);
fPropertyList.Add(UpperCase(Prop.ColumnName), Prop);
end;
end;
end;


We’re doing exactly the same thing as before, except this time we’re iterating over the properties of the class, and checking the attributes of each property. If that attribute happens to be out PersistentAttributeProperty, we create a TPropertyMap class and add it to our list of properties. Once this class procedure has been executed, we now have a cache of information about our class and how we should go about persisting it. we could add a few class functions to help us access that information.



 class function PropertyMap(const aName : string) : IPropertyMap;
class
function TableName : string;
...
...
class
function TPersistable.PropertyMap(const aName: string): IPropertyMap;
begin
fPropertyList.TryGetValue(UpperCase(aName), Result);
end;
...
...
class
function TPersistable.TableName: String;
begin
Result :
= fTableName;
end;



We’re still a long way from persisting our objects, but we now have all the information we need. When I do implement the actual persistence, I’ll make sure it is extremely easy to change from persisting to SQL Server or to a simple XML file.