[MAGNOLIA-1453] beanification: reading configuration structures, allow class definition per node, support maps Created: 06/Apr/07  Updated: 23/Jan/13  Resolved: 27/Apr/07

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: None
Fix Version/s: 3.1 M1

Type: Improvement Priority: Major
Reporter: Philipp Bärfuss Assignee: Philipp Bärfuss
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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:

 Description   

I started to improved the ContentUtil.setProperties() method and wrote a general configuration reader. I will put this into another util class or package. How ever Gregory is working on a similar system based on xsteram and jcr and as we know we use openwfe's encoder/decoder. What I have written is not meant to be a persistance mechanism but a tool to read configuration the way magnolia configuration is defined in general.

It is very likely that this code will be replaced by Gregories work once we have internal jcr nodes and his work is finished. For now I would like to motivate everyone to use the toBean(node) methods where every they transform configuration to beans. This will improve the flexibility of magnolia a lot:

  • you can define implementing classes by the class property
  • additional properties (not forseen in the original class) are set as well
  • maps are supported in a simple way

Example (orginal reason: filter bypasses and virtual uri mappings can be any kind of implementation and are much flexibler (and faster) therefore. This allows user based mappings or what ever you can think about.



 Comments   
Comment by Philipp Bracher [ 13/Apr/07 ]

I checked in my code. Here is what it is about:

  • converting a hierarchy of nodes into beans
  • supports maps, collections in the way we use them in configuration
  • checks for adder method
  • no extra entry or key node (the node name is the key)
  • uses reflection to get the class to use in case the node has no class property
  • property type
  • checks adder method for maps/collections
  • uses the FactoryUtil for interfaces (define default implementation as usual)
  • for not resolvable map types the *.content2bean files are used to resolve the type
  • in case no class can be resolved the bean is a map (properties as key value pairs)
  • customizable (conversion, exclusions, ...)
  • performance: I did not care a lot about since this is used for reading configuration mainly

In the most cases a call to ConfigUtil.toBean(Content node, boolean recursive) will be enough. If you need more customization you will use Content2BeanProcessor.getInstance(). In most of the other cases the Content2BeanUtil will be enough.

The implementation of serializing beans to a configuration is not yet implemented, but can follow in case we need it.

I will extract the Content2BeanProcessor interface for simplify tests.

Comment by Philipp Bracher [ 13/Apr/07 ]

Interfaces are extracted, comments added and minor cleanup done

Comment by Philipp Bracher [ 15/Apr/07 ]

The transformer and the current transformation state are the same. This is wrong and need to be changed.

Comment by Philipp Bracher [ 18/Apr/07 ]

state, transformer and mappings separated

now we can think about bean to content transformation (should be trivial since the base is already there)

Comment by Philipp Bracher [ 27/Apr/07 ]

content 2 bean transformation is working fine. I will define new more precise jira entries

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