|
|
| Line 5: |
Line 5: |
| For WPF, call this early in your application: | | For WPF, call this early in your application: |
| WPFDequeuer.Active = true; | | WPFDequeuer.Active = true; |
|
| |
| OCL-PS Example
| |
| Here's a small model to show how to use the PSEval value. This could also be interesting if you're working with associations.
| |
| I've created this model where web Article, SysUser - this would be the logged in user. You have comments, so this is an article where users can comment. I've added the link row name i.e. if you navigate from the SysUser to the comments. If you go from the comment to the article, that's the inner link name. That's always a good way to set up if you have a link clause like this – for associations.
| |
| How is this stored? It is stored in the database as one table for the article, one table for the SysUsers and one table for the comments. This is like two multi-links with one in one end and many here. What's going on here is that you have one comment in that table. You have one pointer to the SysUser and you have one pointer or link or ID to the article.
| |
| You need to know outside this model. The expression for that is, SysSingleton.oclSingleton.CurrentUser That's the system main thing. If you're using the standard ASB.NET thing for MDriven, you will get the Current User to point to the SysUser. The reason this is done here is so that the SysUser won't have tens of thousands of comments. In this case, we're assuming that we're not going to have huge amounts of comments for performance reasons. We select from the comments an article that, in this case, points to self. Because this navigation starts from article, the self here is article. We are looking at the Current User's comments for this article. We take the first comment because this is a collection, but we don’t know for a fact if this will be the only one. We are converting a list to the one thing we have, looking at how we can increase the performance or the performance problems that we could have here, whether we're going to show a list of articles or one article. Let's say there are a thousand comments for each article. There would be a problem because if we are showing, let's say, a hundred articles with a thousand comments, that means there's a hundred thousand comments. We need to load into memory and sum up. If we were to use, we have a view model here, the article view, that shows the content. We want to show how many likes this article has gotten.
| |
| Then, we have the list of comments which could also be a list of articles or maybe just part of the article, but we still want to show the like count. We have three different implementations of how to show the like count. One way would be to say article.comments. Select for the likes and then show the number. That would require the system to load every comment object into memory and then filter out the ones that has like that is not null and see how many they are.
| |
| Then we are thinking, let's be smart here and use PSEval value. We want an integer. We use the PSVAL value and we say self.comments. This is basically the same as what would be in the OCL. The OCL would load all the objects. PS for persistent storage says that we can just do this in SQL and not load the objects. We take the comments, select the ones who are liked and take the size of it. In this case, we are also subscribing to the article. I don't know if this would make any difference here, but it means that this would be re-evaluated if the article changes.
| |
| Anyway, this will work well to show how many likes you have. But if this user that we are looking at, likes or unlikes it, this value would not change. You would have a non-responsive UI because if the user then uses this action toggle like and toggle like here would be like this. It would change from like to turn on and off the like to date here. It wouldn't update the user interface that we can see here. It would stay the same. Why? Because it is just not re-evaluated because there is nothing triggering the re-evaluation. If we were to add all the comments here as a way to say when to recalculate that would defeat the purpose because then we still load all the objects to look at them.
| |
| What can we do? Well, we could, for example, say that we will use PSVAL to get all the comments for this article into memory, but only the ones that have like on them. It would still load objects, but it wouldn't load all of them, only the liked ones up to 9,999 in this case, and then we would take the size of that. The thing here is that that would actually kind of work much better with ourselves because at least if we had liked it before, how our object would be in those objects being used here to sum up things. By loading the objects, we can take this size here after we have loaded the objects. In this case, it would be better.
| |
| In this case, we combine OCLPS and PSEval with OCL. Let's first pick out the comment, the user I have made this my comment. Then we take and we find take comments and we find all the objects that have liked on it except my comment object. We sum this up. I can see here that this doesn't matter. It's actually going to return an in 30 truths. So maybe we should have an integer here. The size is in 32. Let's go with in 32 and still something is wrong. Let's keep that to comment now.
| |
| In this case, we're getting the objects and we're taking the size of the object. We're loading all the objects. This is not what I want - there's one more thing we can do here. We load all the objects except my own objects, which is here except that one. And then we add my own comment, liked status manually. This will be executed in OCLPS, this part, and this part will be in OCL. And then the next variant here would be to have this as an integer. We have size here instead and we don't need this. Now this should be PSEval value. This is a mix of things. In this case, we have the integer and we calculate the value of every comment except mine. And then in OCL, which is auto-subscribed, we calculate the liked form for only my comment.
| |
| The effect of this will be that the UI will update when I like or unlike, but if someone else does it, it won't update until my session reloads this for some reason. It will feel like it's responding right away to my like setting, but to other like settings, it will be a delay because it will only reload when this value is needed the next time. It's slightly off, but I don't think anyone will notice and it's a huge performance boost.
| |
|
| |
|
| |
|
| |
| [[Category:MDriven Framework]] | | [[Category:MDriven Framework]] |
DisplayQueue is part of the coding framework for MDriven Framework. It implements the databinding updates async to avoid thrashing the UI with updates that may be passing states. For example, if you looped this command x:=x+1 - we do not want to force UI updates for each loop.
DisplayQueue polling is different on different UI implementations.
For WPF, call this early in your application:
WPFDequeuer.Active = true;
