Is there any guidance or documentation for which classes in TOM.NET replace the functionality in the legacy COM API for Tridion?
I'm having trouble finding the entry point corresponding to TDSE.
The closest class you have to the good old TDSE is the Session class, which exposes most (if not all) of the "system-level" methods and properties (like current User, WorkflowManager, etc).
In Event Systems you get a session as part of the Subject - all classes derived from IdentifiableObject expose a Session property - and this Session will be running under the identity of the user that caused the event to be triggered. In TOM/COM days, this was not always the case, and very often you had to call .Impersonate in your code to act as the current user. With TOM.NET this is not required anymore, as long as you use the correct session.
Good luck with your upgrade, the new Event System engine is worlds apart from the old one, there really is no turning back.
The TDSE object does not really exist in TOM.NET. The closest object you have is the Session class, although you may not need it as you will receive the target object as the subject parameter of your handler. Try reading this article by Bart:
https://sdltridionworld.com/articles/sdltridion2011/sdltridion2011eventsystem.aspx
The article has a good overview on setting up the event handlers, and a link to a matrix document mapping old COM driven TOM based event systems to the new methodology of the new TOM.NET based event handlers.
Have a look at Rob Curlette's post about performing an upgrade to 2011. It discusses the upgrade of the event system:
http://www.curlette.com/?p=90
Bart has also provided a table that maps old events to new ones:
http://sdltridionworld.com/images/event_matrix_tcm89-18738.pdf
Hope this helps get you started!
Related
I'm implementing an Alexa search skill for a website. My question is that there is some kind of possibilities to give intents some kind of scopes, so built in Intents could be reused?
I mean, for ex. the AMAZON.YestIntent to have different functionalities on different situations.
You can handle this in your intent handler. You can save context information in the session or a database if you are using one. Then in the intent handler, test the session or DB data to determine which response to take.
For example, in the Who's On First? Baseball Skit skill, the dialog between the user and Alexa is about 85 lines long. The user can say "who?" at several different places in the dialog, and Alexa needs to respond differently depending upon which line of the dialog they are at. To handle this, I simply save the line number in the session. Then when an intent is called, the intent handler gets the line number session variable, uses it to select the appropriate response, and increments it and passes it along in the session for the next line.
It really depends on the complexity of your skill, the accepted answer is a perfectly correct implementation for a simple flow and it starts to address keeping state tied to the session.
If your skill is more complex and you're using Node.js, I would suggest using the official SDK which offers this functionality out of the box:
https://github.com/alexa/alexa-skills-kit-sdk-for-nodejs
The state management allows you to define which intents should be handled in each state and the rest can be passed to a context-specific handler. More information is here:
https://github.com/alexa/alexa-skills-kit-sdk-for-nodejs#making-skill-state-management-simpler
The state management takes a little getting used to, but once you have used it, you won't go back because of the control it offers you over the experience.
What is the difference between MVVM messaging and RaisePropertyChanged.
I'm trying to run a function in View model A when a property in view model B changes, which approach is a better one to use - Messaging or RaisePropertyChanged broadcast?
Thanks,
Nikhil
Messaging decouples your view models. It's like a Tweet, you send out a message into the air and someone can read it or someone could register to listen for it. PropertyChanged is used by the UI to know that something changed and to redraw the values.
Messaging is definitely the best choice. MVVM light has a built in option to broadcast the message. You can use the mvvminpc code snippet.
It's surprising your post wasn't answered sooner. Maybe this answer will still be useful to someone out there.
To follow #Kevin's post:
Messages are indeed used for decoupled comunication. This means that once the message is sent one or more recipients - who have registered their interest in a particular message type - are notified.
In general I use INotifyPropertyChanged when the comunication between the view and the view-model is concerned (via databinding) and messages when I want to communicate between multiple view models or upward from the view-model to the view and databinding is not concerned.
When receiving messages in the view model make sure that you call Cleanup to unregister from the Messenger. If you handle the message in the view - where no Cleanup is available - register for the Unloaded event and call Messenger.Unregister(this) from there.
Depends on how View model A and View model B relate to each other.
If View Model A already has direct reference to B for a valid reason (e.g. A "owns" B i.e. it is parent-child relationship) then just subscribe to B.PropertyChanged event. That way B doesn't need to remember that something depends on it which is in spirit of reactive programming.
(offtopic: in case if B has longer lifetime than A then don't forget to unsubscribe from event because "long living publisher / short living subscriber" can result in memory leaks).
If A and B are unrelated / in very different parts of the app then messaging might be a better choice.
Messaging should be used when it is solving a specific problem. If you uses it everywhere your application becomes difficult to maintain and later understand the code.
suppose I have a domain classes:
public class Country
{
string name;
IList<Region> regions;
}
public class Region
{
string name;
IList<City> cities;
}
etc.
And I want to model this in a GUI in form of a tree.
public class Node<T>
{
T domainObject;
ObservableCollection<Node<T>> childNodes;
}
public class CountryNode : Node<Country>
{}
etc.
How can I automatically retrieve Region list changes for Country, City list changes for Region etc.?
One solution is to implement INotifyPropertyChanged on domain classes and change IList<> to ObservableCollection<>, but that feels kinda wrong because why should my domain model have resposibility to notify changes?
Another solution is to have that responsibility put upon the GUI/presentation layer, if some action led to adding a Region to a Country the presentation layer should add the new country to both the CountryNode.ChildNodes and the domain Country.Regions.
Any thoughts about this?
Rolling INotifyPropertyChanged into a solution is part of implementing eventing into your model. By nature, eventing itself is not out of line with the DDD mantra. In fact, it is one of the things that Evans has implied that has been missing from his earlier material. I don't remember exactly where, but he does mention it in this video; What I've learned about DDD since the book
In and of itself, impelemnting an eventing model is actually legitimate in the domain, because of the fact it introduces a decoupling between the domain and the other code in your system. All you are doing is saying that your domain has the capability of notifying interested parties in the fact that something has changed. It is the responsibility of the subscriber, then, to act upon it. I think that where the confusion lies is that you are only using an INotifyPropertyChanged implementation to relay back to an event sink. That event sink will then notify any subscribers, via a registered callback, that "something" has happened.
However, with that being said, your situation is one of the "fringe" scenarios that eventing does not apply all that well to. You are looking to see if you need to repopulate a UI when the list itself changes. At work, the current solution that we have uses an ObservableCollection. While it does work, I am not a fan of it. On the flip side, publishing a fact that one or more items in the list have changed is also problematic. For example, how would you determine the entropy of the list to best determine that it has changed?
Because of this, I would actually consider this to not be a concern of the domain. I do not think that what you are describing would be a requirement of the domain owner(s), but rather an artifact of the application architecture. If you were to query the services in the domain after the point that the change is made, they would return correctly and the application would still be what is out of step. There is nothing actually wrong inside the world of the domain at this momeent in time.
So, there are a few ways that I could see this being done. The most inefficient way would be to continually poll for changes directly against the model. You could also consider having some sort of marker that indicates that the list is dirty, although not using the domain model to do so. Once again, not that clean of a solution. You can apply those principles outside of the domain, however, to come up with a working solution.
If you have some sort of a shared caching mechanism, i.e. a distributed cache, you could implement a JIT-caching/eviction approach where inserts and updates would invalidate the cache (i.e. evict the cached items) and a subsequent request would load them back in. Then, you could actually put a marker into the cache itself that would indicate something identifiable as to when that item(s) was/were rebuilt. For example, if you have a cache item that contains a list of IDs for region, you could store the DateTime that it was JIT-ed along with it. The application could then keep track of what JIT-ed version it has, and only reload when it sees that the version has changed. You still have to poll, but it eliminates putting that responsibility into the domain itself, and if you are just polling for a smaller bit of data, it is better than rebuilding the entire thing every time.
Also, before overarchitecting a full-blown solution. Address the concern with the domain owner. It may be perfectly acceptable to him/her/them that you simply have a "Refresh" button or menu item somewhere. It is about compromise, as well, and I am fairly sure that most domain owners would have a preference of core functionality over certain types of issues.
About eventing - most valuable material I've seen comes from Udi Dahan and Greg Young.
One nice implementation of eventing which I'm eager to try out can be found here.
But start with understanding if that's really necessary as Joseph suggests.
Until recently I have been using cairngorm as a framework for flex. However, in this latest project I have switched to Mate. It's` still confusing me a little as I kind of got used to leaving data in the model. I have a couple of components which rely on the same dataset(collection).
In the component the creation complete handler sends a 'GiveMeMyDataEvent' which is caught by one of the eventmaps. Now in cairngorm in my command class I would have had a quick peek in the model to decide whether I need to get the data from the server or not and then either returned the data from the model or called the db.
How would I do this in Mate? Or is there a better way to go about this, I'm trying to utilize the data that has already been recieved from the server, but at the same time I'm not sure I have loaded the data or not. If a component which uses that same data has been instantiated then the answer is yes otherwise no.
Any help/hints greatly appreciated.
Most things in Mate are indirect. You have managers that manage your data, and you set up injectors (which are bindings) between the managers and your views. The injectors make sure your views are synchronized with your managers. That way the views always have the latest data. Views don't get updated as a direct consequence of dispatching an event, but as an indirect consequence.
When you want to load new data you dispatch an event which is caught by an event map, which in turn calls some service, which loads data and returns it to the event map, and the event map sticks it into the appropriate manager.
When the manager gets updated the injectors make sure that the views are updated.
By using injectors you are guaranteed to always have the latest data in your views, so if the views have data the data is loaded -- unless you need to update periodically, in which case it's up to you to determine if data is stale and dispatch an event that triggers a service call, which triggers an update, which triggers the injectors to push the new data into the views again, and round it goes.
So, in short the answer to your question is that you need to make sure you use injectors properly. If this is a too high-level answer for you I know you can get more help in the Mate forums.
I ran into a similiar situation with the app I am working on at the moment, and found that it is easily implemented in Mate when you start thinking about having two events.
The first event being something like DataEvent.REFRESH_MY_DATA. This event is handled by some DataManager, which can decide to either ignore it (since data is already present in the client and considered up to date), or the manager can dispatch an event like DataEvent.FETCH_MY_DATA.
The FETCH_MY_DATA event triggers a service call in the event map, which updates a value in the manager. This update is property-injected into the view, happy days :)
My question is essentially the same as question 765054 on StackOverflow. I'm only asking it again because the accepted answer is incorrect (you can not access the session object in Application_BeginRequest).
Our use case is that we want to store the authenticated user's user object in the session. So in subsequent requests, we can correctly set the IPrincipal and IIdentity based on the user object in session.
Apparently AcquireRequestState is the earliest event where HttpContext.Current.Session is not null. I just attached to all of them in sequence and tested. I prefer to use PreRequestHandlerExecute which occurs before the constructor on my controller is called.
This is relevant if you would rather have your code in or referenced from the Global.asax instead. See this page for the sequential list of the events in the application lifecycle: http://msdn.microsoft.com/en-us/library/ms178473%28v=vs.100%29.aspx
I do similar things using a base controller and overriding OnActionExecuting. Whether this is the earliest it can be done or not, I don't know, but I do know that it will happen before your action is executed (and thus before the view is rendered). Alternatively you might want to have a custom authorize attribute that does what you want. This might be the only way to make sure that it's done prior to other attributes running.