I have a standard REST API list of items, each of them accessible on its URI
GET /items/1
{"item":{
"some":"data",
"selected":false
}}
Now I want to add a constraint that only one item in the list can be selected. In other words, if one item is selected, all other items should have false in their selected field. Basically it should behave like a radio button group.
I see three options how to implement it, all of them bad
Keep it as it is. If someone updates an item, the server changes the value in previously selected item. This unfortunately makes the resource not cacheable. I update one item but the other one changes its state as well.
Change the resource so the whole list is one entity. The client updates it at once and it's up to him to make sure that only one item is selected. I do not like this solution, since the items are logically separate entities and I want to access them separately.
Force the client unselect the previously selected item first and only after that let him to select the new one. It's quite complicated for the client and it can lead to ugly race conditions if more clients are trying to select an item.
Is there a better solution that I do not see?
the items are logically separate entities and I want to access them
separately.
While this may be true for individual items, it cannot really be said about their selection.
As you describe it, the selection is not really a state of a single resource. It's a property of the whole group of items.
I would therefore manage the selection by issuing POST requests to the resource representing the collection of items
POST /items?selection=<item_id>
I would also disallow the modification of the selected property by any requests to single item resources.
Perhaps it would be a good idea to remove the selected property from the representation of an item and make the selection a separate resource.
GET /items/1 - read the first item
GET /items/selected - read the currently selected one
or perhaps make the selection a property of the items resource as a whole.
{
"items" : [
{"id" : 1, "some" : "data"},
{"id" : 2, "some" : "data"}
],
"selected" : 2
}
or both, either way I wouldn't keep collection-related data in the representation of an item in the very collection.
Related
In theory what I want to achive is pretty simple:
You choose an item from a sap.m.select which is a category.
This effects which items can be selected in a second sap.m.select that contain items that still need to be requested from a backend system.
On choosing one of the items in the second sap.m.select, a backend request for the full information of the choosen item should be triggert.
This works so far as long is I change the item in the second sap.m.select manually.
But if I choose a category this applys a Filter to the model that is the source for the second sap.m.select.
The problem is: there is no change triggert when the filter is done an thus the current item of the second changed (because one item can only have one category).
I already tried a few things, starting with manually fireing the change event of the second select as soon as I it filter. But all solutions so far did not achieve what I had planned.
(in the example of the manuall fired event after the model for the second select is filtered, the selected item of the second sap.m.select is not yet set. I need that item to know which item to query)
I only have some hacky solutions remaining, like some delay for firing the change event or modifing the handler of the change event to check the model, and the filter, for the first entry and query this in case the selected item of my sap.m.select is not yet set.
But is there nothing like an onBindingUpdated handler or something like this?
I want to create a REST API with items in categories and list all categories alongside its number of items.
Schemas:
Category {id, name}
Item {id, name, categoryId}
Endpoints:
GET /categories/list
GET /categories/<id>
PUT /categories/<id>
GET /items/list[?category=<categoryId>]
GET /items/<id>
To update a category I take what I get from GET /categories/<id>, modify the JSON object and PUT it back.
So far so good.
My question is if there are one ore more best practices to retrieve the item count?
I can think of a few ways to do this:
Fire a GET /items/list?category=<categoryId> for each category, counting the resulting items.
Taking the count from a X-total-count or content range header or a total_count field returned from the endpoint will avoid having to actually load all items.
Add an item_count field to the resulting category JSON objects.
How should this read only field be handled for PUTs? Make the backend ignore it? Manually unset it?
Create a dedicated endpoint /categories/item_counts that returns a list of categories with each number of items.
I like option number 2 (e.g. the wordpress API does it this way) because it does not need extra requests. But I really dislike the idea of having a different object structure for the GET and PUT requests.
REST is really about representation of objects. Category doesn't have a count as it's a single object. Item doesn't have a count either for the same reason. Count is more like RPC where you tell the service to compute something.
GET /items/list[?category=<categoryId>]
is like RPC, passing the category parameter to the list method. Staying in that idiom, you could "chain" the methods to get the total count of items in the specified category:
GET /items/list/count[?category=<categoryId>]
although I'd use path parameters instead:
GET /items/list/<category_id>/count
but list is implied so you could remove it:
GET /items/<category_id>/count
It's straying a bit from "pure" REST but it keeps your actual REST objects clean, as you say, keeping total_count our of your Category objects.
I'm assuming you sometimes need the count but not all the Items otherwise you wouldn't need to ask the API for the count, you'd just count them yourself in the client. That suggests another option:
GET /categories/<id>/count
{
"total_count": 10
}
which fits better with the use case of finding out how many Items are in a Category.
I'm using the basic work item process in Azure DevOps.
If I look at my backlog without any filters, then it shows me a hierarchy, with epics as the top-level items, then issues and then work items.
If I filter this to only show items that are to do or doing, it shows them as a flat list, not a hierarchy.
Is there any way to see the items as a hierarchy, but filter out done items?
Update following Shayki Abramczyk's comment
The options button doesn't include an option to show parents...
Go to the Work Item Query tab and create a work item query. Configure it to Tree view and let it follow the parent/child relation.
You can filter on the top level (top part of the query editor) and the lower levels (bottom part of the query editor). Use the State in filter to select multiple states. You can't multi-select them in the UI, so typing is required:
PS: The , is the list separator in most languages, but sometimes you need to use ;.
If you want to see parents when ANY child leaf is still open, set the Filter: Match top-level items first to Filter: Match child-level items first.
To specify the order, add the Backlog Priority field to the query and use the table header to sort by it:
Or use the Sorting option in the "Choose Columns" fly-out:
Note: The exact field name differs per Process template. Backlog Priority is for the Scrum Template, Stackrank for CMMI and Agile and Basic:
An easy way to get started is to take the board view closest to what you want and save it as a work item query.
There is some form in a web form. It contains the list of items that use can edit, remove and change.
When the server receive the list of items, it should update existing items, create ones and remove the deleted ones.
I only know the naive and quite ugly approach:
When server receives the list of items from a client, it gets the actual list of items from the database
Pass round the received list of items:
2.1. If element has the ID and database has the element with this ID, this element updates
2.2. If this element doesn't have ID or database doesn't contain element with this ID, this element creates
Delete all items, that were not in the received list (marked as deleted)
The updated list of items are returnded to the client (with new IDs), and client displays them
I feel, that there is more elegant solution, and, propably, established for this task.
I had the same challenge and i solved it like this:
1-First when you load the page, create a list made up of id and data.
2-then the user fill the data.
3-those items that user doesnt fill should be deffault value.
4- then retrive the list from database and delete it and put the updated list
Hope this helps
This might be simple but I am new to Oracle. I am using Oracle 10g and have a form that lists our information from a linked table in a tabular Layout. The last column of data is a "list Item" item type that has the Element list of Enabled (T) and Disabled (F).
What I need is when a user changes this dropdown, to disabled, I want ONLY that row to have some of the columns be disabled and not the entire column.
This is also assuming on load of the form, it will disable and enable rows of data depending on what values are being pulled from the EnabledDisabled column in the database.
Thanks for the help!
Option 1: use the ENABLED item property.
Unfortunately Oracle Forms does not allow changing the ENABLED property of an item at the item instance level.
What you can do, however, is enable or disable the whole item when the user enters a record - use the WHEN-NEW-RECORD-INSTANCE trigger - depending on the value of the current record's value for the list item, the trigger would set the ENABLED property to PROPERTY_TRUE or PROPERTY_FALSE.
Of course, your list item would also have the same code in its WHEN-LIST-CHANGED trigger.
The downside to this approach is that the whole column will "look" disabled to the user, and they will not be able to select a different record using those disabled items.
Option 2: use the INSERT_ALLOWED and UPDATE_ALLOWED properties.
You can set these properties at the item instance level using SET_ITEM_INSTANCE_PROPERTY. You would set them in the block's POST-QUERY trigger, as well as in the list item's WHEN-LIST-CHANGED trigger.
This would not, however, change how the items look on the screen. To solve this, you could also set a visual attribute at the item instance level (e.g. change the items to use a dark gray background or something).
More comments.