cronometer-development — Development Related Discussion for CRONOMETER

[Cronometer-development] newbie question: crdb_004

[Richard W. <ri...@gm...>]

I checked out the cronometer code, but had to make some adjustments to get
it to run. It appears to be looking for a crdb_004 (no extension)
file/directory, but I only see crdb_003.jar in the repository. Is crdb_004
an updated food list that didn't make it to the repository, or am I doing
something wrong?

[Cronometer-development] localization support

[Pál F. <pal...@gm...>]

Hi

It would be really nice if cronometer had localization support. I believe it
could reach a lot more users this way.

Regards,
Pál

[Cronometer-development] fiber calories

[Geoffrey L. <geo...@gm...>]

First, must say I love CRON-o-Meter!  Use it all the time for myself and for
patients.

Generally, the fiber fraction of carbohydrate is considered as having
between 2 and 2.5 calories per gram.  Based on my own calculations, it does
not seem that CRON-o-Meter takes this into account in its calculations.  Why
not?  Or better, could this be done?

Thank you for a great program!
Geoffrey Levens, L.Ac.

[Cronometer-development] Cronometer crashes Fedora 10 KDE sessions...

[Linuxguy123 <lin...@gm...>]

In case anyone out there is listening and interested, Cronometer 0.95
crashes F10 KDE 4.3.2 sessions completely every time its run.  

I think the problem has something to do with the redraw method because
the crashing starts when the application is moved on the desktop.  But
other things will trigger it to.

Reply if you want more information.

LG

[Cronometer-development] Cronometer Rocks !

[Linuxguy123 <lin...@gm...>]

My gf and I are using Cronometer to track our fitness progress.  She is
running it on Windows and I am running it on Linux.

Cronometer rocks.  Its outstanding.  We both enter our foods every day.
We are entering our weight, %body fat, lean muscle mass, etc. using a
modified biomarker setup.

The graphs with the "n" days averaging are great.

Its a really well thought out and implemented program.   Kudos to the
developers.

LG

PS: how come nobody ever talks on the developer list ?

[Cronometer-development] Extending Cronometer...

[Linuxguy123 <lin...@gm...>]

I'd like to extend Cronometer to record my workouts and to store the
daily images I am taking of myself.

Does anyone have ideas on how this should be done ?  I'll contribute my
work back to the project if its wanted.

Thanks

Re: [Cronometer-development] Cronometer won't get through first start up.

[Kim L. <ki...@gm...>]

I just installed Cronometer onto my girlfriends laptop that runs Vista.
It works.

Thanks

[Cronometer-development] Cronometer won't get through first start up.

[Linuxguy123 <lin...@gm...>]

I am trying to install Cronometer 0.94 on a Fedora 8 computer. 

$ uname -a
Linux localhost.localdomain 2.6.26.6-49.fc8 #1 SMP Fri Oct 17 15:59:36
EDT 2008 i686 i686 i386 GNU/Linux

$ java --version
java version "1.5.0"
gij (GNU libgcj) version 4.1.2 20070925 (Red Hat 4.1.2-33)

Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

Cronometer starts and displays the splash screen and even the software
acceptance notes and then died as follows:  

$  sh ./cronometer.sh
Header Chunk. Image width:100 height:100 depth:8 color type:6
compression type:0 filter type:0 interlace:0
Initializing settings file /home/xxx/.cronometer/Settings.xml
Creating settings file /home/xxx/.cronometer/Settings.xml
Loading index...
Loading index...
Loading Deprecated index...
Loaded 37 foods.
Loading index...
Loading Deprecated index...
Loaded 7878 foods.
Loading: /home/xxx/.cronometer/Default User/servings.xml
  --> file does not exist
Loading: /home/xxx/.cronometer/Default User/notes.xml
  --> file does not exist
Loading: /home/xxx/.cronometer/Default User/metrics.xml
  --> file does not exist
