New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal for entity list system (Trac #2567) #2567
Comments
cash wrote on 40800879-04-26 Another use case is photo albums. The only way to order the photos right now is to store the order as a serialized array. |
cash wrote on 40979472-05-22 I was cleaning up the sites library and saw that Ben and Marcus originally had the concept of collections being their own table or entity. Also, this additional table would solve the pages plugin ordering problems. |
Milestone changed to |
ewinslow wrote on 41719537-01-08 I would love for collection to be a top-level type instead of group. There are plenty of use-cases for these and right now the only option is to subtype object and implement your own collection interface. Folders, playlists, bookshelves, albums, friend lists, groups, etc... plenty of use-cases for this. |
ewinslow wrote on 41719539-05-26 As for pages, we'd have a nice recursive definition. Pages are collections of pages :) |
cash wrote on 41820998-07-12 Tagging this with ElggList and ElggCollection so it's easier to find in the future |
trac user kevinjardine wrote on 41978044-04-21 I would not like collections to be top level entities. Currently any entity whatsoever can be a container and I would like to maintain that flexibility. A group is not just a container. It has members and access groups, etc. I do like the idea of an API to make it easier to manage containers. |
cash wrote on 41978234-07-14 http://community.elgg.org/pg/forum/topic/830706/entity-list-spec/ |
trac user mrclay wrote on 42324086-11-18 Latest thread http://community.elgg.org/pg/forum/topic/835942/elggcollection-plugin-implementation/ |
trac user mrclay wrote on 42919688-07-30 Friday night hackathon! I'm going to need this soon whether or not it makes it into 1.9, so tonight I did a huge sprint on this and made some great progress. https://github.com/mrclay/Elgg-leaf/compare/19-collections I've still not actually executed any of this, but PhpStorm promises everything looks right. It also introduces the ideas discussed in the elgg-dev thread (a query modifier interface, named queries, and a proof-of-concept "entities query API"). Still a few big todos: implement method to relocate an item within the collection (for drag/drop), get rid of all the other unneeded items methods like slice(), write units, specify the plugin API and what/if any global functions we want to create to manage these. |
trac user mrclay wrote on 42919701-09-03 BTW, this implementation was rewritten to completely use relationships instead of a new table. Ordering is done via relationship ID (and yes re-ordering will be a pain). The description I have so far: "A collection can be thought of as metadata that stores a list of entities in a way that's optimized for SQL JOINs". Next step: sticky blog post feature. |
Current work on this: https://github.com/mrclay/Elgg-elggx_collections_api This removes access control (simplifying a ton) and basically makes this a lightweight API for creating relationships. Also adds a function to find collections by entity (was very difficult in the previous model), and some built-in views/actions for creating links to add/remove items. The sorting JS needs refactoring but it was pulled from a working project and you can see how it would work. /cc @ewinslow @cash @kevinjardine The fact that the API is inherently directed (forces you to choose the parent entity first) I think makes this easier than the current relationship API, which always leaves me confused about which is guid_one and guid_two. |
In production this is being used to allow users to create collections of favorite site objects (including other collections). I use an ElggObject to hold title/description and to provide access control. Also each user's collections are also in a collection, so the user can sort how their collections are displayed. When entities are deleted, the system checks for containing collections and replaces the items with a placeholder "This item was deleted" containing some of the original entity data. |
I was very loosely following this feature, but in general idea is nice. I see it as encouraging more efficient solution to common use cases. I'm a bit lost about implementation details though. Can we summarize what elements do we have in current solution? I'm not sure I like marking "This item was deleted", why exactly can't we just notice that entity is gone? Don't you make join with entities table anyway? What do you mean by "containing some of the original entity data"? Do we duplicate data in DB? Which one? Do you take care of synchronization both places if sth changes? |
Sorry for the confusion, my last comment was about how it's getting used on one site. None of that would go in core. The basics for the plugin:
|
Sounds like we're coming down to something pretty solid here. Can you give a concrete example of how you envision this working with photo albums or pages? Could we potentially implement friends collections (circles) on top of this too? |
I eventually arrived at this API: https://github.com/mrclay/Elgg-elggx_lists_api |
Still missing: view to re-order items. The action is done, based on jQuery UI sortable, but I haven't made a dedicated view for it. Challenge being dealing with very long lists. Also, current API doesn't fire relationship events. I'm not sure what would be ideal here, as re-ordering items involves removing and re-adding relationships... it's kind of its own thing. |
Weights on relationships? #4462 |
In my plugin lists are ordered by relationship.id, so in the lists schema I suggest we just call this column "position" |
but yes, essentially lists have an order, but if you're using the schema as relationships, you just ignore order |
API seems nice. I'd even encourage more OO, instead of the $members = $group->getList('members')
if (!$members->contains($user)) {
$members->add($user);
} The main question I would have is how to expose metadata about the relationships (relationship time_created, weight -- if we were to add it -- etc.?) |
just so you know, i already created a plugin that adds sort functionality to lists and it is running on my site. it would be great to get a core function for that. |
just a reminder that this is now the ticket that covers the introduction of a generic 'featured items' function, since the original ticket was closed in favor of this one. |
If you want a featured items feature, reopen that ticket, but this is for adding the API that (hopefully) will power it. |
99% of tickets i create get support and are then closed. in this case, the ticket was closed due to it being moved to another ticket. when i viewed that ticket, it too had been closed and moved to this ticket. |
I'm sorry? Maybe a community discussion on ticket etiquette would be useful? |
i think so, yes. there appears to be intent to just close as many as possible, without communicating between all involved |
@propertunist Feel free to contest the close or request justification. Closing tickets without justification is poor form. |
you can follow the thread from the original ticket here: #6293 |
Yes, we receive a notification for every comment made here. |
@mrclay I think a practical next step here would be to write up the interfaces that would be exposed. That gives us a reference from which to work, rather than relying on examples alone which always leaves me thinking "is the whole API covered by this set of examples?" Here's a start... // How do we expose "weight" and "time_created?"
interface EntityList extends Iterable, Countable {
function contains(Entity $e): boolean;
function add(Entity $e): ???;
function remove(Entity $e): ???;
}
interface ListsRepository {
public get($id): List;
public getFromEntity(Entity $e, $name): List;
} |
Lists can't have IDs until we migrate to the new schema. Rather than starting from scratch again, could we just try to build something on my implementation and find what it's missing, etc. I've put a ton of time into it finding the simplest boundaries I could find to get it work. |
Since we're staying on the relationships schema it worth noting that my implementation doesn't fire relationship events. To provide generic actions that could be reused by plugins I do however have a simple embedded permission system (based of elgg_can) to determine who can add/remove/rearrange items. This can be simplified however we see fit. |
Good observation about not being able to get lists by ID. We don't have to start the implementation from scratch, but I would like the opportunity to discuss the interface. |
I put some more time into defining the interfaces necessary for this. It's missing several APIs compared to @mrclay implementation but I believe it doesn't lose any expressiveness and the methods are more "standard", based on my knowledge of collection/list APIs. |
The usecases mentioned in the original post can easily be achieved by |
Original ticket http://trac.elgg.org/ticket/2567 on 40796290-01-22 by trac user mrclay, assigned to trac user mrclay.
I've [http://mrclay.org/index.php/2010/10/17/elgg-core-proposal-new-table-entity_list_items/ posted a proposal] to add an "entity list" system (and at least one new table) in the core. This would greatly ease the creation of features like this:[[BR]]
[[BR]]
Working API plugin using relationships for storage: https://github.com/mrclay/Elgg-elggx_lists_api but I suggest the relationship schema move to lists.
TODOs
Interfaces for discussion
Open questions:
There
where
method is probably the most mysterious (and difficult to implement). My idea here was to allow something like elgg_get_entities, but with a slightly cleaned up API:I find it a little clearer than the QueryModifier concept, which is too vague (modify how, exactly?).
The text was updated successfully, but these errors were encountered: