RFC: Node Context and domains

[radmiraal (Rens Admiraal)]

@aertmann

Decouple URL from the backendOne of the first thing to do is to decouple the front end URL from the backend. This will allow us to show any node from the CR and allow showing entities as well. Additionally it will allow viewing a site regardless of the domain, which is very useful for multi-sites. Either using the node identifier with a context string, e.g. 75a28524-6a48-11e4-bd7d-7831c1d118bc@user-admin;language=en_US or the full path. And then keep the uriPath accessible as a fallback and for flexibility & backwards compatibility.

This means the backend URL won’t be as “accessible” as before, but it will make it more robust and it’s the URL for the page could be displayed in the backend. A speaking URL should be an optional enhancement, not a requirement.

Full ack here. I think default behavior should be to use the speaking url if possible. This will make the change a lit less ‘shocky’ Would a setting to completely ignore the speaking url for the backend make sense? I think I’d like that as I’d prefer consistency in my installs…

@aertmann

DomainI found it odd that the current implementation accepts patterns, although potentially useful, it is currently not always working as expected and people get confused by it.

The only reason we need a host name is for linking from one site to another. In all other scenarios using the request for determining the URL should suffice for which the current solution works.

Now there are two ways of solving that problem. Either add a primary flag (canonical) as you suggest, which requires that it’s a host name and not a pattern. Or we make it possible to order them and the first one with a host name is used. We can easily display a warning if a site in a multi-site setup doesn’t have at least one domain with a host name.

I’m not sure which solution is best, but I’m leaning towards the priority one from a UX perspective and since it would fit the existing concept.

Btw. there’s already a ticket for adding a primary flag to the domain entity.

I definitely prefer the primary flag over ordering. Or if we do use the ordering I think the design / context should be really clear about what would be the primary one. But as one could sort a pattern as the first one this could become really confusing.

@aertmann

So in general I think we should try to come up with a solution that doesn’t involve a site, but rather a flexible context that’s being parsed around (like in CR).

Maybe @radmiraal would be interested in chiming in, since he’s considering some scenarios similar to this.

In short we’re going to put our content outside of a site node, and will just use site nodes to create websites that are displaying that content based on filters. So everything that removes the default site requirement is making me happy

What I’m not sure about yet is how to solve the dimension issue / specific site configuration. To me it is site configuration which dimensions will be used (so that should be configurable on a site level). But I doubt if I think the same about the dimension fallbacks… If they’re not global it might become overly complex while I’m not even sure yet if it has a usecase.