[SJN-51] Fix hierarchies in configuration files | |
| Status: | Closed |
| Project: | Simple-JNDI |
| Component/s: | |
| Affects Version/s: | 0.9.1 |
| Fix Version/s: | 0.11 |
| Type: | Bug | Priority: | Major |
| Reporter: | Henri Yandell | Assignee: | Henri Yandell |
| Resolution: | Won't Fix | ||
| Environment: | |||
| Description |
| Given: one.Foo.name=bar one.Foo.value=1 one.Foo.name=test one.Foo.value=2 it should create a List in one.Foo which contains name and value for each element. Currently it creates one.Foo.name=bar,test and one.Foo.value=1,2. XML and .ini should be handled the same way. XML is very obvious: <one><Foo><name>bar</name><value>1</value></Foo> <Foo><name>test</name><value>2</value></Foo></one> |
| Comment by bayard [ Tue, 4 May 2004 12:26:23 -0700 (PDT) ] |
| Genjava-Core's FQMap might be of use here. It's basically a hierarchy map of maps based on a delimiter. Pretty much all simple-jndi's underlying system is. It needs to masquerade as a Properties file somehow to allow the PropertiesContext to have no clue that anything is going on. Also needs to extend AbstractProperties, as that is how PropertiesContext will know to return a Context object on a lookup. |
| Comment by bayard [ Tue, 4 May 2004 20:13:25 -0700 (PDT) ] |
| Big rewrite here. FQMap modified as HierarchicalMap and all the Properties classes changed to Parser classes. |
| Comment by bayard [ Tue, 4 May 2004 21:41:10 -0700 (PDT) ] |
| Tests all nearly pass except for one to do with the 'type' special variable. This is because the code ends up with a HierarchicalMap as a node which contains key=value, where value is a List. The type variable ends up in the List. Instead, the value in the HierarchicalMap should always be a Value object, and if a type is found it is set as Value.setType and not as a child of the value's key. Could optimise and only have a Value object when type is found. This is all work that is needed in the put of HierarchicalMap. Tempting to move the convert code into the get of HierarchicalMap and out of PropertiesContext. Slims that class down and puts like with like. |
| Comment by bayard [ Wed, 5 May 2004 22:06:27 -0700 (PDT) ] |
| Conversion code is out of PropertiesContext and into HMap as planned, but after a failed attempt to create the ConvertValue wrapper system suggested previously, I simply put a bit of magic in the get() method to hide that there is something underneath. This will not be enough in the long run as there are other ways to obtain values. However, it should also be impossible for a user to obtain a HMap, they should always be behind a Context, so not all of those methods will need to be implemented. More testing needed, but current unit tests are all happy. |
| Comment by bayard [ Wed, 5 May 2004 22:07:04 -0700 (PDT) ] |
| Probably much left to do, but unit tests all pass now and the underlying system is quite possibly much clearer now. |
| Comment by bayard [ Thu, 6 May 2004 23:17:22 -0700 (PDT) ] |
| Despite passing the tests, I suspect that this completely doesn't work yet, though all the code so far is important in laying the groundwork for a working system. Need to come up with unit tests to confirm this suspicion, then fix the odds and ends that are not quite right. |
| Comment by bayard [ Thu, 21 Apr 2005 23:26:43 -0700 (PDT) ] |
| Doing a complete rewrite instead. |