So I have an product and want to change the position of its images and swap the cover image, while adding some more images to the medias assigned to the product.
The media should look somewhat like this:
{
"media": [
{
"id": "a060944a2938442c8d461b3a0107ecf5",
"mediaId": "722d194bfbb84dc489f9f5b74da53bb3",
"position": 1
},
{
"id": "b060944a2938442c8d461b3a0107ecf6",
"mediaId": "822d194bfbb84dc489f9f5b74da53bb4",
"position": 2
}
],
"coverId": "a060944a2938442c8d461b3a0107ecf5"
}
and change to this:
{
"media": [
{
"id": "a060944a2938442c8d461b3a0107ecf5",
"mediaId": "722d194bfbb84dc489f9f5b74da53bb3",
"position": 3
},
{
"id": "b060944a2938442c8d461b3a0107ecf6",
"mediaId": "822d194bfbb84dc489f9f5b74da53bb4",
"position": 2
},
{
"id": "c060944a2938442c8d461b3a0107ecf7",
"mediaId": "922d194bfbb84dc489f9f5b74da53bb5",
"position": 1
}
],
"coverId": "b060944a2938442c8d461b3a0107ecf6"
}
I couldn't find a way to restructure the media positions and change the cover image.
So I tried to remove the media from the product, but the cover image stills stays even though the medias aren't connected to the product any more.
Also an UPDATE on the coverId doesn't seem to do the job either.
I used this to remove the images:
DELETE https://your-page.com/api/product/5efd4f22dc134ba7bf77c85f92fed0a9/media/b060944a2938442c8d461b3a0107ecf6
cover and media are two separate associations, so removing all media associations can still leave the cover association intact.
new ManyToOneAssociationField('cover', 'product_media_id', ProductMediaDefinition::class, 'id')
new OneToManyAssociationField('media', ProductMediaDefinition::class, 'product_id')
Notice how both refer to the definition ProductMediaDefinition. That means for coverId you have to provide the id of an existing product_media entity, not of a media entity.
If you have the id of a media entity, you can also create the product_media entity on the fly:
{
"id": "{productId}",
"cover": {
"mediaId": "{mediaId}"
}
}
If you want to remove the cover image without setting a new one, you can set coverId to null.
Related
I'm trying to update the pop-up note via the API. I can easily update the top box (aka the Note) but I don't see how I go about updating the pop-up section. What's odd to me is that the Note doesn't even appear in the WSE, abut when I send the update it does work.
When I retrieve the record, it also doesn't appear to send the data that I have in the pop-up section, and I'm not even clear how I can add it to the WSE.
I've tried just adding it to the JSON update with a couple different names like this (tried popupnote, notepopup), and that still goes through, but only updates the top box:
"note": {
"value": "Travis Update Test!"
},
"notepopup": {
"value": "Travis Pop update Test!"
},
Anyone know if this is possible?
The answer from Acumatica Support is below. In short you need to add a custom field in the items sectionm for the 2 notes and it works perfectly. When loading the items, if you plan to serialize into this class, add this ?$custom=Item.NoteText,Item.NotePopupText to the end of your url:
{
"id": "2a113b2c-d87f-e411-beca-00b56d0561c2",
"custom": {
"Item": {
"NoteText": {
"type": "CustomStringField",
"value": "Regular note 2"
},
"NotePopupText": {
"type": "CustomStringField",
"value": "Popup note 2"
}
}
}
}
We are using Survey Creator to allow our users to build questionnaires. However, we want to keep it simple and we don't want them to have to deal with pagination.
In other words, in the builder, we want to disable pages (showPagesToolbox = false) and have them create a set of questions all on a single page.
When we present this to respondents, we want them to see a single question per page. I.e. Q1 is on page 1, Q2 is on page 2, etc.
Does the SurveyJS library provide a way of handling this situation, i.e. here are all the questions, show them with N questions per page?
There is an option, whch allows you to automatically display one question per page. To enable this you need to set "questionsOnPageMode": "questionPerPage" on the survey level. Here's an example:
{
"pages": [
{
"name": "page1",
"elements": [
{
"type": "text",
"name": "question1"
},
{
"type": "checkbox",
"name": "question2",
"choices": [
"item1",
"item2",
"item3"
]
}
]
}
],
"questionsOnPageMode": "questionPerPage"
}
This is also configurable through the SurveyJS creator by opening the "Survey Settings" dialog, then going to the "Navigation" section, and finally setting the "Questions on page mode" value.
Unfortunately at this time there is no option to specify N number of questions per page. The documentation for this setting is here.
I've tried to find a good way to work with one to zero-or-one association.
I have two resources. The first resource has one to zero-or-one association with the second resource.
(in the example below I will use Page and Line. You can think that a Page can only have "one" or "zero" Line)
At the first moment I thought to retrieve the data by using this approach:
/api/pages/:id/
When the Page has one Line
{
"id": 1,
"name": "Test",
"line": {
"id": 10,
"name": "aaa"
}
}
When the Page hasn't one Line
{
"id": 1,
"name": "Test"
}
That way when the developer gets a list of pages he doesn't need to make more requests to the API to get the Line of each Page.
But if the page doesn't have one Line, is the best way only to avoid to show the "line" and explain it in the documentation? Or add a boolean named "has_line"?
An alternative solution would be
{
"id": 1,
"name": "Test",
"lines": [{
"id": 10,
"name": "aaa"
}]
}
and
{
"id": 1,
"name": "Test",
"lines": []
}
But if you are certain there won't be more lines later, then I would stick with your approach. You need to document it no matter which approach you choose. No need to have a hasLine boolean.
Suppose we are building one-page app with two views: list view and detail view.
In list view, we present a list of objects with just their names and maybe some more minimal data.
In detail view, we present all possible fields of particular object.
Hence the question: when we GET /api/items/, should we or should not to JSON-encode all fields of the objects listed, or just those presented in list view?
In other words, if we show list of food like
Name Price
Potato 1
Milk 2
does our API need to respond with JSON like this:
{
[
{
"name": "Potato",
"quantity": "1 kg",
"origin": "Egypt",
"manufacturer": "Egypt Farmers",
"price": 1,
"packaging": "String bag",
"_type": "Food"
},
{
"name": "Milk",
"quantity": "1 litre",
"origin": "Finland",
"manufacturer": "Valio",
"price": 2,
"packaging": "Tetra Pak",
"_type": "Food"
},
]
}
or like this:
{
[
{
"name": "Potato",
"price": 1,
"_type": "Food"
},
{
"name": "Milk",
"price": 2,
"_type": "Food"
},
]
}
The RESTful API should concentrate on the resources that are represented, not necessarily how those resources are used.
In a master/detail scenario, typically the master will contain details of the master object, and include a list of its details (including a link to the API for each detail resource. So /api/items/ might look like this:
{
items: [
{ name: 'item 1', href: '/api/items/1' },
{ name: 'item 2', href: '/api/items/2' }
]
}
The detail resource would contain properties of an individual item in the items list. So the /api/items/{itemName} api might look like this:
{
name: 'item 1',
color: 'blue',
weight: 100,
id: '/api/items/1'
}
So this would probably be closest to your second scenario. There are a number of advantages to this model: it probably matches the domain model that your api is accessing, it makes each api very simple and single-purpose, it's easy to scale, even to very large lists. The disadvantage is that it may lead to more complexity on the client.
The answer as usual may be: it all depends ;)
In case of the connection is limited or unstable (e.g. mobile connection like LTE or even wifi) the best idea is to return the whole list of resources with all fields filled and use the same data on both views. In the company I work for we often take this approach since our backend almost always provide data for mobile applications.
The second idea is to use a mechanism called field or resource expansion. In general a request is made to the endpoint and fields of resources to be returned are included in this request:
/api/items?fields=(name, quantity, origin, whatever)
This mechanism is very convenient since you can use this endpoint to server multiple views without any performance loss.
Personally I'd use two endpoints. An /api/items/ endpoint with field/resource expansion mechanism built-in (with a limited list of fields that can be expanded) and the second one /api/items/{itemID}/ to return a particular item with all the data. This is also the most RESTful approach.
We have a JSON string of articles, where each article has comments. Also, both the article and the comments contain the author/commenter information.
Because Sencha is using "id" as a model key, after Sencha loads the JSON (as shown below) the first article contains article.user but its comment objects do not contain it, e.g. comment.user does not exist. The question is how can we avoid that issue?
One approach we tried is to remove the id field from the user model and the JSON. Then, Sencha will create its own id values and in that case all the data is loaded. However, it seems that if we made a change to the article.user object we wouldn't see that change in the other user objects that (we know) correspond to the same user.
Another approach which would save bandwidth and solve the previous problem is to avoid having (potentially) multiple copies of the same user object by having a pointer to the object for those cases. In this case, the user object of the article would be loaded but the other instances would only contain a pointer to that object. The problem here is that we cannot remove the initial object.
What would be the standard way to approach this problem in Sencha Touch (2)?
{"articles": [
{
"id": "14338138",
"user_id": "1",
"title": "test",
"user": {
"id":"1545"
"first_name": "Joe",
"last_name": "Kae",
"status":"1"
},
"comments": [
{
"id": "1545",
"article_id": "14338138",
"says":"This is my first comment to my own article.",
"user": {
"id":"42",
"first_name": "Joe",
"last_name": "Kae",
"status": "1"
}
},
{
"id": "1546",
"article_id": "14338138",
"says":"This is my second comment to my own article.",
"user": {
"id":"42",
"first_name": "Joe",
"last_name": "Kae",
"status": "1"
}
}
]
}
]
});
Take a look at Sencha Docs Data.Association