How to link Circles and Events (or Resources)

On DPO we have an issue which is that we need to be able to link Circles and events (or resources, or polls). The default way would be to add a relation (like a ForeignKey) between the circles and events models but they are in separate packages.

Furthermore, we do not really want to introduce a strong dependency as someone could want to use the Events or Resources or Polls modules and components without the need for any Circles at all.

So how do we manage to get the best of the two use-cases:

• Keeping a way to use the events or resources modules independently
• Being able to link the two models so that from a given circle you can retrieve the list of associated events. See the following mockup for reference:

Here as you can see you have access the detail of a Poll (but you also have menus for events and resources) associated with the Food network circle.

Furthermore to be able to do what we see in that last screen, we would need to modify the djangoldp-circle package to add the proper nested_fields and serialize_fields information, so that it exposes endpoints having the form api/circles/{id}/events/.

We probably do not want to modify the circle package for that, but then, how to extend that package to realise that use-case ?

We would also need to be able to assign a circle to an event when creating it, and then it will imply specific behaviour on the web component part.

Any ideas @calummackervoy @jbpasquier @sylvain on the best way to proceed there ? This behaviour will also be needed with projects I guess.

Two possibilities on the backend side:

• We go all-in for an implementation specific to the DPO use-case (preserving the link between circles and events/resources/polls) but then we need at least to modify the djangoldp-circle package alongside the DPO ones
• We add extensibility to the djangoldp-circle package so that everything can be defined in the DPO modules.
  • If we do that we can trigger the circle model extension only if the djangoldp-circle module is installed.

On the component side, we'll probably need a fork/two different repos to handle (or not) the dependency, which has impact on the creation forms.

My 2 cents are that it is probably not ok to modify the djangoldp-circle package to handle a specific use-case, but then we are missing something.

changed the description

changed the description

needing a foreign key on the model to Circle, without the hard dependency

You could create a new package, which extends the DjangoLDP-Event model and adds the foreign key to DjangoLDP-Circle?

we would need to modify the djangoldp-circle package to add the proper nested_fields and serialize_fields information

I opened this issue a couple of weeks ago, which I think summarises the problem here djangoldp-packages/djangoldp#253 (closed) .. I think @fabien4vo is working on this issue at the moment?

Good point. I'm glad we're entering this kind of issues.

I think we should go for an even more generic solution. Ie, If I develop my own "main menu" feature, let's say list of departments of my company, I want to be able to add polls or events in each department.

From an architecture point of view, I'd like to deploy an application, select the main features (left menu), and somehow select the features inside the main features. In terms of implementation, maybe we can have a third part model that would be able to plug the parent to the child. Or maybe the circles should have their child model list configurable.

I think we should go for an even more generic solution.

Issue is, we need something for next week :-)

In djangoldp-packages/djangoldp#253 (closed) I propose for the use of behaviour like the Manager from Django- where in the foreign key I am able to define related_name in Circle.profile and Profile has access to a manager with profile.circles.all()

That's interesting. I'm not sure to understand the whole story, but that sounds like a good lead.

mentioned in issue djangoldp-packages/djangoldp#253 (closed)

Done actually.

closed