Clifford Heath wrote:
Ok Hal, I've had a read of your API. I created an ORM model of it
in fact, using VisioModeler. That's ORM as in Object Role Model.
The reason I've taken an interest in this is because I believe that
such a tool can benefit strongly from an aspect-oriented data model,
more on that later.
Wow, I'm speechless. I didn't expect anyone to pay such close attention.
Good move not starting on the GUI, but you need to start even further
back, with a conceptual data model. The API is then a simple consequence
of the data model.
That may be true, but if the API is a "simple consequence," I would guess
that the data model is pretty heavily specified.
You have a few bits of mixed terminology or terms used only once.
For example:
* I assume that "name" and "title" are the same thing?
Yes.
* You also use the word "key" - again, is this "title" or
is it a path in the data store?
The key is a unique string assigned to each item. It serves as a
literal key into each database table. See the bottom of the file.
* What's the significance of the "current" topic - is that just a
presentation thing or does it affect searching? No other function
seems to indicate that the current topic is relevant.
I'm undecided on that issue. It certainly affects presentation, but
it's not obvious to me whether the notion of a "current" topic makes
certain operations easier. I *think* it does.
* What's the effect of "load"ing a topic of note?
Did you mean "topic OR note"? A "load" simply references all the tables
needed to get the "pieces" of an object, then assembles them into a
"real" Ruby object (of class Note or Topic) and returns it.
Functionality questions:
* When you change the root topic of an app, what happens to all the
now unreachable topics and notes? Is the change persistent? Perhaps
you could replace this problematic operation with a simple "flip
parent and child" operation?
That's also unclear to me at this time. I was thinking along the lines
of a Unix "chroot" operation -- "pretend" that this subset of the tree
is the whole tree for now. Not sure this concept is useful.
* It isn't clear whether find_topic searches content or just titles.
In the "simple" form it searches only titles. In the block form, you can
access any or all content or metadata for purposes of searching, but you
do it explicitly (by analogy with Enumerable#find).
* It seems that topics and notes differ only in that notes have content,
which requires a different presentation, and in whether the metadata
inherits
That may be true, but it hurts my head to think of the terminal and non-
terminal nodes as being the same thing. It's a very CS approach, of course,
but it doesn't fit my mental model.
> (BTW, this isn't inheritance I believe, but propagation down
the tree - is that right?).
I'm not sure what you mean. There are probably good reasons not to call it
inheritance. But it's not simple cascading, i.e. doesn't affect siblings.
Why bother with the two things - instead you could simply load all
items having no content as your tree.
Probably is doable, but again, doesn't fit the way I think.
Aspect orientation suggestion:
Your model has a number of different kinds of data value associated
with each note or topic. For example, you have info on date/time and
number of times accessed, modified, etc. You have GUI variables. You
have sorting and searching (keywords).
If you regard each item (topic/note) as having values for variables,
you can model the variables as pertaining to a relevant (meta-)topic.
So for example, you could have a Presentation topic, which contains a
Note sub-topic. The variables whose values define the presentation of
a note "belong" to the Note class, but "pertain" to the
Presentation/Note subtopic. I also allow Items to pertain to other
items.
It sounds like you're talking about multiple "views" of the data, is
that correct?
In this way you provide for an arbitrary number of kinds of metadata,
while the model actually has very little actual *meta*data. The only
metadata you need is the "Item" class(es) and the Variable class(es).
Item has a title string, a parent Item, a superclass Item (e.g. Topic,
Note), an Item to which it "pertains" (which will often be its parent),
subitems, optional Variables, and optional values (for its variables
and for inherited ones).
Variable is also an item (each has the same), but its subclasses define
sub-Variables, for example "max-length" for a string, etc.
I'm halfway following this, though it's confusing. How would you
propose to store all this?
The API should allow fetching all values (including inherited and
propagated) of an item which *pertain to* the aspect of interest. So
for example the GUI will fetch values of all variables of items which
pertain to the Presentation topic. The searcher will fetch values of
different variables, and the object manager will access and update
values pertaining to access and modification times and counts. You can
also store user information (values for an item, and subitems) into
multiple aspects in the same way. It creates some interesting search
algorithms, but is a very powerful way to separate different kinds of
data and metadata.
It does sound powerful, but I wonder 1) would it require a full-fledged
database? and 2) wouldn't it require an awful lot of disk access to
store things in a "scattered" format?
Thanks much,
Hal
