[MGNLDAM-567] JcrAssetProvider not I18n-aware Created: 31/Mar/15  Updated: 01/Jul/15  Resolved: 18/May/15

Status: Closed
Project: Magnolia DAM Module
Component/s: DAM JCR Provider
Affects Version/s: 2.0.6
Fix Version/s: 2.0.9

Type: Bug Priority: Major
Reporter: Vivian Steller Assignee: AntonĂ­n Juran
Resolution: Fixed Votes: 0
Labels: assets, i18n, quickwin, support
Remaining Estimate: 1h
Time Spent: Not Specified
Original Estimate: 1h

Issue Links:
Relates
relates to MGNLSTK-1404 STKAssetWrapper is not i18n aware Closed
causality
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)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

Currently the JcrAssetProvider is not I18n-aware. Customers have to patch the respective class in projects in order to have multi-language support for assets.

The patch would be quite easy: in JcrAssetProvider, patch the method createAsset by wrapping the node with I18nNodeWrapper and that it:

    @Override
    Asset createAsset(final Node assetNode) {
        if (AssetNodeTypes.isAsset(assetNode)) {
            log.debug("Created asset linked to the following node '{}'", NodeUtil.getPathIfPossible(assetNode));

            // FIXME PATCH START

            // wrap asset node with i18n functionality
            return new JcrAsset(this, new I18nNodeWrapper(assetNode));

            // PATCH END
        }
        throw new IllegalArgumentException("Node '" + NodeUtil.getPathIfPossible(assetNode) + "' is not defining an asset but another item type");
    }

A more sophisticated patch would ask I18nContent Support if I18n is enabled after all...

By the way, it would be helpful if that method was protected instead of package visible - but this is a general problem in Magnolia code...

This issue might also fix MGNLSTK-1404 in the same way?

Thanks for patching this soon



 Comments   
Comment by Philip Mundt [ 13/May/15 ]

Please provide a test for this scenario.

Comment by Philip Mundt [ 18/May/15 ]

The test doesn't prove that a) the above defect was actually given and b) doesn't prove the solution solves the issue.
I was expecting something like:

    @Test
    public void assetIsI18nized() throws RepositoryException {
        // GIVEN
        final Map<String, Locale> locales = new HashMap();
        locales.put("en", Locale.ENGLISH);
        locales.put("fr", Locale.FRANCE);
        final DefaultI18nContentSupport defSupport = new DefaultI18nContentSupport();
        defSupport.setEnabled(true);
        defSupport.setFallbackLocale(new Locale("en"));
        defSupport.setLocales(locales);
        ComponentsTestUtil.setInstance(I18nContentSupport.class, defSupport);

        final Node assetFolder = root.addNode("Folder", NodeTypes.Folder.NAME);
        provider.setRootPath(assetFolder.getPath());
        final Node assetNode = assetFolder.addNode("Asset", AssetNodeTypes.Asset.NAME);
        assetNode.setProperty("caption", "caption");
        assetNode.setProperty("caption_fr", "caption_fr");

        // WHEN
        final Asset asset = provider.getAsset("Asset");

        // THEN
        assertNotNull(asset);
        assertEquals(asset.getCaption(), "caption");

        final MockWebContext ctx = new MockWebContext();
        ctx.setLocale(Locale.FRANCE);
        MgnlContext.setInstance(ctx);

        assertEquals(asset.getCaption(), "caption_fr");
    }
Comment by Vivian Steller [ 22/Jun/15 ]

pmundt Thanks for this blue print testcase implementation, I just learned a lot ...and of course for fixing this...
Cheers,
Vivian

Generated at Mon Feb 12 05:01:07 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.