buttercup-core
buttercup-core copied to clipboard
Field ordering
Support ordering of fields (meta).
Ordering information should be stored in an attribute. The attribute key could be as such: metaOrder:someAttributeName
. The order should be numeric, 0 and upwards. If a meta item does not have an order attribute, it should be placed at the end of the list in random order (as it falls).
Helpers to get the order should be provided. A helper to reset the order of each item should be provided. Some kind of interface to manage changing the order should be provided. Discuss any ideas here before implementation.
Some kind of interface to manage changing the order should be provided
I think, initially, a feature to automatically order fields alphanumerically would be useful (enough for me). I make use of (key) naming such that things naturally group when ordered. A select, similar to the entry pane component[c], would suffice for this with some options:
- key: ascending
- key: descending
- time - added/created: newest
- time - added/created: oldest
- time - edited/modified/updated: newest
- time - edited/modified/updated: oldest
- value: ascending
- value: descending
NB Being able to set ordering (e.g. groups, entries, fields) globally would be useful too
In addition, manual field ordering could come later, once the interaction patterns exist, using some down/up (arrow) buttons, drag/drop (and don't forget keyboard shortcuts!)
If you have any issues (e.g. questions/queries) then happy to help
Hope this helps
Regards
c:
The trouble with this issue is that fields are stored on Entries as key: value
, and don't contain any associated attributes. Every entry has a hidden attributes
collection, which is also key: value
, so information regarding the order of entry properties should be stored there.
In my opinion we could start with simply numerical orders which would allow for drag+drop reordering. @ldexterldesign your design would still be applicable as an extension to this behaviour as it could forcibly update the numerical orders in the background.
Seems legit[l]
If you can help[h] then happy to attempt a PR
Cheers
h: @ldexterldesign:matrix.org (preference) or https://keybase.io/ldexterldesign l: https://devdocs.io/dom_events/drag > https://jsfiddle.net/zfnj5rv4/
Ok, so I'd go about this process in the following manner, if I were tackling it:
- Add a constant in
Entry.js
to hold the prefix for field orders, as every field could have an associated attribute to record its order. The prefix could resemble the only other current attribute name, maybe something likeBC_ENTRY_FIELD_ORDER:
. - Add a method called
getPropertyOrder
, which takes a string for the property name. It should return the 0-based order of the property if set andInfinity
if it's not set. - Add a method called
getPropertyOrders
that returns an array of property names (all on the entry) in order. Each property should be passed intogetPropertyOrder
and then sorted from lowest to highest. - Add a method called
setPropertyOrder(property, order)
that sets the order of a property. If the order is taken by another property, that property's order should be increased (along with all of the others after it). If set toInfinity
the order should be set as the next number after the previous last item.
So, as an example, let's say we have the following setup:
Property | Order | Attribute name (eg.) |
---|---|---|
username | 0 | BC_ENTRY_FIELD_ORDER:username |
password | 1 | BC_ENTRY_FIELD_ORDER:password |
URL | 2 | BC_ENTRY_FIELD_ORDER:URL |
3 | BC_ENTRY_FIELD_ORDER:E-Mail |
|
Test Note | 4 | BC_ENTRY_FIELD_ORDER:Test Note |
After calling entry.setPropertyOrder("Test Note", 2);
:
Property | Order | Attribute name (eg.) |
---|---|---|
username | 0 | BC_ENTRY_FIELD_ORDER:username |
password | 1 | BC_ENTRY_FIELD_ORDER:password |
Test Note | 2 | BC_ENTRY_FIELD_ORDER:Test Note |
URL | 3 | BC_ENTRY_FIELD_ORDER:URL |
4 | BC_ENTRY_FIELD_ORDER:E-Mail |
Notice the orders of "Test Note", "URL" and "E-Mail".
After calling entry.setPropertyOrder("username", Infinity);
:
Property | Order | Attribute name (eg.) |
---|---|---|
password | 0 | BC_ENTRY_FIELD_ORDER:password |
Test Note | 1 | BC_ENTRY_FIELD_ORDER:Test Note |
URL | 2 | BC_ENTRY_FIELD_ORDER:URL |
3 | BC_ENTRY_FIELD_ORDER:E-Mail |
|
username | 4 | BC_ENTRY_FIELD_ORDER:username |
Note that setting any order above the last possible order value will result in it being normalised to the last possible value.
Also good to note that the deleteProperty
method should be modified to also delete the order attribute, if it exists. I'm not sure that setProperty
needs to set the order, but I could be swayed either way.
Slloooowwwlllyy working on this...
I see jsdoc style comments - are there generated docs hidden somewhere?
Cheers
@ldexterldesign Yes API.md in the root is generated from JSDoc comments..
During the implementation of this would it allow for duplicate custom fields for entries? Right now the behavior is such that only the last duplicate field is saved.
Hi @haloway13,
Do you have a use case for this?
I'm currently doing this for single sign-ons but TBH I would rather not have to bother with (managing) the numeric suffixes, so I'm inclined to agree with you:
sing
![Screenshot 2020-05-29 at 01 21 16](https://user-images.githubusercontent.com/1715809/83204123-580baa00-a14b-11ea-8f8c-ae08617d7a8b.png)
![Screenshot 2020-05-29 at 01 20 45](https://user-images.githubusercontent.com/1715809/83204118-5510b980-a14b-11ea-8c92-42e4852876b0.png)
Sincerely
FYI
Slloooowwwlllyy working on this...
I'm not working on this any more in case anyone else wants to pick it up
Unfortunately I don't think my JS is far enough along to attempt the PR + I'm currently doing svelte where once I hoped to learn react
Apologies
Hi @haloway13,
Do you have a use case for this?
I'm currently doing this for single sign-ons but TBH I would rather not have to bother with (managing) the numeric suffixes, so I'm inclined to agree with you:
sing
![]()
![]()
Sincerely
I just had the case happen when I was mistakenly adding a field name I already had that it deleted the field value I wanted to keep and not replace. I would be happy to expound if that does not make sense.
Hi @haloway13,
I just had the case happen when I was mistakenly adding a field name I already had that it deleted the field value I wanted to keep and not replace. I would be happy to expound if that does not make sense.
Yes, it's happened to the best of us 🙃
Sincerely