[MAGNOLIA-3349] Port Virtual URI mappings to a Registry Created: 29/Oct/10  Updated: 29/Jan/18  Resolved: 02/May/17

Status: Closed
Project: Magnolia
Component/s: Virtual URI mappings
Affects Version/s: 4.3.8
Fix Version/s: 5.5.6, 5.6

Type: Improvement Priority: Neutral
Reporter: Christian Ringele Assignee: Oanh Thai Hoang
Resolution: Done Votes: 2
Labels: None
Remaining Estimate: 0d
Time Spent: 6d 6.5h
Original Estimate: 5d

Attachments: PNG File Screen shot 2010-10-29 at 12.13.53 PM.png     Text File magnolia-core.patch    
Issue Links:
Relates
relates to MAGNOLIA-6994 Exception is thrown when add a new co... Closed
relates to MAGNOLIA-4090 VirtualUriManager should be reimpleme... Closed
relation
supersession
supersedes MAGNOLIA-6415 VirtualURIMapping via YAML Closed
is superseded by MGNLUI-4244 Implement new VirtualUriMapping app a... Closed
is superseded by MGNLUI-4313 Demote About app's VirtualUriMapping ... Closed
is superseded by MULTISITE-73 Update multisite URI mapping against ... Closed
is superseded by PAGES-139 Check conflicting virtual URIs agains... Closed
is superseded by MAGNOLIA-7016 Improve API of Virtual URI mappings Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Sprint: Saigon 87, Saigon 88, Saigon 89, Saigon 90, Saigon 91, Saigon 92, Saigon 93
Story Points: 8

 Description   

In order to support folder-hierarchy within Virtual URI mappings config, VirtualURIManager should be ported to an AbstractRegistry.

  • The registry is bound to configuration-sources upon module startup
    • allowing virtual URI mappings by file at the same time
  • Existing VirtualURIManager goes to deprecation
  • Beware: registries are currently populated upon startup of the "owning" module. This is different to when virtual URI mappings & commands are loaded now (after all modules are started).
    • we could also consider generally deferring population of registries in similar fashion, while we're at it.

Side notes:

  • Virtual URI mappings could have their own app (outside of About app)
  • App could become a subset of Definitions app?
  • Can registry offer specific API to know which mapping fired? Would it be the right place?
    • just mentioning here but might as well be considered in a superseding ticket.

Original title: Allow subfolders/nodes in the observed 'virtualURIMapping' module nodes

When having a lot of virtualURIMappings registered in a module, it can be quite hard to keep the overview.
Being able to sort them in folders/nodes would improve that a lot (as in paragraphs/dialogs already possible).

I added a patch of this class, which does that. Code should be checked for core quality, was implemented very quickly.



 Comments   
Comment by Michael Mühlebach [ 04/Nov/15 ]

Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Comment by Michael Mühlebach [ 03/Mar/17 ]

Jan: Use registries for virtual URI mappings. This solves this issues and many others.

Comment by Mikaël Geljić [ 15/Mar/17 ]
  • Virtual URIs are part of core, while config APIs are in depending configuration module
  • Should we extract those to an own module?
    • in that case, speaks against backport to 5.4 => alternative fix for old manager impl or ignore?
    • submodule of main vs. standalone CE module (would own the registry and the app currently in about-app)
  • Would it help foreseen core-split?
    TBD
Comment by Mikaël Geljić [ 17/Mar/17 ]

Outcome from architects (cc ejervidalo had pmundt rkovarik):

  • The port was confirmed w/ PO, to reap same benefits/features other registries/definitions have
  • We deprecate VirtualURIManager and make it non-final anymore. This is binary-compatible.
  • We extract a new submodule of main, proposing magnolia-virtual-uris
  • For compatibility w/ projects without the new dependency:
    • We sub-class VirtualURIManager as an adapter, internally backed by the new registry.
    • We override default implementation via component mapping in module descriptor
  • As a follow-up, there is temptation to drop the Virtual URI Mappings subapp from the about app, in favor of Definitions app; but it lacks the domain-specific filters.
Comment by Mikaël Geljić [ 02/May/17 ]

The VirtualUriRegistry is successfully implemented, within the new magnolia-virtual-uri module.

The new module means that we had to relocate APIs (VirtualURIMapping, VirtualUriFilter), while the VirtualURIManager is now deprecated in favor of the registry (book-keeping) and the filter (evaluation).

Significant backward compatibility is provided, mainly by a couple things:

  • Rebinding of the VirtualURIManager to a compatibility adapter, backed by the registry.
  • Exposing old mappings (from core) with another adapter to the replacing mapping interface.

Taking the opportunity of the relocation, follow-up MAGNOLIA-7016 is addressing API improvements—so that we don't break APIs after initial release. This is why the registry "standalone" is dropping off the 5.5.4 wagon (also to give us more time for testing, as 5.5.4 is due shortly).

As a side note, the new magnolia module was developed with 5.4.x-compliant APIs; that should leave a few options open.

Generated at Mon Feb 12 03:45:37 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.