Is it possible to access a property which is located in a ViewModel from outside of the ViewModel? I'm running a check (TriggerAction) on one of my entries, and I need to access a property (a double) from my ViewModel, which I need to use to limit my numeric entry. I was able to come up with a way to actually limit my entry to not go above a certain number, but I need it to not go above this specific number from my ViewModel.
Related
I'm struggling to understand how to use UICollectionViewDiffableDataSource and NSDiffableDataSourceSnapshot to model change of items.
Let's say I have a simple item which looks like this:
struct Item {
var id: Int
var name: String
}
Based on the names of the generic parameters, UICollectionViewDiffableDataSource and NSDiffableDataSourceSnapshot should operate not with Item itself, but only with identifier, which Int in this example.
On the other hand, again based on names of generic parameters, UICollectionView.CellRegistration should operate on complete Item's. So my guess is that UICollectionViewDiffableDataSource.CellProvider is responsible for finding complete Item's by id. Which is unfortunate, because then aside from snapshots, I need to maintain a separate storage of items. And there is a risk that this storage may go out of sync with snapshots.
But it is still not clear to me how do I inform UICollectionViewDiffableDataSource that some item changed its name without changing its id. I want UICollectionView to update the relevant cell and animate change in content size, but I don't want insertion or removal animation.
There are two approaches that would work solve your problem in this scenario.
The first is to conform your Item model to the hashable protocol. This would allow you to use the entire model as an identifier, and the cell provider closure would pass you an object of type Item. UICollectionViewDiffableDataSource would use the hash value for each instance of your model (which would consider both the id and name properties, thereby solving your name changing issue) to identify the data for a cell. This is better than trying to trick the collection view data source into considering only the id as the identifier because, as you stated, other aspects of the model might change. The whole point of structs is to act as a value-type, where the composition of all the model's properties determine its 'value'...no need to trick the collection view data source into looking only at Item.id.
Do as you said, and create a separate dictionary in which you can retrieve the Items based on their id's. While it is slightly more work to maintain a dictionary, it is a fairly trivial difference in terms of lines of code. All you should do is dump and recalculate the dictionary every time you apply a new snapshot. In this case, to update a cell when the model changes, make sure to swap out the model in your dictionary and call reloadItem on your snapshot.
While the second option is generally my preferred choice because the point of diffable data source is to allow for the handling of massive data sets by only concerning the data source with a simple identifier for each item, in this case your model is so simple that there's really no concern about wasted compute time calculating hash values, etc. If you think your model is likely to grow over time, I would probably go with the dictionary approach.
I am trying to configure the UiPath get queue items activity but when I specify the QueueItemData variable as the output it gives a warning asking for a generic IEnumerable object.
What is the proper UiPath queue object to use when a IRnumerable object is required?
You can simply use IEnumerable<UiPath.Core.QueueItem> as type for your variable. A simple way to create a suitable variable is to hit CTRL+K in an appropriate property field, like this:
Studio will then automatically add the variable after hitting Enter. You may need to change the scope manually.
You will want to use IEnumerable<UiPath.Core.QueueItem>.
Essentially, you can read that as this is an iterable collection that contains nothing but UiPath.Core.QueueItem objects.
Beware of Imposters
Be careful when you choose the generic type associated with the IEnumerable class though. There are many similarly named classes that can cause confusion, and if you choose the wrong one you'll end up with an error about being unable to case between one and the other.
Automatic Type Setting
When in doubt, allow the UiPath Studio tool to set the type for you. Just move the cursor into the input window for the field in question in the Properties tab and type set var: items. UiPath Studio will then register the variable and set the object type to the appropriate class. This takes the guess work out of figuring out which type to use.
I want to declare a variable whose value can be displayed anywhere in app (on any page) and can be modified from any micro flow. how can we do that??
As all mutable values in mendix are represented by attributes in an entity, you need to create an entity in order to be able to modify a value. The closest thing to a global variable in Mendix is an attribute on a singleton entity.
Let's suppose we want to be able to change the some settings of your app through its UI or within a microflow. To do this we can create an 'AppSettings' entity with attributes for all the different "global variables" that need to be set.
To make it a singleton entity we need to make sure that there is only one object of its kind in the database. To do this it's a common practice to implement a 'GetOrCreate' microflow that retrieves the 'AppConfiguration' object from the database and creates one if there is none yet.
We can now use 'GetOrCreateAppConfiguration' anywhere, where we need to read or modify our app settings, such as a microflow.
Using'GetOrCreateAppConfiguration' we could also create and settings page, where admins can modify the AppConfiguration attributes using a DataView with a Microflow retrieve.
We can also use a dataview to display the AppName "global variable" to users and use conditional visibility based on feature flag "global variables" to show or hide UI elements. Note that this means that we should probably not to give regular users write access to 'AppConfiguration' attributes.
In order to allow us dynamic control over labels and error messages, we created a custom DataAnnotationsModelMetadataProvider. In a Display attribute we store the key in the Name property and using the custom DataAnnotationsModelMetadataProvider we substitute the key for a string value from our custom CMS. The problem is that we now have two sets of values. One for Web views and one for mobile views. At runtime we check if the client is on a mobile device and substitute the values accordingly.
After test running this setup I came across a strange issue. When the AppDomain is first created and the Name properties of the different data annotations are replaced with the string values, everything works fine. In debug, when I enter the custom DataAnnotationsModelMetadataProvider for a second time, I see the name properties already populated with the values I had substituted the previous run. This was strange to me, since it was my understanding that data annotation propeties could not be chnaged at runtime. It now seems like there is a model metadata cache happening somewhere. Since I based my custom solution on replacing the values each time the DataAnnotationsModelMetadataProvider is called upon, I would like to disable this caching, if possible.
For now I started using the ShortName property as my key storing property and I replace the Name property, and this way I can repopulate the strings on each run. But this was not the initial design and I don't have such a key store property for ValidationAttributes.
So is there a way to disable this cache? I don't need the cache for the sake of caching, since all CMS data is cached in memory in another layer anyway.
It seems like I can declare computed properties in the model and in the controller. I'm getting to the point where I'm not sure which one to look in for a given property.
What dictates whether a property should be placed in the controller vs the model?
Typically, place in the controller if the property is presentational in nature (e.g. display, labels, formatting), and place in the model if the property is inherent to the record itself (e.g. calculations, associations)
In practical terms though:
Model if the property
needs to be accessed by other models, since models don't have access to their controllers
needs to be accessed in routes before controllers are setup
needs to persist across controllers (e.g. order.subtotal is used in OrderNewController and OrderController)
Controller if the property
only needs to be accessed by the view or template
only needs to be accessed by other controllers
You can probably go with putting most properties in the controller, until you run into situations where you need to access the property from other models, or if you find yourself writing {{controllers.modelName.property}} too many times.