Accessing your "calling" event info in a condition

Feb 6 at 7:01 PM
I'm looking to handle the Element Instantiated and removed events in a condition. It's not clear to me what has to be imported to get access to those events, in particular the sender of the event. What should I be importing?
Coordinator
Feb 7 at 9:10 AM
Hmm, not sure I yet understand the question.
Are you saying that you want access to the event that is raised in the condition that determines whether to execute the eventlaunchpoint for it?
Can I ask what you are trying to do here? Sounds like a scenario we haven't heard of yet.
The event only contains a reference to the current element which you already have in the condition.

For the current element just import IProductElement as usual.

You could also take a look at the EventSenderMatchesElementCondition.cs to see how it imports the event and current element for what it is doing which maybe close to what you want: https://nupattern.codeplex.com/SourceControl/latest#Src/Library/Source/Conditions/EventSenderMatchesElementCondition.cs
Coordinator
Feb 8 at 10:08 AM
OK, we spoke on Skype about this inquiry.
I just wanted to document the highlights here for others.

Over the years I've had several people pursue a similar line of enquiries about events and synchronizing properties between elements in the model so that generation of code is accurate as properties are adjusted. This the just in time codegen pattern for want of a better term. Whilst this is possible, and supported, it requires a lot of custom automation to be written by the toolkit owner, and some understanding of the underlying modelling rules and constraints in Visual Studio. And whilst that is possible, it is still not simple to achieve, and leads to other difficulties as the complexity of the toolkit increases.

What we recommend to avoid all this is a simple "code generation policy" that avoids unnecessary synchronization, that just works for most toolkits most of the time (80-20 rule). At least, to start with that before judging it no longer suitable, and then resort to more complex automation.

The policy is simply this: Generate (re-generate) all code from all elements/collections every time the solution is built. In fact, just before it compiles.
Do this by hooking the OnBuildStarted event in the launch points for each CodeGen command you have on any element in your model.
Turn on validation at the pattern element, add validation rules to all element and properties that must be correctly configured to generate correct code, and ensure you use the ValidElementCondition on the launch points to ensure the model is valid before the generation commands are invoked.

In this way, all the code is generated at the same time. All value providers are evaluated at that point (all dependent properties are resolved), and all the T4's can navigate the model freely to extract the values of properties and elements from anywhere at that point, without requiring complex synchronisation. Validation is also run just prior to ensure the toolkit user has good values.

Its a proven successful pattern for most toolkits that are generating code.