Changes to repository

[jon.ki...@gmail.com]

Hello, all. I've just committed changes to the repository that affect
you. Please read:

I've fixed the repository structure so that the main work is being
done in /trunk/, rather than in an obscure directory under /branches/.
Professor White's original applet is now stored under Branches/
Original_Applet, and the most recent version - the one that went up to
the bio server, and the one which students are using - is under
branches/First_Release.

Anyone committing code will want to re-set their IDE to point svn
commands at
https://tree-buildingsurvey.googlecode.com/svn/trunk

instead of
https://tree-buildingsurvey.googlecode.com/svn/branches/rewrite

The latter will fail.

Professor White - if you haven't used SVN before, I want to make sure
you understand it well enough to get at your code and modify it. We
can do this any time before the end of the semester, at your
convenience.

[Andrew.S...@bbh.com]

Nicely done Jon!  Everytime I went to view the code on google I was wishing that we had it setup that way.  I've started working on the model refactoring and one thing that I wish we hadn't done was include the immortal empty node in the model elements.  It is serving no purpose at all, especially in the string that gets persisted to the the database.


Andrew Schonfeld
Brown Brothers Harriman & Co.
Infomediary Systems
617-772-6738

From:	"jon.ki...@gmail.com" <jon.ki...@gmail.com>
To:	tbs-group <tbs-...@googlegroups.com>
Date:	01/29/2010 02:37 PM
Subject:	[tbs-group] Changes to repository
Sent by:	tbs-...@googlegroups.com

---

--
You received this message because you are subscribed to the Google Groups "tbs-group" group.
To post to this group, send email to tbs-...@googlegroups.com.
To unsubscribe from this group, send email to tbs-group+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tbs-group?hl=en.


*************************** IMPORTANT NOTE*****************************-- The opinions expressed in this message and/or any attachments are those of the author and not necessarily those of Brown Brothers Harriman & Co., its subsidiaries and affiliates ("BBH"). There is no guarantee that this message is either private or confidential, and it may have been altered by unauthorized sources without your or our knowledge. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. BBH accepts no responsibility for loss or damage from its use, including damage from virus. ********************************************************************************

[Jon Kiparsky]

I think I might have a fix for that. Let me play with it for a minute.

[Andrew.S...@bbh.com]

Dude, I wouldn't worry about it for now.  We have already put it into production so all of the data is going to be demolished because once you remove the immortal node (id: 20) you will have to decrement the ids of all of the subsequent elements in the tree.

[Jon Kiparsky]

I don't see how you'd keep it out of the Model without complicating things unnecessarily, but  you could keep it from dumping to the saved tree. Check to see if this is the IEN. If so, return an empty string.

The proper way to check whether this is the IEN, however, requires that Node have access to Model - that's easy enough. Then you've got getImmortalEmptyNode() to compare to.

I won't commit that, since you're at work in Model, but that's how I'd do it, if that extra line bothers you.

[Jon Kiparsky]

I need something to get my head out of tests for a minute, it's cool.

There's a hack you could use: if id==20, don't dump this string.
Boom.

Just don't come crying to me when Brian adds a tse-tse fly to the organisms and all of a sudden things go screwy.

[Andrew.S...@bbh.com]

I think its more aesthetics than anything, but the whole idea of people's saved trees having a gap in their serial number structure once we remove the immortal node is what scares me from doing this.  It would be a change that could go in for the next round of students because we would be working with fresh data.  the thing that I am working on moving the createModelElements, createButtons, & createStudents out of the model and mostly into the view, because the stuff it is creating is mostly for the view not the model.  And when I started looking at this I realized that all we really need is the position of the immortal node(for displaying), a rectangle(to represent an area the user can click on) and then when they click on that rectangle it will create a new empty node which, depending on where the drag it to, will be added to the list of model elements in the model.

It would have saved us the work of having to save a pointer to that immortal object.  But thats 20/20.

[Jon Kiparsky]

Yeah, I'm really not too worried about having the IEN in the tree.
I suppose we could arrange to start numbering Organism Nodes at 1, and let the IEN be id = 0, if you want. That might make life a little easier, in terms of skipping the IEN on dump() without making a break in the sequence, and also in terms of keeping track of the little bugger.

[Andrew.S...@bbh.com]

It has nothing to do with positioning, its just idea that we are devoting so much to the insignificant object.  We have a spot in each treeString for it & we have a property in the StudentModel for it.  Looking back on it we probably didn't need that.  Ehh, something for thought in the future.  Anyways, the refactorings are coming along nicely.

[Jon Kiparsky]

Good to hear the refactoring is coming along. We'll save the Undying Speck for another day.

[Ethan Bolker]

Glad to see the refactoring proceeding. I do hope you are doing it
more or less like the book - that is, making really small changes one
at a time with testing before and after each one, so that you're sure
no functionality has changed.

Having said that, it sounds like good work even if you're not.

Ethan