Re: [Adobe-source-devel] ASL and menus

[Ralph T. <ra...@gm...>]

On Apr 4, 2005 11:14 AM, Foster T. Brereton <fbr...@ad...> wrote:
> One thing to note in this pipeline is the "pushing" of information. The
> data is never "fetched" in the sense that a function has to reach
> outside its domain to get at information it needs. The application
> pushes the subject to the predicate; the predicate pushes the result
> back to the application; the app pushes UI updates to the client; the
> client pushes the selection of a command to the application; the app
> pushes the current subject to the selected function operation. The
> reason this is important is because we want our application system to
> model a directed acyclic graph (DAG). Adam and Eve are founded on the
> principle that application software, for the most part, is an attempt
> at describing a system as a DAG. Unfortunately current OOP techniques
> don't enforce this very well, and code can easily become hard to keep
> all in your head at once. By "DAGing" at the foundational level, we
> keep the system maintained in a way that it is easy to get our heads
> wrapped around a given component. You can see this in the ASL already,
> as the only "get" function in the entire codebase (I believe) is in
> value_t.
> 
> Thoughts?

I have some questions (more than thoughts ;-)). Perhaps if we answer
them then we'll have a better understanding of what we need to make.

 1. How should I think of data in the GUI?
 2. How do I push updates to data in the GUI?

As an example, think of a buddy list in an instant messaging program.
The list of buddies is known some time after the application starts,
and is always subject to change. In order to determine which menu
items should be available attributes of the currently selected buddy
need to be known to Adam. The buddy is a data model, and so is the
list of buddies (we can define a data model simply as something with
properties to bind).

You could write a single model as a special entry in an Eve file (like
a non-visible widget), and then bind it's properties to cells in the
Adam sheet. This isn't straightforward (to me!) for accessing data
model properties which are arrays of other data models.

I imagine that once there's a way of representing/reflecting data into
the GUI domain it will be easy to update it.

Thanks,
 Ralph