New Posts New Posts RSS Feed: Customizing Code Generation??
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Customizing Code Generation??
 Post Reply Post Reply
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
jmarbutt View Drop Down
DevForce MVP
DevForce MVP


Joined: 04-Jun-2010
Posts: 17 		Post Options Post Options   Quote jmarbutt Quote  Post ReplyReply Direct Link To This Post Topic: Customizing Code Generation??
    Posted: 04-Jun-2010 at 11:06pm
Ok I am trying to transition an application from RIA services to DevForce. In my current RIA Service MetaData I have created my own attributes for properties, example in RIA services:

[MyAttribute("MyValue1","MyValue2")]
[Display(Name="My Field")]
public string MyField {get; set;}


I know DevForce creates the Display attribute and you just set it in the Entity Manager. So my question is how can I extend the DevForce to create the MyAttribute and set MyValue1 and MyValue2 in the entity model designer? And do you have an example that best fits doing this with DevForce?

I believe you can do this with T4 template but I am not an expert of using the T4 templates (I have never used them) so go easy on me on that.

Edited by jmarbutt - 04-Jun-2010 at 11:09pm
Back to Top
ting View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 27-Mar-2009
Location: San Francisco
Posts: 427 		Post Options Post Options   Quote ting Quote  Post ReplyReply Direct Link To This Post Posted: 10-Jun-2010 at 7:54pm
I'm assuming you're using the [MetadataType] attribute to specify a separate metadata class in WCF RIA Services.  You can do the same thing in DevForce and we also provide a method to read the attributes from both the primary class, as well as from it's metadata twin.  (See IdeaBlade.Core.ReflectionFns.GetAttribute() - If you specify true for the checkMetadataType parameter it will read it from there as well.)
 
You could modify the template to generate the attribute, but it would have to know how to get the data for MyValue1 and MyValue2.  There isn't an easy way to expose those attributes to the property sheet of the Entity Framework designer.
 
Back to Top
WardBell View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 31-Mar-2009
Location: Emeryville, CA,
Posts: 338 		Post Options Post Options   Quote WardBell Quote  Post ReplyReply Direct Link To This Post Posted: 10-Jun-2010 at 8:34pm
Very interesting. Ting's suggestion mimics the RIA Services approach ... except that, unlike RIA Services, you have to carry the metadate "buddy" class into the SL app with you.
 
We don't have a separate code generation tool that transforms server-side entity classes and associated metadata and shared partial classes into a Silverlight entity class. We don't have it because we don't need it and you don't want it (trust me!).
 
Ah ... but it would be convenient in this corner case, wouldn't it? Instead, per Ting, you can link to the metadata class in SL and use the ReflectionFns to get your attribute.
 
===
 
There is another way. You could inscribe your attribute right into the generated entity class by overriding a property generation method in our T4 code generation base class (virtually no T4 knowledge needed). An example of how to do that will follow (or you can search our forum to see how some other folks are doing this).
 
Now you'd be able to write "MyAttribute" into the code. Unfortunately, that's only half the battle. You need to tell your code-generation overide (a) whether or not to hang this attribute on the property and (b) what the parameter values should be. Where do you specify this information where your code-generation overide can find it?
 
I considered and immediately discarded the notion of a separate XML file that your code can discover an interpret. You could do this ... and write yourself a little DSL for it ... maybe even your own visual editor. But this seems like a lot of work for a small problem.
 
Idea #2: We enhance our DevForce VS EF Designer extension so you can inject your own properties. Then you could entere values in the EF Designer just as we do. We'll look into this for a future release; it doesn't help you now.
 
Idea #3: Hijack an existing EF Designer property.  This is a short term hack but it may be your best bet. The "Long Description" under the "Documentation" heading would be my candidate.
 
Adopt your own markup convention so you can distinguish your attribute parameters from the text you'd actually like to see in the Long Description.
 
Your code-generation override would (a) extract your custom markup from the Long Description, (b) rewrite the Long Description text so that the XML remarks in the code turn out as they should, (c) use the markup to write your custom property.
 
A total hack as I said. We'll come up with something better in a future release.
 
Hope this helps for now.


Edited by WardBell - 10-Jun-2010 at 8:37pm
Back to Top
jmarbutt View Drop Down
DevForce MVP
DevForce MVP


Joined: 04-Jun-2010
Posts: 17 		Post Options Post Options   Quote jmarbutt Quote  Post ReplyReply Direct Link To This Post Posted: 10-Jun-2010 at 9:03pm
I love the idea of #2 but like you said that doesn't help me today.

I actually started doing #3 today, I figured that was the best way to do it for now since most of the time I don't use them as much as I could. It is a total hack but an easy one at that.

Thanks Ward!
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down