Hi David L,
I've implemented an initial version here:
https://svn.apache.org/viewvc?view=revision&revision=1765430
I had to rename the methods a little bit. The to() has the actual
implementation type, just as before. The new method added is target() which
is where you can specify how to view the
HI David B.,
Yup, something like that would do just fine!!
Thanks a lot.
Cheers,
=David
> On Oct 18, 2016, at 7:43 PM, David Bosschaert
> wrote:
>
> Hi David L,
>
> The as() method (at least in its current incantation) say something about
> how to treat the source object - the thing you
Hi David L,
The as() method (at least in its current incantation) say something about
how to treat the source object - the thing you are converting from. So in
your example
myDtoWithMethods =
converter.convert(map).as(PlainDTO.class).to(DtoWithMethods.class)
it would try to treat the source map
Hi David B.,
Thanks for this suggestion. That would indeed work nicely. As you say, it
requires an extra class, but at least there is very little duplication, at
least converting TO something.
Converting TO:
> Map m = converter.convert(myDtoWithMethods).as(PlainDTO.class).to(Map.class)
When
Hi David L,
Recently I added the 'as()' method to the converter, which is really meant
to disambiguate source objects. Let's say you have an object that is both a
JavaBean as well as implementing an interface. The Converter spec will
specify some 'priority' rules for this, but they may not always
Hi David B.,
Thanks. I think you’re right, the spec is quite clear.
If I wanted to treat any class like a DTO (ignore the methods and use only the
public fields — just like before the recent changes made to the code base), can
you think of any way?
Perhaps having “strict” mode to follow the s
Hi all,
The OSGi spec for DTOs is pretty clear. Section 57.2 of the R6 Core spec
states:
"Data Transfer Objects are public classes with no methods, other than the
compiler supplied default
constructor"
Therefore I would be reluctant to use a different definition for the
Converter.
OTOH I think
Hi David L,
I imagine the “extra step” and “redirection” are the need to create both the
SomeDTO and the SomeImpl?
Thinking about this a bit more I’m reminded that sometimes I end up thinking
that putting that first “this” parameter back into every method that C++ took
out might be a good ide
Hi David J.,
That is an interesting perspective.
Also based on the ideas proposed by Peter, and after a bit of experimentation,
these are my thoughts:
* Java object encapsulation “works", but only if we assume that there is
no such thing as reflection. Since an object can be introspected
A while ago Peter said something about DTOs violating data hiding or
encapsulation and I decided that if you think of the DTO as a primitive data
type they don’t. Following this line of thinking (which I have not been able
to try out in practice, just as thought experiments) you’d have
public
Hi!
I only noticed now that according to the RFC, DTOs cannot contain methods. I
can understand why this is so, and I do not object.
However, I have found a very practical design pattern whereby I use classes
that act both as DTOs and domain value objects. In effect, this means that they
are
Hi!
I only noticed now that according to the RFC, DTOs cannot contain methods. I
can understand why this is so, and I do not object.
However, I have found a very practical design pattern whereby I use classes
that act both as DTOs and domain value objects. In effect, this means that they
are
12 matches
Mail list logo
