No, you do not have to.
But sometimes you have to remap (in the map) the keys from form to db.
That would be extreme, my point was only that VO could and in my case
should be collections.
I mostly work w/ jTable and DataSource now, which work via "reflection"
(for each)
.V
Joe Wolf wrote:
:
Sent: Tuesday, March 14, 2006 9:57 PM
Subject: Re: How to make dao's / vo's more polymorphic
If you use Struts, it supports maps instead of beans, so no need.
If you use DisplayTag, it takes a collection.
So does DataSource in c#, Flash, and jTable.
So ... there is no such thing
If you use Struts, it supports maps instead of beans, so no need.
If you use DisplayTag, it takes a collection.
So does DataSource in c#, Flash, and jTable.
So ... there is no such thing (giant interface of string constants of
keys) is my case.
It takes the Collection (arraylist of hashmaps) and
fferent than my object data model)
and I'm grateful iBATIS supports them.
-Joe
- Original Message -
From: "netsql" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, March 14, 2006 3:58 PM
Subject: Re: How to make dao's / vo's more polymorphic
Using Collections fo
and has the whole mess memorized).
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of netsql
Sent: Tuesday, March 14, 2006 3:58 PM
To: user-java@ibatis.apache.org
Subject: Re: How to make dao's / vo's more polymorphic
Using Collections for VO makes them *reusab
Using Collections for VO makes them *reusable*, which is what OO's only
goal, to make you more productive via reuse.
They are dynamic VO in the sense that one cad add a column in SQL or in
view from version 1.0 of your web app to 2.0, and you can do so w/o any
code changes in the VO. Sorry that
Vic, this recommendation is completely wrong and borderline dangerous.Maps are not dynamic. Maps are strongly typed, strict data structures that are impossible to associate behavior with. There's nothing OO about them -- Period.
To be frank, I'd prefer if you stop spamming Maps as the solution to
I used to think that, and wrote a still up to date book covering OO,
iBatis and beans, etc., free here :
http://wiki.apache.org/struts/StrutsBookhttp://wiki.apache.org/struts/StrutsBook
But since I have seen and used dynamic langs, and trying to bring some
of the benefits to the still strongly
clue where to start with the Maps method that'd be handy……BEAR IN MIND that I have to start with a collection of XMLObjects, which are actually already value objects.
Best Regards
Paul Carr .
-----Original Message-From: Clinton Begin [mailto:
[EMAIL PROTECTED]]
Sent: 14 March
@ibatis.apache.org
Subject: Re: How to make dao's / vo's more polymorphic
I've been without power
for a couple of days due to a bad storm, so I've missed some of the debate
too. I'm going to sidestep the whole "OOP best practices" talk
(sound and fury).
…BEAR IN MIND that I have to start with a collection of
XMLObjects, which are actually already value objects.
Best Regards
Paul Carr
.
-Original Message-From: Clinton Begin [mailto:
[EMAIL PROTECTED]]
Sent: 14 March 2006 03:46To:
user-java@ibatis.apache.orgSubject: Re: How to make d
PROTECTED]
Sent: 14 March 2006 03:46
To: user-java@ibatis.apache.org
Subject: Re: How to make dao's /
vo's more polymorphic
Don't get me wrong, iBATIS will always support Maps for those who absolutely
need them. But I'll always be very clear, about their place... :-)
tter than the usual JDBC + SQL
string construction garbage we all see from time to time.
Steve
From: Clinton Begin
[mailto:[EMAIL PROTECTED]] Sent: Monday, March 13, 2006 5:10
PMTo:
user-java@ibatis.apache.orgSubject: Re: How to make
dao's / vo's more polymorphic
Fair enough,
Ah. Yes. I *definitely* agree that I would *never* want to use maps for my domain model...
Ack! Talk about anti-OOP
One of these days I'll get around to trying this: create my domain model with the objects
necessary to accurately represent the domain and with only the methods required for t
Using iBATIS to cleanly
structure the SQL has been fantastic, much better than the usual JDBC + SQL
string construction garbage we all see from time to time.
Steve
From: Clinton Begin
[mailto:[EMAIL PROTECTED] Sent: Monday, March 13, 2006 5:10
PMTo: user-java@ibatis.apache.orgSubject:
Fair enough, I agree. You're argument is valid against Sun's design for JavaBeans and the pattern matching approach of getters/setters -- and how they are hardly a best OOP practice (I won't get into that OOP itself isn't necessarily a best practice)
However, your argument does nothing for or
Actually, I've long been annoyed with all our frameworks forcing me to expose all my
domain objects' fields via setters and getters. I've toyed with the idea of doing all my
selects as maps (and my input from the UI layer too) and giving the domain objects the
smarts to pick what they need out o
http://www.mail-archive.com/user@struts.apache.org/msg30063.html by
Husted himself.
I figure every 6 months or so post to remind people of modern dynamic
practice. Give you guys a chance to learn new tricks, like when you get
additional requirements on a project, and nothave decay of cruft.
...and by doing that lose all of the performance, type safety, context and compatibility of a proper domain model. While you're at it, why not dispense with all other best practices as well.Cheers, ;-)Clinton
On 3/13/06, netsql <[EMAIL PROTECTED]> wrote:
You can do that and more including losly c
You can do that and more including losly coupled by using a HashMap as
return type (return ArrayList of Maps from iBatis ) like I do. No more
out of sync beans.
.V
Paul Carr wrote:
Ideally I'd like all my DAO interfaces to extend a BaseDAO
and all my
value
#x27;user-java@ibatis.apache.org'Subject: RE: How to make dao's / vo's
more polymorphic
Yes.
The problem can be somewhat overcome by parsing the source file of the base
class instead of introspecting
but if
it's not source that you are generating it becomes a
om: Jeff Butler
[mailto:[EMAIL PROTECTED]Sent: Friday, March 10, 2006 12:28
PMTo: user-java@ibatis.apache.orgSubject: Re: How to
make dao's / vo's more polymorphic
Yes - that's a difficult problem on many levels. First there's the
difficulty of the introspection (an
l Message-From: Jeff Butler [mailto:[EMAIL PROTECTED]
]
Sent: Friday, March 10, 2006 8:55 AMTo: user-java@ibatis.apache.org
Subject: Re: How to make dao's / vo's more polymorphic
Abator doesn't have support for this now - but it should be fairly simple to add. Abator would not gen
10, 2006 8:55
AMTo: user-java@ibatis.apache.orgSubject: Re: How to
make dao's / vo's more polymorphic
Abator doesn't have support for this now - but it should be fairly
simple to add. Abator would not generate these base objects, it would
just assume they are the
Right….you’d want to write
your own Base objects anyway.
-Original
Message-
From: Jeff Butler
[mailto:[EMAIL PROTECTED]
Sent: 10 March 2006 13:55
To: user-java@ibatis.apache.org
Subject: Re: How to make dao's /
vo's more polymorphic
Abator doesn't have
s
Abator doesn't have support for this now - but it should be fairly simple to add. Abator would not generate these base objects, it would just assume they are there and use them - right???
Jeff Butler
On 3/10/06, Paul Carr <[EMAIL PROTECTED]> wrote:
Hi All,Is there a way to make the DAO's and VO
Hi All,
Is there a way to make the DAO's and VO's generated by abator all extend
a single class or implement a common interface?
Ideally I'd like all my DAO interfaces to extend a BaseDAO and all my
value objects to extend a BaseValueObject automatically as abator
creates them ???
Best Regards
P
27 matches
Mail list logo
