missing: optional code-generation for properties

mindplay · Post by **mindplay** » Wed 04 Jan 2012 20:00

It appears there is no way to bypass code-generation for a specific property?

There are cases in which you need to implement both the get-method and set-method for a property - when the persisted property is a calculated value, for example for optimization purposes; or when the persisted value is a representation of another run-time value, for example an object being serialized/unserialized to/from a string.

I'd like to have an option to disable code-generation only - not mappings; since non-generated properties are still technically part of the model, although they must be implemented manually.

Here's where I think it would make sense to gray out certain properties - if non-generated navigation properties will no longer display in gray, perhaps it would make sense to display non-generated properties in gray?

(alternatively, to avoid confusion with existing display in current version, perhaps disabled properties could display in parentheses or with an asterisk? I'd prefer not to use a color-coding such as red, since I use diagrams as documentation - which would mean you need a color-printer and expensive ink...)

Note that bypassing code-generation for navigation properties might also be useful in some cases; although conceptually this option might collide with the existing ability to disable (Generated=false) a navigation property entirely.

It's not the same thing - bypassing code-generation means you have to implement the code yourself; whereas bypassing a property entirely (which makes sense only for navigation properties) means the property is definitively not part of the model (or mappings) at all.

Helen · Post by **Helen** » Thu 05 Jan 2012 14:06

This task is rather specific, and we don't think it's urgent. Besides, it's not clear how to present this feature to most of the users who will not use it.
We allow modifying of our code generation templates for such specific tasks. We also allow defining extended properties for basic objects of the Conceptual model with our templates. These properties can be set in Entity Developer and then used by template for your specific generation tasks.

We should warn you that in case of using your own templates based on Entity Developer standard templates, when updating Entity Developer to a new version, you will need to merge your template with the updated Entity Developer ones if you want to make use of their updated functionality.

mindplay · Post by **mindplay** » Thu 05 Jan 2012 14:21

Helen wrote:We should warn you that in case of using your own templates based on Entity Developer standard templates, when updating Entity Developer to a new version, you will need to merge your template with the updated Entity Developer ones if you want to make use of their updated functionality.

Thanks - I am aware of that; I checked the original template into SVN before making changes, so I should be able to diff and merge with relative ease.

I don't think the need to implement custom behavior in a get-accessor is as exotic as you make it out to be; to me, it's simply the natural counterpart to the change-events ED generates - in my opinion that's a fairly complex facility for what it does, which is basically just allowing you to aggregate functionality onto set-accessors. Yet you don't think it's necessary to add functionality to get-accessors at all?

Either way, this is something I can very easily implement in my custom template by just adding another flag and a few if-statements.

Helen · Post by **Helen** » Thu 05 Jan 2012 15:13

mindplay wrote: Yet you don't think it's necessary to add functionality to get-accessors at all?

This functionality will be available in the next build. Please take a look at this post .

mindplay · Post by **mindplay** » Thu 05 Jan 2012 16:49

What does this have to do with access-modifiers? (maybe along with public/private/protected etc. there will be an option like "unimplemented"?)

Helen · Post by **Helen** » Tue 10 Jan 2012 11:46

Sorry for the small misunderstanding of "get-accessors". We have understood that you meant access modifiers setting when you talk about "get-accessors".

At the moment we don't have any plans to implement an "unimplemented" option.

Helen · Post by **Helen** » Fri 13 Jan 2012 11:28

We have investigated this issue and decided to add an option to disable code-generation only.

We will post here when the corresponding build of Entity Developer is available for download.

Helen · Post by **Helen** » Fri 20 Jan 2012 14:51

mindplay wrote: I'd like to have an option to disable code-generation only - not mappings; since non-generated properties are still technically part of the model, although they must be implemented manually.

The new "Generate" extended property, which allows disabling code generation, is added for entity properties and complex type properties.

This feature will be available starting from the next build of Entity Developer.
We will notify you when it is available for download.

mindplay · Post by **mindplay** » Fri 20 Jan 2012 15:08

I named mine "Unimplemented", but I can probably search/replace in the file and reverse "True" and "False" to port my existing model

Helen · Post by **Helen** » Fri 27 Jan 2012 12:47

New build of Entity Developer 4.2.120 is available for download!

It can be downloaded from http://www.devart.com/entitydeveloper/download.html (the trial and free versions) or from Registered Users' Area (provided that you have an active subscription).

For the detailed information about the improvements and fixes available in Entity Developer 4.2.120, please refer to
http://www.devart.com/forums/viewtopic.php?t=23252

mindplay · Post by **mindplay** » Fri 03 Feb 2012 15:23

You did not implement optional code-generation for navigation-properties.

You already have a property named "Generate" on navigation properties - that's why I named this option "Unimplemented" in my own implementation; since you're already using the term "Generate" on navigation-properties, it's ambiguous...

(by the way, setting the "Generate" option on a navigation-property to false via the property-sheet, causes an error-message.)

Helen · Post by **Helen** » Mon 06 Feb 2012 13:32

Thank you for your report. We will investigate the situation.

mindplay wrote:by the way, setting the "Generate" option on a navigation-property to false via the property-sheet, causes an error-message

Please specify the exact text of the error message you received.

mindplay · Post by **mindplay** » Mon 06 Feb 2012 13:57

Something like object does not exist.

My guess is, when "Generate" is unset, you're deleting an object, or something gets removed from the property-sheet that is still referenced - and right after the property-sheet updates, something attempts to access a property on the object that was removed...

Helen · Post by **Helen** » Wed 29 Feb 2012 09:04

We have added the new "Unimplemented" extended property, which allows disabling code generation for navigation properties. In addition, the "Generate" extended property, which allows disabling code generation for entity properties and complex type properties, is renamed to "Unimplemented" now.

We will inform you when the corresponding build of Entity Developer is available.

Helen · Post by **Helen** » Fri 16 Mar 2012 09:15

Entity Developer 4.3 is released!
The new build can be downloaded from http://www.devart.com/entitydeveloper/download.html (the trial and free versions) or from Registered Users' Area (provided that you have an active subscription).

For more information, please refer to http://www.devart.com/forums/viewtopic.php?t=23647 .