This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi, I'm attempting to customise the code generation templates and was wondering if there's any possibility that you could add the ability to define a Designer Extension Property on a relationship - at the moment I can only choose "Entity" or "Field" for the target of an Extension property. I'd like to be able to define a property that will control if a relationship is generated (during DTO generation/serialisation). I was going to use the EagerLoad attribute to signal this, but then I fear I'll compromise the effectiveness of the 2nd level caching I've configured...
Cheers, |
|
|
Hi Greg, I've added this for one-to-many associations, beginning in the next nightly build. Note that extension properties that you specify on an association will be available on the collection, backreference and foreign key field, so if you need to be able to specify different values on (say) the collection and backreference, you'll need to create two extension properties (e.g. CollectionIncludeInDto and BackreferenceIncludeInDto) and check for these separately in the appropriate places in your templates. We have to implement extension support separately for each kind of association, so I've not yet implemented it for one-to-one associations or through associations. If you need these as well, let me know. |
|
|
Ivan, This is working perfectly for One-To-Many relationships. Could you also implement this for through associations, as I do have several through associations in my model too? |
|
|
Hi Greg, Through association support will be in tonight's nightly, but I'd appreciate some feedback on the design. As you're aware, there are two ways to represent a through association in the designer: with the through entity, and the one-to-many associations to the through entity, explicitly represented on the diagram; or with an 'auto' through entity not displayed on the diagram surface. Both of these result in the same thing at the template (generated code) level, but obviously in the second case you don't have access to the through entity and one-to-many associations at the designer level. The way I currently have extension properties working on through associations is that they are exposed to the template on everything that is generated from the through association. That means that with an explicit through entity, the extension property will appear on the TA, but NOT on the one-to-many associations or FK fields (because they're explicitly modelled separately from the TA). But with an auto through entity, the extension property will appear on the TA, the OTM associations and the FK fields. This maximises flexibility for users of auto through entities, but it feels a bit inconsistent and hard to explain. It might be more consistent for us to surface the TA extension properties only on the TA, and if you wanted to customise the OTM associations and FKs that underlie the TA, you would have to use an explicit through entity. As a user, do you think this change would make it easier to understand and remember the behaviour? I have to admit I'm beginning to lean towards it myself... |
|
|
Hi Ivan, Only just getting back to looking at this. I'm happy with how its working now, but I it takes a couple of reads to understand it, and it may not be the most intuitive. On a related topic, there doesn't seem to be a way to determine (in the NVelocity template) which end of a ThroughAssociation you are dealing with. In the designer (and it seems the underlying model xml), ThroughAssociations have an implied direction - they refer to a Source and Target. However, in the template, there are two ThroughAssociationModels - one from the perspective of each related entity. To me, the current ThroughAssociationModel is flawed, in that the TargetEntity property changes depending on which end of the logical association the ThroughAssociationModel represents. Ideally it may have been better to have the current ThroughAssociationModel implemented as ThroughAssociationEndModel with both ThroughAssociationEndModel's related to a ThroughAssociationModel representing the original TA. I imagine you'd be resistant to this sort of refactor of the generation models though... In my specific case, I am attempting to use two custom designer properties on ThroughAssociations - called IncludeSourceCollectionInDTO and IncludeTargetCollectionInDTO controlling generation of the DTOs at the respective ends of the TA. Can you think of any alternative way to accomplish this sort of thing given the limitations identified above? Cheers, |
|