Data Manager Library: Sample Calling Application
From: Matthew Jones [mailto:firstname.lastname@example.org]
Sent: Friday, December 15, 2006 12:37 AM
To: Duane Costa
Cc: 'Jing Tao'
Subject: Re: Sample calling application
Hi Duane and Jing,
A samle app sounds great. Comments inline...
Duane Costa wrote:
Could you add your comments to this discussion about a
application in the Data Manager Library code? Jing and I both agree
that a sample calling application (as opposed to Junit
tests) would be
a useful addition to the distribution, even if it's limited
to just the user documentation. However, there are a couple
of loose ends Jing and I feel unsure about (see below). After
you add your comments, I'll open a Bugzilla entry for this.
On Wed, 13 Dec 2006, Duane Costa wrote:
I think it would be nice to provide a sample calling
the Data Manager Library source code distribution. It would
just be a
small program, together with implementations of the
call-back interfaces for database connection pool and Ecogrid end
point, to demonstrate the different use cases. Do you
think this is a
good idea? If so, there are a few minor things to decide:
It is great idea.
Good! I'll work on the sample program. I'll also add a new
Bugzilla bug to document these ideas after Matt adds his comments.
- Where to put the source code -- One possible package would be:
This package sounds good to me.
I am not sure. But I think since it is sample and it will
be good to
be easy found by the user. So we can still use the package you
prosposed, but can we put them into a another dir
- sample, which is parallel to src? The dir structure will
This sounds fine. Maybe we need a separate ant target in
compile the sample code, something like 'ant
Sounds fine. If its easier to just include the code in src
then I might just do that instead of making the parallel
hierarchy. But either way is fine.
- How to set properties -- The main program could hard-code the
database values as constants, or the main program could
from the lib/datamanager/datamanager.properties file. The
the first approach is that it keeps the database values
together in the same file with the main program; the
has the advantage that users can edit
datamanager.properties and run
the sample program without needing to recompile. Which approach do
you like better?
First, I have a question. How do you plan to run this
sample code? It
will be compiled and distributed too? Or user should compile it by
himself or through build.xml? Or even just give user an
idea how to
use the library and we don't have plan let user run it? If we just
want to show user how to use the library and I think it is okay to
hard code in main program.
If we plan to let user run it (like our test file, it is
those values in the property file.
I don't know which approach is best. Maybe we just want to include
sample code primarily as part of the documentation, without any
expectation that the user will actually compile and execute
it. Or maybe we do want the end user to try it out
themselves. I think we need Matt's input on this.
Let's use a properties file. Hardcoding these values in code
is a bad example to set.