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

[Richard Gaskin]

That's helpful, but still a lot to digest (maybe it's just my pre-coffee 
state of mind).

So it's a library, or set of libraries?

To get a feel for how it works, are there similarities/differences with 
Apple's Core Data?
<http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/index.html>

Got a 30-word-or-less summary of what it does for developers?

It would be helpful to see it in action -- do you have links to 
applications shipping with it, perhaps with descriptions of how it 
helped the development process?

TIA -

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com


MisterX wrote:
> 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