[ http://jira.magnolia.info/browse/MAGNOLIA-1453?page=comments#action_13802 ] Philipp Bracher commented on MAGNOLIA-1453: -------------------------------------------
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. > beanification: reading configuration structures, allow class definition per > node, support maps > ---------------------------------------------------------------------------------------------- > > Key: MAGNOLIA-1453 > URL: http://jira.magnolia.info/browse/MAGNOLIA-1453 > Project: Magnolia > Issue Type: Improvement > Components: core > Reporter: Philipp Bracher > Assigned To: Sameer Charles > Fix For: 3.1 > > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia.info/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---------------------------------------------------------------- for list details see http://www.magnolia.info/en/developer.html ----------------------------------------------------------------
