I have a use-case where the "href" of the forms in the Thing Description must contain the MAC address of the device (or some ID unique to that device). The form description would look as follows:
"forms": [
{
"op": [
"readproperty"
],
"href": "/things/01-02-03-04-05-06/properties/temperature",
"contentType": "application/json",
"mqv:controlPacketValue": "SUBSCRIBE"
}
]
I think it would make sense to use a placeholder for the MAC address like this
"href": "/things/[MAC]/properties/temperature"
The device would then replace the placeholder with its own MAC. This way, the Thing Description doesn't have to be adjusted when a different device is used.
Does the WoT specification consider the use of such placeholders in the Thing Description? Does anything speak against the Thing modifying its own Thing Description?
This idea might also be expanded to having the Thing setting other attributes in the TD, to the Thing completely generating its own TD (although the effort for this stand in no relation to the use, in my case).
Version 1.1 of the TD specification defines Thing Models (https://w3c.github.io/wot-thing-description/#thing-model) where such placeholders can be used. However, Thing Models are not exchanged with usual WoT Consumers since they would expect no out-of-band information other than security credentials. You can however think of a mechanism that sends a Thing Model and a placeholder map that can be used to generate a TD with concrete endpoints.
Regarding how a TD can be managed, especially updated, it is a bit tricky. You need to think that there are WoT Consumers that consume a TD and do not have a way of handling changes, i.e. being notified of updates and how to incorporate those updates into the Consumer application logic. You can also look at https://github.com/w3c/wot-thing-description/issues/1174 . The Discovery specification has started working on how TDs are managed though, you can look at https://w3c.github.io/wot-discovery/
Related
We have the requirement, that we shall host an SAPUI5 application inside a java-application's host, which our vendor offered to us by implementing and exposing jxbrowser.
This vendor's java application offers an api, which can be accessed from within our SAPUI5 application.
This java api offers also an environment (or config-settings), where, amongst a rich set of settings, also a user language can be obtained.
And this language is neither a sap-logon language param nor is it guaranteed to be always the language which is set up in the "jx-browser" ( if possible at all, like in all real browsers ), and it uses the standard i18n _xy_AB acronym's naming style.
And I want to load the proper i18n_xy.properties at onInit of my first view and set them in the code.
We do have currently 4 of them ( _de,_it,_fr ), and the fallback is also present.
I am a little idiot, because I found some quick n dirty code, but this was about one month ago and I simply forgot the link and all of that. So now I need to ask( and maybe even for a best practice solution to this...)
So, additionally, another (my personal) requirement is, that, once I retrieve the right i18n file, I want to set it, in a way, that, whenever later on, I would use
info = this.getView().getModel("i18n").getResourceBundle().getText("obfuscated");
I always obtain the right text in the right language.
What I think of, is: Load the proper file ( according to the environment settings from the api ) in onInit, set this i18n as the proper one for the rest of the application's runtime and use a easy name for it, which will then be referred to as, maybe this:
info = this.getView().getModel("i18n_loaded").getResourceBundle().getText("obfuscated");
Is this possible, is this the right way, and , if not, which one is, according to some kind of guidelines, the best practice for this scenario ?
You can pass the parameter in the url:
sap-ui-language=en
Or set the default language in your JavaScript code:
sap.ui.getCore().getConfiguration().setLanguage("en-US");
I was not completely aware, that the determination of the used locale also works the other way around.
Meaning, if the ressource bundle contains e.g. 4 i18's,called i18_en, i18_it, i18_de, i18_fr, and the either the app is set up by
sap.ui.getCore().getConfiguration().setLanguage("en-US");
or the url-param, this not only means, that:
All ui-elements will be translated propery, once the locale's acronym is properly spotted
ALSO this is automatically replaced by the proper spotted ressource file and the translated text is retrieved properly....
info = this.getView().getModel("i18n").getResourceBundle().getText("obfuscated");
I was aware of how this fallback determination of a locale works, but I was not aware that it works also the other way around.
I close my question and i do not care about any rewards.
As our team ( namely myself and two other developers ) spiked on PACT past week or so, one of the areas of concern is not having the ability associate parameters to provider states. The absence of this key feature ( which is slated for version 3 release ), we likely will not get buy in from each of our respective service sub-teams.
#MattFellows - Any projections on when version 3 might be available for Go? Any chance we can get this feature earlier?
Allow multiple provider states with parameters
In previous versions, provider states are defined as a descriptive string. There is no way to infer the data required for the state without encoding the values into the description.
{
"providerState": "an alligator with the given name Mary exists and the user Fred is logged in"
}
The change would be:
{
"providerStates": [
{
"name": "an alligator with the given name exists",
"params": {"name" : "Mary"}
}, {
"name": "the user is logged in",
"params" : { "username" : "Fred"}
}
]
}
You are correct in that it won't be available until version 3.
You can still achieve what you are after, however. The state itself is just a handle for the Consumer to some set of data on the Provider - that can be a one-to-one or one-to-many mapping - it's completely up to you.
Typically the Provider is notified of the state during verification, it will then setup a test data fixture (often seeding a database) that sets up the 'state' of the entire system based on that reference, which allows the Consumer test to run.
Whilst the ability to pass through parameters and multiple states is nice, it's somewhat an advanced feature and I very much doubt this will be the first problem you run into as a team. I've never needed to use them myself.
For a crude but effective example of this, take a look at the gin code in the examples folder of the project.
I'd like to know if it's possible (or even correct) to use embedded documents as reference in other documents.
I know I can move the embedded document to its own collection but the main goal is to have the performance benefit of embedded document and also avoid duplication.
For example:
User
{
_id: ObjectId("4fed0591d17011868cf9c982"),
_class: "User"
...
addresses: [ {
_id: ObjectId("87KJbk87gjgjjygREewakj86"),
_class: "Address",
...
} ]
}
Order
{
_id: ObjectId("gdh60591d123487658cf9c982"),
_class: "Order",
...
address: ObjectId("87KJbk87gjgjjygREewakj86")
}
Your case reminds me of the typical relational approach, which I was a victim of, too, when starting to use document-oriented DBs. All of your
entities in the example are referenced, there is no redundancy anymore.
You should start to get used to the idea of letting go normalization and starting to duplicate data. In many cases it is hard to determine which data should be referenced and which should be embedded. Your case tends to be quite clear, though.
Without knowing your entire domain model, the address seems to be a perfect candidate for a value object. Do not maintain an Address collection, embed it within the user object. In Order, you could either make a reference to the user, which gives you implicitly the address object and might make sense, since an order is made by a user.
But...I recommend that you embed the address entirely in the Order. First, it is faster since you don't need to resolve a reference. Second, the address in shipped orders should never change! Consider orders of the last year. If you hold a reference to the address you would lose the information to which address they were shipped, once the user changes his address.
Suggestion: Always take a snapshot of the address and embed it in the Order. Save the MongoDB ID of the user as a regular string (no #DBRef) within the `Order. If a user should change his address, you can make a query for all non-shipped orders of that user and amend the address.
Since you asked if this is even correct, I would say, gently, "No." At least not typically.
But if you did want to insist on using an embedded address from user:
You can reference the user embedded address in the Order object, just not the way you might think! If you stored the id of the user in the order (it should already be there if Order belongs_to User), then you merely use user.address instead of copying the address instance as you have done.
ALTERNATIVE
I hope to illustrate a better approach to modeling the domain...
A more common approach is to instantiate a new order object, using the user's address as the default "ship to" address for the order, yet allow the user to override the shipping address if desired. In theory, each order could have a different "ship to" address.
Just because two classes have an address, does not mean they are necessarily the same address.
COMMENTARY
Orders are more of an historical document, versus one that changes. Therefore, Orders are generally immutable once placed, your model allows the address to change every time the user changes their address. That change ripples into the Orders, and would be incorrect insofar as normal order business logic goes.
Assume your address last year was in Spain and you had Order #1 show Spain when you ran a report of Orders last year. Imagine if your address this year is now Portugal and Order #1 now shows Portugal in the same report. That would be factually incorrect.
BTW: #Matt gave you the tip that from a "problem domain" perspective, you likely do not want to model it as you have. I am merely elaborating on that...
Since I got no answer I will post here how I did it. If you have a better solution I am happy to here it.
It looks like there's no way to create/reference a collection inside another collection, so I had to extract the addresses from the user collection to it's own collection and create a reference in the User and Order collections as mentioned here. I was expecting something more flexible, but couldn't find one.
User
{
_id: ObjectId("4fed0591d17011868cf9c982"),
_class: "User"
...
addresses: [ {
"$ref" : "addresses",
"$id" : ObjectId("87KJbk87gjgjjygREewakj86")
} ]
}
Address
{
_id: ObjectId("87KJbk87gjgjjygREewakj86"),
...
}
Order
{
_id: ObjectId("gdh60591d123487658cf9c9867"),
_class: "Order",
...
address: {
"$ref" : "addresses",
"$id" : ObjectId("87KJbk87gjgjjygREewakj86")
}
}
I am confused about wiring up my own datasource to the Kendo Scheduler. I looked at their API and I'm still confused. For instance, I see it says the start and the end are required, but are they the names of the fields in my dataset? They can't be mapped to another name?
My dataset has some other details as well as a date in the format, "2016-10-20T00:00:00." Is this going to work?
Can someone tell me if the actual field names from the DB/JSON are literally the same as in Telerik's docs? For instance, my date field isn't called "Start" and End. It's something else, and I don't even have an end, and I don't have starttimezone and endtimezone, are these all needed?
Another question I have is: I'm not limited to just the fields from their documentation am I? I have a datasource that has other things, for instance, we don't have "title," we have something else. And riding off that question, I'm hoping that when I call the pop up when the user double clicks on a time/day or event, that I can customize what fields I want to appear.
The other question is: What is the "from" attribute/property for? For instance
end: { type: "date", from: "End" },
Thanks
My two cents on this:
I think the options "Title", "Start" and "End" are the ones that are always needed on the dataSource. "startTimezone" and "endTimezone" are not always needed.
I also think that the "from" attribute/property is a reference to from where you are getting that data. I mean, which field from the database guards a specific information.
You can also have your own custom fields to the model, as long as they came from a valid field from the database and as long as they have an correspondent and valid datatype value.
At last but not the least, you can also customize what fields you can make appear once you do double-click and the pop-up window shows up. For that, you must use your own template for a custom pop-up editor.
Hope this gives you some insight.
Thanks for the help. I figured out the core issue with the error. It was a matter of me tweaking my schema model.
I want to use custom error messages for validation constraints on dozens of fields in my project.
I do not want to set the message on every one of these, because that would be a blatant violation of DRY. Repeating the same string in every declaration like: #NotNull(message="custom msg") would mean that if I decide to change the message in the future I'd have to hunt them all down replace them, but even worse I might use the wrong string on some of them and be inconsistent.
How do you deal with this?
Is the best option really to extend every symfony stock constraint and set my default there, and use my own custom annotation class?
Please note that using the translator is not an option for me, so I am looking for a solution that does not include the symfony translation component.
Thanks a lot for the help in advance.
Assuming you are working with English as the app's language, and you've configured translator: { fallback: en }, you can override these constraint messages universally. Start by creating this file: app/Resources/translations/validators.en.yml
And use the following translation format:
This value should not be blank.: Your custom message here
Whatever the standard message is.: Another custom message
This also works for any other language setting, assuming you've made a validators.lang.yml for it!
You can also place this file in your bundle directory under Resources/translations, and a few other places.
You can read more about this here!