[MAGNOLIA-2969] Enhance magnolia propertiesImportExporter to handle Dates, and to export to a properties file Created: 12/Dec/09 Updated: 04/Nov/15 Resolved: 04/Nov/15 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | core |
| Affects Version/s: | 4.2.1 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major |
| Reporter: | Ryan Gardner | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | import, unittests | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| 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)
|
||||||||
| Testcase included: |
Yes
|
||||||||
| Date of First Response: | |||||||||
| Description |
|
In my opinion, one of the biggest hassles in creating a unit test for something that is driven by data in a repository is creating the properties file to drive the test. There was a mostly-implemented properties exporter in core but it didn't support writing out the data in the same format that it reads it in (namely, it didn't write the @uuid information or the @type information that it supports when importing from a properties file) This patch enhances the importer / exporter to the point where you can dump out content to a Properties or to a string representation of the properties. In addition, the Date nodes weren't dumped properly before. I added in some basic support for dumping and retrieving the Calendar objects from the properties file. I think that this, combined with another patch I'm about to submit that adds a "dump to properties format" to the JCR Queries page in Admin Interface should greatly reduce the pain for creating unit tests that operate using data from a repository. |
| Comments |
| Comment by Ryan Gardner [ 15/Dec/09 ] |
|
This updated version supports filtering with a contentfilter and uses the same dateformat used in the JCR. |
| Comment by Ryan Gardner [ 21/Dec/09 ] |
|
This version adds support for exporting metadata and cleans up the previous export slightly. |
| Comment by Ryan Gardner [ 21/Dec/09 ] |
|
In the latest, it's using a Jackrabbit ISO8061 util class to do the date exporting. I did try using Magnolia's DateUtils, but it requires a valid Locale it seems to work so I switched back to this ISO8061 class because it works and doesn't require a Locale. DateUtils could probably have a new method added that would do the same function (heck, and because of the license of the Jackrabbit, you could probably just copypasta their util class into it and put a note in your source saying that's where it's from) This version makes some of the content filter selection in the related patch a bit irrelevant since it will always export the metadata nodes if they are there (the developer can just delete them if he doesn't want them in his test properties). I've already used this a few times to generate test data from both the config and data repositories and it works nicely. |
| Comment by Magnolia International [ 20/Jan/10 ] |
|
Patch applied - minor style corrections. I also removed the support for importing any type (and the corresponding that checked URLs could be imported), since they are not supported jcr property types. Let me know if I'm missing something. Now, one thing I want to do before applying I'd also like to see if we can remove/simplify the duplication of code wrt type conversions (I don't think all the convert*ToExportString methods are necessary) But thanks, great stuff anyhow ! |
| Comment by Magnolia International [ 12/Mar/10 ] |
|
Pushing this to the next version, sorry. |
| 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. |