[MAGNOLIA-7586] Storing Properties to a file does not work when using OrderedProperties Created: 19/Jul/19  Updated: 08/Aug/19  Resolved: 07/Aug/19

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 5.7, 6.0
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Marty Glaubitz Assignee: Unassigned
Resolution: Workaround exists Votes: 0
Labels: properties
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 10


Issue Links:
Relates
relates to MGNLCTS-109 No export of MultiValueFields Open
Template:
Patch included:
Yes
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   

One cannot use info.magnolia.cms.util.OrderedProperties when one wants to write properties to a file (for example when generating custom translation files). 

The entire reason for this is that OrderedProperties is missing a Method override, this one to be exact:

@Override
public synchronized Enumeration<Object> keys() {
    return new IteratorEnumeration(keySet().iterator()); // stored properties file will be empty otherwise
}

 



 Comments   
Comment by Mikaël Geljić [ 06/Aug/19 ]

Hi Marty,

Magnolia's OrderedProperties were originally an implementation detail for the PropertiesImportExport facility. That one is vastly unused by now, except in our own tests, and in one version-handling bootstrap task. In both cases import-only.

This 3rd-party utility https://github.com/etiennestuder/java-ordered-properties seems a lot more thorough than our implementation, and may fit your purpose better. In my view, it would make little sense for us to level up our impl for usages we don't have. In fact, we might as well consider replacing ours with the one above. Only downside is that it's not on Maven Central, seemingly only on JCenter.

Re: use case, you piqued my curiosity on those translation files or reports though, would you kindly share some details on that?

Cheers,

Comment by Marty Glaubitz [ 06/Aug/19 ]

@mikael no Problem: we've added a custom Pagenode Action to the Pages App which, when clicked, recursively writes all properties (whose names have to be in a set of known properties) of the currently selected node (page) and all it's subnodes into a properties file, which is then downloaded. This might look like this:

/de/de/home@title=Homepage title
/de/de/home/area/component@title=Component Title
/de/de/home/area/component@description=Component Description

This file can then be handed to some translator (their tools are used to .properties files) and when returned be imported back into Magnolia. The import action will simply write all properties under the given path.

It's the easiest way to translate content one can come up with

 

Comment by Mikaël Geljić [ 06/Aug/19 ]

Thank you for that,

Do you use (or have attempted to use) the Content Translation Support module?

One could configure additional importers/exporters to support this properties format. That would make a nice contribution too; do you know which tool they use, if I may ask?

Comment by Marty Glaubitz [ 07/Aug/19 ]

@Mikael we're quit heavily relient on using composite nodes in combination with multivalue transformers which save those under subnodes. We found that the content translation mdoule cannot deal with that... The translators are using https://www.sdltrados.com/. But regardless - all of them are happy with .properties files

Comment by Mikaël Geljić [ 07/Aug/19 ]

I see, sounds like something we should solve in CTS; thank you for the additional details, properties is definitely a legit choice.
Do you still need anything specific here then, or would you be happy to use the 3rd-party lib/class for ordered writes?

Comment by Marty Glaubitz [ 07/Aug/19 ]

@Mikael Helijc i think we weould be fine by using this existing Library. 

Comment by Mikaël Geljić [ 07/Aug/19 ]

Alright, let us know how it goes! Meanwhile let me close this issue as "Workaround exists" if I may.

Generated at Mon Feb 12 04:25:04 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.