Loading from disk
Add Biomarker: Weight
Add Biomarker: Body Temperature
Add Biomarker: Systolic BP
Add Biomarker: Diastolic BP
Add Biomarker: Resting Heart Rate
Add Biomarker: Blood Glucose
java: xcb_io.c:228: _XSend: Assertion `!dpy->xcb->request_extra' failed.
./cronometer.sh: line 10:  4761 Aborted                 java -cp
cronometer.jar:jcommon-1.0.10.jar:jfreechart-1.0.6.jar:swingx-0.9.3.jar:cronometer.jar:usda_sr20.jar:crdb_003.jar:docs.jar ca.spaz.cron.CRONOMETER

Any ideas ?

Thanks

[Cronometer-development] Location of file containing personal data?

[Bill S. <bi...@be...>]

I'm going to rebuild my os and need to make sure that my personal data is 
included in my backup copy of cronometer. I have a directory, /opt/cronometer 
with the following items in it:

apache-log4j-1.2.15  httpunit-1.7           license.txt        README
CRONoMeter.app       jcommon-1.0.8          liquidlnf.jar      rhino1_7R1
cronometer.sh        jfreechart-1.0.10      liquidlnftest.jar  
swing.properties
easymock2.3          jmock-cglib-1.2.0.jar  looks-2.1.4
hsqldb               jmock-core-1.2.0.jar   lpr
htmlparser1_6        jtidy-04aug2000r7-dev  __MACOSX

Is my data in the above somewhere, so that when I copy these files back to my 
new clean hd I have not lost everything I've recorded for the past month or 
so?

TIA,

Bill

[Cronometer-development] How to build cronometer?

[Bill S. <bs...@be...>]

Any build/install documentation anywhere (linux)? Having trouble building 
this.

TIA,
Bill

[Cronometer-development] Wishlist

[Nickolay <nic...@ho...>]

Hello,
=20
Great work on the program, I am an avid user.=20
=20
There are three features that I think would enhance the program:
=20
1. When a serving is inserted, put the time it was inserted before the serv=
ing (should be editable).=20
2. Ability to insert "topics" in between servings to separate them, i.e. br=
eakfast, lunch, 1 hour workout, cardio etc (these should be user defined).
3. Same as point 1, timestamp when the note was written.=20
=20
I think point 1 and 2 would be really useful as it is important to eat at t=
he right time and would be useful features for a nutritionist to evaluate t=
he diet.=20
=20
Again, great work guys! =20
=20
=20
Nickolay

_________________________________________________________________
Connect to the next generation of MSN Messenger=A0
http://imagine-msn.com/messenger/launch80/default.aspx?locale=3Den-us&sourc=
e=3Dwlmailtagline=

Re: [Cronometer-development] Recent interface changes

[<aa...@sp...>]

> Regarding the "Add Serving" button.  I am used to keyboard shortcuts
> in the Windows fashion (underlined letter indicates which letter to use
> with the alt key).

Control-Letter menu shortcuts have been standard practice around on
Windows since at least Windows 3.x.... I can look at adding alt-key
accelerators as well.

> I am not sure I understand the double-tabbing choice however.  If
> you were to use single tab to move from the match input field to the
> list then to the amount field, wouldn't it give exactly the same behaviour
> and allow the user to optionally stop off at the list and use the arrow
> keys to change the selection, while maintaining expected behaviour?

Not quite that simple because then clicking an item would no longer
transfer focus. I can try and detect the difference between a click and a
tab, and handle it differently...we'll see.

It takes two tabs to select the top item -- one tab to select the table
itself, then the second tab selects the row within it. A normal table then
has tab cycle through every cell, then when it reaches the very last cell,
it goes on to the next component. If your search results had a lot of
hits, it could take a lot of tabs to exit. It's tricky stuff to get right
in Java. I'll spend some more time playing with it.

Re: [Cronometer-development] Recent interface changes

[Richard T. <ric...@gm...>]

On 1/22/07, aa...@sp... <aa...@sp...> wrote:
> For a more detailed analysis of why the change to the main window was
> made, and why it's faster, check out my recent post: http://spaz.ca/?p=219

Removing the search panel to a window is fine by me.  But I would like to
try and persuade you that the way it is now, it is not very simple to use
and does not behave in expected ways (although perhaps my
expectations are biased in some unreasonable manner by using
Windows).

Regarding the "Add Serving" button.  I am used to keyboard shortcuts
in the Windows fashion (underlined letter indicates which letter to use
with the alt key).   Understandably this is a Java application and I can't
expect Windows conventions to apply, but the next usability standard
(which comes to my mind at least) does not work either. That is being
able to give focus to a button and for the button to retain focus.  When
I use an application, I usually expect to be able to tab to a button, then
hit enter to select it.  And if it opens a window, then when the window
closes, focus remains on the button in the main window (and enter
can be hit again to get a new serving window).  But ctrl-e while
unexpected works fine of course.

I am not sure I understand the double-tabbing choice however.  If
you were to use single tab to move from the match input field to the
list then to the amount field, wouldn't it give exactly the same behaviour
and allow the user to optionally stop off at the list and use the arrow
keys to change the selection, while maintaining expected behaviour?

Anyway, thanks for your continuing work! :-)

Cheers,
Richard.

Re: [Cronometer-development] Recent interface changes

[<aa...@sp...>]

> Hi,
>
> Some of the recent interface changes to Cron-o-meter have made it
> harder for me to use, so I thought I would post a quick note about it.
>  I am refering to moving the addition of servings from the left-hand
> side of the window to a pop-up window through a button specifically.
>
> While not the most well-advised approach to ensuring a balanced diet,
> I tend to write down all I have eaten during the day, their weights
> and at the end of the day or when I get a chance I enter them one by
> one.
>
> When the "Add Serving" was the left-hand side of the main window, I
> could do this completely through the keyboard relatively quickly.
> However there was one bug, when you entered the food name into the
> input field for the first serving you added, it would not tab from
> that field to the top matched food (or any of the matched foods).
>
> Now that this functionality is in a fresh window created by a button
> press, I get the non-tabbable behaviour everytime I add new servings.
> In addition to having to use the mouse to select "Add Serving" I have
> to use it to select whatever match I wanted.
>
> Anyway, hardly critical, but something I thought might be worth
> mentioning,
>
> Cheers,
> Richard.

Hi Richard,

Use the keyboard shortcut to pop up the 'add serving' dialog box.
You can double-tab from the search field to the top hit. Unfortunately,
since selecting any result transfers keyboard focus to the 'amount' field,
you can't arrow through the results. It had to be one or the other.

For a more detailed analysis of why the change to the main window was
made, and why it's faster, check out my recent post: http://spaz.ca/?p=219

Cheers,
Aaron

[Cronometer-development] Recent interface changes

[Richard T. <ric...@gm...>]

Hi,

Some of the recent interface changes to Cron-o-meter have made it
harder for me to use, so I thought I would post a quick note about it.
 I am refering to moving the addition of servings from the left-hand
side of the window to a pop-up window through a button specifically.

While not the most well-advised approach to ensuring a balanced diet,
I tend to write down all I have eaten during the day, their weights
and at the end of the day or when I get a chance I enter them one by
one.

When the "Add Serving" was the left-hand side of the main window, I
could do this completely through the keyboard relatively quickly.
However there was one bug, when you entered the food name into the
input field for the first serving you added, it would not tab from
that field to the top matched food (or any of the matched foods).

Now that this functionality is in a fresh window created by a button
press, I get the non-tabbable behaviour everytime I add new servings.
In addition to having to use the mouse to select "Add Serving" I have
to use it to select whatever match I wanted.

Anyway, hardly critical, but something I thought might be worth mentioning,

Cheers,
Richard.

Re: [Cronometer-development] Daily nutrition summary exceeded targets

[Richard T. <ric...@gm...>]

On 1/8/07, aa...@sp... <aa...@sp...> wrote:
> > I checked in my experimental version changes.
> >
> > Have a look, play with it and see if you think it's worth diverting in
> > that direction.
> >
> > Ideally I'd polish it and make it faster to enter food (keyboard shortcuts
> > and auto-focus things better as you move through the window).
> >
> > Also, this quick hack introduces a few minor bugs here and there, so
> > beware.
>
> Oh, and also it will require finding a better home for the food database
> editor actions (import/export, new food, new recipe, delete food, etc...)
>
> They are kind of homeless at the moment...

Hi,

I started using Chronometer several months back, and it has been very
useful.  But this reminds me of a feature I have been wanting which I
would like an opinion on.

One thing about the food database and entering new foods which I
would like is the ability for the use of overriding (kind of like inheritance).
For instance, living in an expensive country where the variety of items
is limited and nutritional analysis of what is available is .. unavailable, I
tend to enter the limited nutritional information which the products give
over the closest product I can find in the database.

Doing this requires:

  a) exporting a similar food
  b) importing it under the new name
  c) modifying the known values to be correct the for local alternative.
  d) hoping I chose the right similar food.

However, what I would rather like is the ability to set known values for
a food and to have the ability to point the food at a base food which
it would fill in all the unfilled fields for.  This way, if I ever had
to rechoose
what similar food I based it on, it would be correct for all use of the
food from day to day.

Is this change practical in terms of how the Chronometer source code works?
Any tips on what in general might have to be done to do it?

I have to also add that I was quite impressed how easy it was to run the
downloaded source code from the repository.  Just opening it up in Eclipse
did the job.

Cheers,
Richard.

Re: [Cronometer-development] Daily nutrition summary exceeded targets

[<aa...@sp...>]

> I checked in my experimental version changes.
>
> Have a look, play with it and see if you think it's worth diverting in
> that direction.
>
> Ideally I'd polish it and make it faster to enter food (keyboard shortcuts
> and auto-focus things better as you move through the window).
>
> Also, this quick hack introduces a few minor bugs here and there, so
> beware.

Oh, and also it will require finding a better home for the food database
editor actions (import/export, new food, new recipe, delete food, etc...)

They are kind of homeless at the moment...

Re: [Cronometer-development] Daily nutrition summary exceeded targets

[<aa...@sp...>]

I checked in my experimental version changes.

Have a look, play with it and see if you think it's worth diverting in
that direction.

Ideally I'd polish it and make it faster to enter food (keyboard shortcuts
and auto-focus things better as you move through the window).

Also, this quick hack introduces a few minor bugs here and there, so beware.

[Cronometer-development] I'll do a little biomarker prototyping

[Gerald T. <ge...@sa...>]

Aaron

I'm going to try this out (if I may quote my own self):

>Interestingly, the left hand with the food search, select, create etc. only
>has a connection with the diet page, not with biomarkers or exercise.
>Radical thought... should the whole UI become 3 pages that fill the 
>window -
>Nutrition (Diet), Biomarkers, and Exercise? The left hand side of the
>Biomarkers and Exercise pages become like the food search, select, create,
>etc. only for their respective things? Hmm... sounds pretty wild, but makes
>me think.

I did a quick lo-fi paper sketch and it holds up; I'll do some hi-fi 
prototyping in code.
If I'm ambitious I'll try something for Exercise too, because that style of 
UI is probably more useful there. It's a bit of overkill for Biomarker but 
does allow for multiple readings in a day which the current UI does not. 
Also, some consistency is usually not a bad thing.

Let me know if you already had different ideas.

(This would be for after .7)

Regards
Gerald 

[Cronometer-development] Daily nutrition summary exceeded targets

[Gerald T. <ge...@sa...>]

Aaron

We talked before about how in the bar chart for the nutrition summary it is 
desirable to show not just progress toward 100% of a target but also show 
(immediately and obviously) if you are exceeding a target and by how much. I 
had done that in my app by making the chart very wide and drawing a vertical 
line at 100%. Your technique of shading from blue through purple to red is 
much better, it is visually appealing and doesn't require any extra real 
estate. But it is not used on the Summary tab, only on the Target column of 
the detail tabs. Maybe using it on the Summary tab too would be a good idea. 
Not quite as colourful as now (and I'd miss that, I might exceed some 
targets on purpose just to add some red) but it would be a nice presentation 
of additional information using no more space.

Regards
Gerald 

[Cronometer-development] Fw: Biomarkers thoughts

[Gerald T. <ge...@sa...>]

Forwarding to list.
----- Original Message ----- 
From: "Gerald Turnquist" <ge...@sa...>
To: "Aaron Davidson" <aa...@sp...>
Sent: Tuesday, January 02, 2007 5:12 PM
Subject: Biomarkers thoughts


>> - I like to put a moving average on the weight graph (my only
>> biomarker) to smooth out the fluctuations. The biomarker part of
>> Cronometer might be easier to use if the check boxes were over in
>> user preferences and the ones you had selected there all appeared
>> in the biomarkers tab (i.e. entry field and the chart already
>> showing, and right on that tab rather than the chart in a dialog).
>
>
>>>I've always wanted moving averages for weight (and other charts).
>>>Actually, the whole biomarker tracking feature set needs a lot of
>>>love. I am not happy with what I have there at all. I hate the UI,
>>>want to plot various things against one another (and against
>>>calories, protein, etc...). Also, the users should be able to track
>>>any custom metrics, and take readings at any time of day (for
>>>instance many diabetics want to take blood glucose readings several
>>>times a day, and chart it along with things like sugar intake). If
>>>you're interested in this, we can talk more about it. I'd be happy to
>>>say 'go wild'.
>
> Here's my thoughts at this time (bound to change as I try to implement).
> Let me know if I'm already off track anywhere.
>
> To accomodate custom biomarkers, make their definition in data rather than 
> code.
> Define (and select) in preferences, have the current ones predefined for 
> selection
> (or customization).
>
> Make which metrics are selected persistent i.e. not having to re-select to 
> enter a value for the
> metric for the current day. That means for each of the metrics the user
> has selected in their preferences, there will be a panel in the biomarker 
> view. I'd like
> to show all the charts at once on the biomarker tab and scroll that panel 
> (rather than
> having to click a button to see the chart) but that might be too much if 
> you track all of
> them, need to prototype. I did like having that weight chart on my
> main window in my program. Wonder if I could put the biomarkers into tabs 
> and put that right on
> the daily summary (not a separate Biomarkers tab, more like the tabs of 
> nutrients).
> Depends on real estate, I'll keep it to 1024x768.
>
> Try not to change the BiomarkerHistory format for now so there is no data 
> conversion needed.
>
> Assume all charts have date/time as the x-axis but some you might want to 
> record time as well as
> date (I guess all except weight might be suitable to have time). Ability 
> to select the
> start date/time and end date/time for viewing on the chart. Assuming that 
> for something like blood glucose
> and the person takes several readings in one day, they would also like to 
> zoom out to view trends
> over multiple days. Zoom out averages data for each day to collapse to one 
> data point per day?
>
> The y-axis label can be just the name of the biomarker like now.
>
> Leave for future enhancements the ability to combine markers on one chart 
> e.g. blood glucose vs
> sugar (food in general?) intake, multiple days of multiple readings 
> overlaid on one chart to see
> variations in days, carbohydrate intake vs weight, the imagination runs 
> wild.
>
> Biomarker definition
> - name
> - value
> - units? only if we want to show that on the y-axis label I guess
> - typical starting value? like 70 for heart rate.
> - valid range for editing? assume all values are numeric floats
> - choose whether to show moving average
>
> Predefined biomarkers (like now)
> - weight
> - body temperature
> - systolic bp
> - diastolic bp
> - resting heart rate
> - blood glucose
>
> BiomarkerPanel - one for each selected biomarker
> - name
> - time entry field (optional). Date is assumed to be the current day being 
> viewed.
> - value entry field
> - chart
> - start date/time for chart
> - to date/time for chart
> Makes me wonder if the data entry use case is different enough that it 
> isn't on the same panel
> as viewing the chart (contrary to my earlier comment). Need to think some 
> more and prototype.
> The moving average thing should be easy, it came free with JFreeChart if I 
> remember correctly.
>
> Enough thinking! I feel the need to code!!
>
>
> p.s. I see comments in the code about using a proper DB at some point. I 
> do have experience with JDO as an
> OR mapping technology. It is very similar to the new JPA which might be 
> the more appropriate choice
> (the OpenJPA implementation) for this project, using an open relational DB 
> like HSQL. We could go wild
> and use an object database like db4o but that might be risky. In any case, 
> a real database is probably
> overkill at this point and a distraction from getting to a stable 1.0 
> release, but could be fun in
> the future. 

[Cronometer-development] Fw: Biomarkers thoughts

[Gerald T. <ge...@sa...>]

Forwarding this to the list partly to try out the list and partly to put it 
somewhere less ephemeral than email.

----- Original Message ----- 
From: "Gerald Turnquist" <ge...@sa...>
To: "Aaron Davidson" <aa...@sp...>
Sent: Tuesday, January 02, 2007 8:22 PM
Subject: Re: Biomarkers thoughts


> Ok, I think I'm tuning in to the pattern you're going for. I'll paraphrase 
> to see if I've got it.
> - The right hand pane is about one day.
> - The diet page has two parts; the list of food servings consumed and the 
> nutrition analysis at the bottom - all for that one day selected at the 
> top.
> - The biomarkers page is a dilemma. The data entry would be for one day 
> and fits the pattern (multiple entries for some biomarkers, maybe a list 
> similar to the foods on the diet page?). A chart at the bottom showing 
> intra-day measurements would fit the pattern. An inter-day chart spanning 
> multiple days would not.
> - The exercise page seems like it would present the same issues. Data 
> entry for one day, probably allow for multiple entries for the day, desire 
> to see a chart/report for one day, desire to see a chart/report spanning 
> multiple days.
> - The Nutrition Report off the Reports menu seems like the same thing 
> again. That is, it is a view of data across multiple days, this time for 
> food (maybe with the idea of printing or exporting some time?) Right now 
> it is shown as a table but no reason why it wouldn't benefit from some 
> graph or chart view too. It even has the from/to dates I wanted for the 
> biomarker charts.
>
> Seems like we have the same problem in three different disguises. Good 
> news about that is that if we come up with a good solution it might apply 
> across the board. Maybe any intra-day reporting goes on the tab but all 
> inter-day reports are off the Reports menu. I did love my little Weight 
> chart but I confess it was largely because it looked purty, but it doesn't 
> scale up to a whole biomarkers subsystem.
>
> Interestingly, the left hand with the food search, select, create etc. 
> only has a connection with the diet page, not with biomarkers or exercise. 
> Radical thought... should the whole UI become 3 pages that fill the 
> window - Nutrition (Diet), Biomarkers, and Exercise? The left hand side of 
> the Biomarkers and Exercise pages become like the food search, select, 
> create, etc. only for their respective things? Hmm... sounds pretty wild, 
> but makes me think. And I was just going to do a little biomarker 
> renovation. Maybe time to rein in the perfectionist tendencies and do the 
> absolute minimum now to improve it while these more grandiose thoughts 
> gestate. (To be perfectly honest, as a user I could live without any 
> biomarkers or exercise capability at all as long as the nutrition part was 
> excellent and easy to use)
>
>
> As for the database, I was following a similar path with my system, 
> including using it to try out technologies. I did have an HSQL database 
> (DB2 first until I thought I might share the program). The searches were 
> surprisingly fast (not quite as fast as COM) but the program took about 30 
> seconds to load because I was loading the whole nutrients part of the 
> database. I wouldn't do that again for the static data, I prefer the zip 
> files. I'm perfectly happy to shelve the database idea indefinitely and 
> only reconsider it for user data, and then only if the current scheme 
> seems like it can't be shored up to handle a few years of user data.
>
> Gerald 

Re: [Cronometer-development] [CRCOMMUNITY] Fw: Questions for bloggers using CRON-o-Meter

[<aa...@sp...>]

> Aaron,
>
> I would be willing to help with the "help" file.  I know nothing of
> coding, but I have a talent for breaking anything down to a set of
> instructions that a first grader could follow.  If you require such
> services just tell me where to start and what, in general you would
> like to see in the help file.
>
> Thanks again for this awesome and free software, I cannot imagine doing CR
> without it!!

Hi Heather,

Well, I'm *terrible* at breaking things down into simple instructions, so
YOu tell ME what should be in the help file :-) Antonio Zemora did the
initial help web page, which is a good start but is already a little out
of date. That would be a good place to start. You can enhance the content
already there or start fresh. You can give us new HTML, a word document,
or a PDF file. If you have any ideas on how to embed user-assisted help
within the program itself, we can do that as well.

For instance, some of the screens already have brief explanations along
the side-bar of the dialog. If you can suggest re-wordings to make them
easier to understand, or new content to add to existing areas, we can look
at doing that as well. We can also add tooltips to things that need them.

A good place to start would be to go under the Help menu and see what's
there already and then look at what needs to be improved.

Cheers,
Aaron

Re: [Cronometer-development] Design of food/datasource

[Aaron D. <aa...@sp...>]

I'm all for the changes, and it should help both of us jump-start back 
into working on it.

[Cronometer-development] Re: Design of food/datasource

[Chris R. <ch...@of...>]

A bit more on examination...

The issue here is with an unfortunate mix of action/dependency
methods.  There are some parts of each class that handle things that
should be handled in other classes.  For example, an SQLFood should
handle writing itself to the database, not the datasource.  The whole
point of the Food interface is to separate that out, and I should have
done that work back when I split things out into interfaces.

I'm starting to think that the nutrientTable class needs to be looked
at again, too -- as mentioned below, the reflection-based design
forces code changes if we want to take on additional nutrients, where
a map-based (and factory patterned) NutrientTable single class with a
private constructor and hashmap nutrient names (which can be populated
from the schema, even -- this is not a large stretch) would be more
flexible in the long run.

I think that the latter of those two is easier to do, and might put my
head back in the right space for working with this.  The downside to
the changes I'm proposing here is that they will of necessity change
the way the interface to the food data sources operates.  I'll try to
minimize it, but I can't guarantee anything.  Saving and loading
foods, especially, will change.  Essentially, once you have a Food,
you should no longer need to know about its datasource, so long as you
know if you can edit it (to which end I have split Food into Food and
MutableFood, which inherits from it)

On 10/10/05, Chris Rose <ch...@of...> wrote:
> I know that this is mainly my fault -- I should have examined this in
> the redesign, but in adding the functionality to distinguish identical
> foods, I have come across a flaw in the design of the food/datasource
> model.
>
> The issue, as I see it, is that the datasource is too tightly coupled
> to HOW the food is stored in the backing store, especially w/r.to the
> writeable foods.  What needs to happen is that all writes to the food
> tables need to be handled internally to the food (EJB-style -- I
> wonder if a future rewrite could use the Spring framework?) and the
> datasource just needs to handle the aggregation and searching of the
> contents of the store.
>
> So, the upshot of this is, I need to tear the guts out of the
> datasources and make them more...  robust in order to make the
> duplicate food problem go away, and render this whole bag of code more
> maintainable over the long term.
>
> I'm also a bit skeptical about the use of reflection to map nutrients
> -- it leads to a relatively small set of code in the child classes, to
> be sure, but I think I can accomplish the same with a hashmap and a
> string array, and let the code be more extensible over the long term.
> With permission, I'll go in and make that change, as well.
>
> Back on track :)
> --
> Chris R.
> =3D=3D=3D=3D=3D=3D
> Not to be taken literally, internally, or seriously.
>


--
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.