Rev vs. AJAX... Ajax vs TAOO [|Not so Short]

MisterX b.xavier at internet.lu
Fri Oct 14 13:22:14 EDT 2005


Dan,

you're clear that im complex and frustrated. and you're right!
sorry for being so revolutionary... but im not really...

most people grow up with legos, I discovered Fisher Tecknics
and didn't even try the other sets because FT's did it all
before Legos did more than just houses...

In HyperCard I built Duplos, then legos than FTs...

TAOO is an art of manipulating objects...
And it's not about navigation alone.

And this I don't make clearer for the reader as you point out!

consider user + computer

computer = applications + data

user = need + information

now, we need a reactive system, RunTime Revolution!

computer can help user get to data, edit it and send or store it away for
future benefits...

In this system we have all the rev "objects", stacks, cards, fields, lines,
columns, etc...

We all have needs for these... business or informational or for
administration of thousands of things... 

we don't have columns in rev but we abstract them with items...

so here's where it's different...

TAOO is the same, I or you can abstract a list of "objects" as "groups".

Forget the group keyword in rev for the moment

So a storage or list or catalog or book or index of objects is easily
represented by a group.

It's easy to see that you can manage a group of objects regardless of their
type.

Any object can be manipulated in its own way in a wide varieted of ways
whether in single or grouped form. This is a matter of grouping the
varieties

Rule of TAOO: if you create a function of one object, create equally the one
that does many...

But these ways of using objects are not intuitive in GUIs. 

hence someone along the line make the "explorer type of interface". 

Once which adapts to anything...

They (the guis) are a universe of groups of objects. These groups are
objects in groups too... you see the space now I see...

Now each object (or group) has a verb. Or rather the user needs to do this
to this object(s)... like delete contact or create contact. contact could be
a company or a car in the inventory.

Our object is a company, a product or a client... The groups are evident.
(in rev, these could be database records or cards in a stack with the
appropriate fields or custom prop arrays or text files, xml, etc...). 

What you don't see is that the underlying GUI, the running scripts use
"contact" (to name one object) as a keyword... It's not hard to make a
contacts stack and gui... true...

but now your business is trading... you need suppliers and buyer contacts to
be differentiated... 

To taoo this is the same "gui"... copy paste... done... no programming
involved... Is that OOP reuse or what? Navigation GUI goes without saying...

So the key and what I battle against today is the pletoria of information
storage types... Doing one by one is necessary but how to do you make one
GUI work with all without changing the GUI each time you update your DB API
or storage source?

That's where TAOO gets interesting because of it's hierarchy of events...

OS->IDE->TAOO->application

or TAOO->Master->[Manager->][Agent->][Group->]Object->property->Value

Navigation GUIS in this high-level dimention and it's control structure is
paramount actually - working in enterprise systems is quite different than
working in single stack releases... 

If you work on medium to long term or repetitive projects you can only
appreciate this* once you hit again another similar data structure to manage
in your application. It doesn't matter if it is record management or
GUI-text-style based controls for a gui. They should always do their best
across the environment. 

And with TAOO you can distribute these GUIs as objects and also improve them
all with only one, I repeat, one handler or change.

Distribution of application resources is easy to implement as we all know.
So automatism in a centralized system is only that much easier...

I don't know what else to say. im off the subject already probably...

After 8 years of economy, programming since 1982, im not shy of saying I put
the best of the best I learned or experienced since then into it... if it is
not clear to you or many others, I must be doing something wrong... but if I
really enjoy it's benefits since 15 years, how can I be so wrong? 

cheers
Xavier








More information about the use-livecode mailing list