On 07/11/2007, at 8:56 AM, Kevin Menard wrote:
I think it's a difference of approach. Largely, I agree with you.
The two
different hierarchies is the root of the problem for me.
Sure, and for many other people as well.
Andrus had mentioned a use case of wanting to keep some methods out
of only
the client class or the server class. My take on it is that obj-
attributes
could be annotated as such and the validation system could handle
this. On
the other hand, I can see a lot of value of not having a setXYZ()
method in
a client class, for example, if calling such would always lead to a
validation failure.
Sure, that could be a check box for each attribute, but isn't that
different to what is being discussed here?
So, ultimately, I'm working towards a single hierarchy. There's a
lot of
code there I'm not familiar with though and if the interface
approach is
incremental and still useful after the fact for certain use cases,
then
great for me :-)
My concern is that this might be the wrong path to go down if we are
ultimately aiming for a common superclass PersistentObject. But your
first comment made it seem like there were reasons to not aim for
that. For the particular case you need this for now, could you do
what you want with just changes to the velocity templates and nothing
else? I know we've hacked ours to provide quite a few extra features.
Ari Maniatis
-------------------------->
Aristedes Maniatis
phone +61 2 9660 9700
PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
