- getRelatedObjects() must return a List instead of an Iterator
-> using iterator instead of list prevent developers to add or remove directly RelatedObject into the returned list. So, can you allow the method to return an iterator, a list or an array ?
- This mapping of relations must be one-way only
-> to make the mapping bi-directional, we need to define two one-way mappings and we need to duplicate in these two mappings all the bi-directional mapping for the attributes. What do you think of allowing method customization like this on a bi-directional mapping :
Not sure on the next release, but it won't be too long. Although I am not guaranteeing we will support all of your suggestions. the team will meet and discuss.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We have completed this change, look to see it in the next release very soon. You can see the actual docs for it (after release) in the advanced property mapping section.
Ben
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is the first form always relevant ? Can't it be replaced by the second one ?
Does this also work with list (Iterators, List, Arrays) attibutes ?
The fact that the get method return an iterator (or a subtype of iterator), a list (or a subtype of List) or an array means that it's an iterate mapping...
If so, the iterate method mapping is no more relevant too.
Thanks for the great feedback. I will work with Ben on re-factoring this into something a little more intuitive. Most of the iterate/method map stuff was an afterthought. We didn't know how many people in the community we need functionality like that. I'll let you know what we come up with.
Thanks,
Franz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't think there is an other thread than this one about the 'field-method' refactoring...
In this thread, my post dated '2005-08-22 16:03' try to explain why a suppression of the field-method as well as field-iterate-method would be interesting (simpler and bi-directionnal mappings).
Currently, we must use field-iterate-method for all our compositions between classes (because our set method is called addXxxx) and so we need to do 2 uni-directionnal mappings...
Good news if inheritance is close to be done ;-)
Thanks,
Richard.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<field> <!-- this always assumes non-cumulative since the getMethod() returns a Car and not a List. We have no way of adding to the list since we can not access it -->
<A theGetMethod="buildCar">cars</A>
<B theSetMethod="addCar">vehicles</B> <!-- maps to the type of the argument, assumes only one method name -->
</field>
I should finish iterate tomorrow. So probably release on Thursday after merging the inheritance patch.
This works one-way...now I just need to get it working the other way.
<!-- Iterate Method Mapping -->
<field-iterate-method>
<A>appleComputers</A>
<B theSetMethod="addComputer">computers</B>
<destinationTypeHint>net.sf.dozer.util.mapping.vo.AppleComputer</destinationTypeHint>
</field-iterate-method>
Thanks,
Franz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This would be a good thing ! (converting apple computers to generic pc computers and the reverse will then be possible ;-)
But is it necessary to specify sourceTypeHint and destinationTypeHint and if we do not specify these, can Dozer take the class specified for the set method parameter instead ?
Thanks,
Richard.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm pretty sure I have it all working. These two examples show iterating bi-directional. You do need to have a hint for any fields that are denoted as 'iterate'. Both fields can be iterate...or just one. You can also mix and match the method level set() and get() attributes.
well, yes there are some definite overlaps there. I was mostly trying to get you a usable fix as fast as possible. I will go back and refactor the whole section this week.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
sorry but it's for a bug again, slighty more difficult than the documentation one ;-)
Well, i found that theSetMethod and theGetMethod don't work when applied on 'B' :
* the working xml :
<mapping>
<classA>A</classA>
<classB>B</classB>
<field-method>
<A theGetMethod="takeA" theSetMethod="giveA">myA</A>
<B>b</B>
</field-method>
</mapping>
* the no-working one :
<mapping>
<classA>fr.maaf.test.mapping.dozer.B</classA>
<classB>fr.maaf.test.mapping.dozer.A</classB>
<field-method>
<A>b</A>
<B theGetMethod="takeA" theSetMethod="giveA">myA</B>
</field-method>
</mapping>
I just put classes on the reverse order, and it doesn't work anymore. The message is :
Error in loading dozer mapping file: dozerBeanMapping.xml : net.sf.dozer.util.mapping.MappingException: net.sf.dozer.util.mapping.MappingException: Unable to determine read method for field: myA class: class A
So it's also impossible to use Custom set() and get() methods in a bi-directional way :-)
I think that's all (today ;-) )
Bye
Seb, Dozer tester 8-D
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Seb. We are re-visiting this functionality this week and re-architecting the way it works. It is still lacking in a few things. Should have it re-factored by next week.
Thanks.
Franz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We choose to use Iterator instead List in these API to be sure that the only way for developpers to add a computer is to do :
container.addComputer(c)
They don't have API allowing :
container.getComputers().add(c)
which allow to add something in a container in a way that the container isn't aware of this operation.
The problem is Dozer doesn't let us defined such API ;-(
Why "iterate" fields (with this attribute of the 1.5.1 release) can't have a get method returning an Iterator ?
We can modify our programming rules to make getXxxx returning List instead Iterators but I liked a lot the fact that we can have our programming rules and tell Dozer these rules (instead of modifying these)....
Richard.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
We are currently testing dozer and it works well !
We need to use "method" attributes in the mapping file for our relations defined by the following API :
Iterator getRelatedObjects()
addRelatedObject(RelatedObject ro)
removeRelatedObject(RelatedObject ro)
And we have the following two limitations :
- getRelatedObjects() must return a List instead of an Iterator
-> using iterator instead of list prevent developers to add or remove directly RelatedObject into the returned list. So, can you allow the method to return an iterator, a list or an array ?
- This mapping of relations must be one-way only
-> to make the mapping bi-directional, we need to define two one-way mappings and we need to duplicate in these two mappings all the bi-directional mapping for the attributes. What do you think of allowing method customization like this on a bi-directional mapping :
<field>
<A>relatedObject</A>
<B>relObj</B>
<originalGetMethod>getRelatedObjects</originalGetMethod>
<originalSetMethod>addRelatedObject</originalSetMethod>
<destinationGetMethod>getRelObjs</destinationGetMethod>
<destinationSetMethod>addRelObj</destinationSetMethod>
</field>
Thanks again for your great product,
Richard.
Richard,
Thanks for the feedback, we will consider some of your suggestions. BTW, wouldn't iterator.remove() still be an issue for you?
We are in the process of planning the next release, maybe some of these suggestions will make it :)
thanks,
Ben
Ben,
The returned iterator will throw an UnsupportedOperationException on its remove() method ;-)
When the next release will be downloadable ?
Thanks again,
Richard.
:)
Not sure on the next release, but it won't be too long. Although I am not guaranteeing we will support all of your suggestions. the team will meet and discuss.
As you said, these are only suggestions ;-)
Richard.
Richard,
We have completed this change, look to see it in the next release very soon. You can see the actual docs for it (after release) in the advanced property mapping section.
Ben
Thanks !
That's Great ;-)
But we are always unsatisfied ;-)
What's the difference between that :
<field-method>
<A type="method">buildCar</A>
<B type="method">addCar</B>
</field-method>
and this new form (instead the fact that the first one has the one way limitation ?) :
<field-method>
<A theGetMethod="buildCar">car</A>
<B theSetMethod="addCar" >car</B>
</field-method>
Is the first form always relevant ? Can't it be replaced by the second one ?
Does this also work with list (Iterators, List, Arrays) attibutes ?
The fact that the get method return an iterator (or a subtype of iterator), a list (or a subtype of List) or an array means that it's an iterate mapping...
If so, the iterate method mapping is no more relevant too.
<field-iterate-method>
<A>appleComputers</A>
<B type="method">addComputer</B>
<destinationTypeHint>net.sf.dozer.util.mapping.vo.AppleComputer</destinationTypeHint>
</field-iterate-method>
Can then be replaced by :
<field-method>
<A>appleComputers</A>
<B theSetMethod="addComputer">computer</B>
<destinationTypeHint>net.sf.dozer.util.mapping.vo.AppleComputer</destinationTypeHint>
</field-method>
And then, my last question is why calling this mapping <field-method> instead of <field> ?
<field>
<A theGetMethod="buildCar">car</A>
<B theSetMethod="addCar" >car</B>
</field>
is simpler than :
<field-method>
<A theGetMethod="buildCar">car</A>
<B theSetMethod="addCar" >car</B>
</field-method>
That's all folks ;-)
I must say that this is by far the best mapping framework I have seen.
Richard.
Thanks for the great feedback. I will work with Ben on re-factoring this into something a little more intuitive. Most of the iterate/method map stuff was an afterthought. We didn't know how many people in the community we need functionality like that. I'll let you know what we come up with.
Thanks,
Franz
Hi Franz,
I just take a look at the release notes and saw nothing about field-method refactoring...
Will this be done in a further version ?
I thought this version will allow list attributes (as well as iterators ;-) ) and make field-iterate-method irrelevant..
Actually, we need to duplicate the whole mapping description to make 2 one way mappings just because we must use the field-iterate-method...
I hope this will take place in a further release soon ;-)
Thanks,
Richard.
Hey Richard -
We are still working on this for the 1.5.1 release. I will let you know when we get close to putting this out.
Thanks.
Franz
Good news ;-)
I'm now waiting for this 1.5.1 release !
Thanks again,
Richard.
Hi Franz,
Just a little post to make the forum alive ;-)
Are you close to put the 1.5.1 release out ?
Richard.
Hey Richard -
Let me get an update from the team. I think some of them might be OOO today.
Did we have a thread stating exactly what needed to be done for the field 'method' stuff?
I know the inheritance piece is close to being done.
Thanks,
Franz
Hi,
I don't think there is an other thread than this one about the 'field-method' refactoring...
In this thread, my post dated '2005-08-22 16:03' try to explain why a suppression of the field-method as well as field-iterate-method would be interesting (simpler and bi-directionnal mappings).
Currently, we must use field-iterate-method for all our compositions between classes (because our set method is called addXxxx) and so we need to do 2 uni-directionnal mappings...
Good news if inheritance is close to be done ;-)
Thanks,
Richard.
Richard -
I got rid of field-method altogether. This works in both directions.
<field>
<A theSetMethod="placeValue" theGetMethod="buildValue">value</A>
<B>value</B>
</field>
<field> <!-- this always assumes non-cumulative since the getMethod() returns a Car and not a List. We have no way of adding to the list since we can not access it -->
<A theGetMethod="buildCar">cars</A>
<B theSetMethod="addCar">vehicles</B> <!-- maps to the type of the argument, assumes only one method name -->
</field>
I should finish iterate tomorrow. So probably release on Thursday after merging the inheritance patch.
This works one-way...now I just need to get it working the other way.
<!-- Iterate Method Mapping -->
<field-iterate-method>
<A>appleComputers</A>
<B theSetMethod="addComputer">computers</B>
<destinationTypeHint>net.sf.dozer.util.mapping.vo.AppleComputer</destinationTypeHint>
</field-iterate-method>
Thanks,
Franz
Great !
So we will make a bi-directional mapping like that ? :
<field-iterate-method>
<A theGetMethod="getAppleComputers" theSetMethod="addAppleComputer" >appleComputers</A>
<B theGetMethod="getComputers" theSetMethod="addComputer">computers</B>
<sourceTypeHint>net.sf.dozer.util.mapping.a.AppleComputer</sourceTypeHint>
<destinationTypeHint>net.sf.dozer.util.mapping.b.Computer</destinationTypeHint>
</field-iterate-method>
This would be a good thing ! (converting apple computers to generic pc computers and the reverse will then be possible ;-)
But is it necessary to specify sourceTypeHint and destinationTypeHint and if we do not specify these, can Dozer take the class specified for the set method parameter instead ?
Thanks,
Richard.
Richard -
I'm pretty sure I have it all working. These two examples show iterating bi-directional. You do need to have a hint for any fields that are denoted as 'iterate'. Both fields can be iterate...or just one. You can also mix and match the method level set() and get() attributes.
<!-- Iterate Method Mapping -->
<field>
<A>appleComputers</A>
<B theSetMethod="addComputer" type="iterate">computers</B>
<destinationTypeHint>net.sf.dozer.util.mapping.vo.AppleComputer</destinationTypeHint>
</field>
<!-- Iterate Method Mapping -->
<field>
<A theSetMethod="addCar" theGetMethod="myIterateCars" type="iterate">iterateCars</A>
<B theSetMethod="addIterateCar" type="iterate">iterateCars</B>
<sourceTypeHint>net.sf.dozer.util.mapping.vo.Car</sourceTypeHint>
<destinationTypeHint>net.sf.dozer.util.mapping.vo.Car</destinationTypeHint>
</field>
This should be in tonight or tomorrow morning. Just need to merge the inheritance stuff.
Hi Franz,
We could not hope for a better solution !
We will test that as soon as the 1.5.1 will be released ;-)
Thanks a lot,
Richard.
well, yes there are some definite overlaps there. I was mostly trying to get you a usable fix as fast as possible. I will go back and refactor the whole section this week.
Hi guys,
sorry but it's for a bug again, slighty more difficult than the documentation one ;-)
Well, i found that theSetMethod and theGetMethod don't work when applied on 'B' :
* the working xml :
<mapping>
<classA>A</classA>
<classB>B</classB>
<field-method>
<A theGetMethod="takeA" theSetMethod="giveA">myA</A>
<B>b</B>
</field-method>
</mapping>
* the no-working one :
<mapping>
<classA>fr.maaf.test.mapping.dozer.B</classA>
<classB>fr.maaf.test.mapping.dozer.A</classB>
<field-method>
<A>b</A>
<B theGetMethod="takeA" theSetMethod="giveA">myA</B>
</field-method>
</mapping>
I just put classes on the reverse order, and it doesn't work anymore. The message is :
Error in loading dozer mapping file: dozerBeanMapping.xml : net.sf.dozer.util.mapping.MappingException: net.sf.dozer.util.mapping.MappingException: Unable to determine read method for field: myA class: class A
So it's also impossible to use Custom set() and get() methods in a bi-directional way :-)
I think that's all (today ;-) )
Bye
Seb, Dozer tester 8-D
Thanks Seb. We are re-visiting this functionality this week and re-architecting the way it works. It is still lacking in a few things. Should have it re-factored by next week.
Thanks.
Franz
Sorry about the bug, I did not test if fully because I was trying to get it out so fast.
Don't worry, i'm here to test ;-)
This is now fixed. It was simply a problem in the dozer castor mapping.
Hi,
We have classes with the following API :
Iterator getComputers()
void addComputer(Computer computer)
void removeComputer(Computer computer)
We choose to use Iterator instead List in these API to be sure that the only way for developpers to add a computer is to do :
container.addComputer(c)
They don't have API allowing :
container.getComputers().add(c)
which allow to add something in a container in a way that the container isn't aware of this operation.
The problem is Dozer doesn't let us defined such API ;-(
Why "iterate" fields (with this attribute of the 1.5.1 release) can't have a get method returning an Iterator ?
We can modify our programming rules to make getXxxx returning List instead Iterators but I liked a lot the fact that we can have our programming rules and tell Dozer these rules (instead of modifying these)....
Richard.