Welcome, Guest. Please Login
Tinderbox
  News:
IMPORTANT MESSAGE! This forum has now been replaced by a new forum at http://forum.eastgate.com and no further posting or member registration is allowed. The forum is still accessible via read-only access for reference purposes. If you wish to discuss content here, please use the new forum. N.B. - posting in the new forum requires a fresh registration in the new forum (sorry - member data can't be ported).
  HomeHelpSearchLogin  
 
Pages: 1
Send Topic Print
Many user attributes vs. prototype children (Read 11380 times)
Rafter T. Sass
Full Member
*
Offline



Posts: 100
Burlington, VT
Many user attributes vs. prototype children
Mar 23rd, 2008, 7:18pm
 
I've been working on this document to use as a reference and workflow tool for ecological landscape design. I've defined around 3 dozen user attributes to track the various qualities of plant species.

(For anyone who is interested, my seminal reference and inspiration text is the genre-defining Edible Forest Gardens, Vol. I & II, by Dave Jacke and Eric Toensmyer).

I'm wondering now if there isn't a downside to all those user attributes. I originally thought they would only apply to specific prototypes and their descendants, not realizing they would be defined for every note in the document.

Maybe I should go the other route, of using prototype-bequeathed children to hold all, or some, of the data on the plant species?

Can anyone comment on whether either of these routes is likely to make TBX run fast and smooth, and/or whether either approach has proven useful for them in their own projects?

Note that there are only about 100 plant species notes now - there will perhaps several 100 to 1000 later.
(It will take a while to get there though...)



Back to top
 
 
raughter   IP Logged
Ioa Petra-ka
Full Member
*
Offline



Posts: 103
Portland, Oregon, USA
Re: Many user attributes vs. prototype children
Reply #1 - Mar 23rd, 2008, 11:08pm
 
In my experience, having an abundance of attributes does nothing to slow down Tinderbox, or if it does, it is so very little that it hardly matters. What I suggest is to allow prototypes to work as a "lens," letting you see only the applicable attributes for that type of object, through the use of KeyAttributes. Then the full attribute display need only be referenced on occasion, and interfacing with the attributes is done entirely through the note's text area.

In this way, you can have five or six major object types all using their own half-dozen or so attributes, and it matters not that there are a bounty of irrelevant attributes. They are invisible unless needed.
Back to top
 
 

Av
  IP Logged
Mark Bernstein
YaBB Administrator
*
Offline

designer of
Tinderbox

Posts: 2871
Eastgate Systems, Inc.
Re: Many user attributes vs. prototype children
Reply #2 - Mar 24th, 2008, 10:20am
 
Though an attribute potential applies to ANY note, that doesn't mean you need to see it, or use it, for every note.  

Unused attributes don't take up *any* space in memory or require *any* additional computation.
Back to top
 
 
WWW   IP Logged
Rafter T. Sass
Full Member
*
Offline



Posts: 100
Burlington, VT
Re: Many user attributes vs. prototype children
Reply #3 - Mar 24th, 2008, 3:41pm
 
Thanks! That's very useful information.

OK, then: Can I formulate a rule such that KeyAttributes includes all and only those user attributes for which values have been defined?
Back to top
 
 
raughter   IP Logged
Mark Bernstein
YaBB Administrator
*
Offline

designer of
Tinderbox

Posts: 2871
Eastgate Systems, Inc.
Re: Many user attributes vs. prototype children
Reply #4 - Mar 24th, 2008, 4:00pm
 
Usually, you inherit the KeyAttributes from a prototype. So, for example, a Book has an Author, a Title, and a PublicationDate; even if the Author is empty (because you couldn't remember it), you can see the attribute so you know it's missing.

Back to top
 
 
WWW   IP Logged
Rafter T. Sass
Full Member
*
Offline



Posts: 100
Burlington, VT
Re: Many user attributes vs. prototype children
Reply #5 - Mar 24th, 2008, 5:14pm
 
Yes, and...

There are many attributes that don't apply to every exemplar of a prototype, that I don't want or need hanging around the text window of the note.

For instance, many useful plants are non-cropping, so I don't want the attributes Fruit, Greens, Nuts, Roots, Tea, Culinary, Medicine, and Other all showing up as KeyAttributes when they don't have have values assigned.

Right now, my adornment-driven workflow adds attributes to KeyAttributes as it assigns values. This breaks down however, as sometimes values are assigned or juggled outside of that workflow map.

What I'm hoping for is a rule to put in the *PlantSpecies prototype, that assigns to KeyAttributes all those attributes that have values.

I do see another way out, which is to convert my numerous (numerical) crop attributes to one Cropping set attribute, but I'm hoping there is a rule-based way, so I don't have to re-tool the attribute structure, as well as a bunch of adornments in the workflow.

Any ideas?

Thanks so much!
Back to top
 
 
raughter   IP Logged
Mark Bernstein
YaBB Administrator
*
Offline

designer of
Tinderbox

Posts: 2871
Eastgate Systems, Inc.
Re: Many user attributes vs. prototype children
Reply #6 - Mar 25th, 2008, 9:55am
 
The approach I'd reach for first would be to inherit the KeyAttributes from prototypes.  So, for example, you might have ProtoPlant, which has KeyAttributes that apply to all plants (FoliageColor, say).  Then you'd have another prototype for CroppingPlants, which inherits from ProtoPlant but adds some more key attributes that are shared by all cropping plants.  You could elaborator this further with FruitingPlants, which inherits from CroppingPlant and adds some additional attributes that apply to all Fruiting Plants.  

Now, perhaps this won't work because you're using inheritance to do something else.  But this is one natural approach, and I belabor this because I think it's much easier than doing the same thing with rules.
Back to top
 
 
WWW   IP Logged
Rafter T. Sass
Full Member
*
Offline



Posts: 100
Burlington, VT
Re: Many user attributes vs. prototype children
Reply #7 - Mar 25th, 2008, 12:55pm
 
This makes sense. I will try it.

Really, a Cropping set attribute makes sense to, I'm just resisting the retool.

Thanks!
Back to top
 
 
raughter   IP Logged
Pages: 1
Send Topic Print