$assigrow problem

[Geir Fjærli]

Haven't seen any docs about this, but here is my understanding:

The built in table class was always there and would be used in the instance
if you defined a list directly from a schema class. However, since you then
didn't have a physical table class in your application you could not
override or add methods, you were stuck with the built in ones.

Lists in version before version 4 had to be explicitly defined in code by
using $definefromsqlclass, from either a schema, query or table class.

In the new version this has changed, in that it is possible to name a schema
or table class as a subtype for a list directly in the variable definition.

Now a list might be used for other purposes than updating a database. It
might not even have anything to do with an actual database table. You would
still want to define it from a schema, simply because it is easier than
doing $adds in code. This is much the same as when people would create
memory only file formats in the old days, but it allows you stay with in the
modern paradigm of schemas and lists.

With such a list having a table class instanciated each time would just be
overhead, and so I guess they have added the option to say "I don't need
one".

Just my thoughts.

Geir :)

-----Original Message-----
From: omnisdev-en-bounces at lists.omnis-dev.com
[mailto:omnisdev-en-bounces at lists.omnis-dev.com] On Behalf Of Jean Marc
Azerad
Sent: 24. april 2009 09:22
To: OmnisDev List - English
Subject: Re: $assigrow problem


Le 23 avr. 09 à 23:49, Bastiaan Olij a écrit :

>
> Hi Jean Mark,
>
>> To me, the build in table class works with any version of Studio (not
>> sure for 1.0, I've never used it)
> The build in one was always there but you always had to create a table
> class and set $sqlclassname to the schema you wanted to use. What is  
> new
> in Studio 4.x is that there is a tick box on the schema class that  
> lets
> you define a list directly from the schema class without creating a
> table class first. Before that version of Studio,if you used a schema
> class you would get a list defined by the schema class but with no
> database methods (so no $insert, $update, etc.)

Sorry to insist, but yes, you could...
As a matter of fact, I'm still puzzled by this check box.
My understanding is that, in previous versions, the invisible default  
table class was there, available for rows (lists) defined from Schema  
and that, since 4.X, it is optional...
Not gone any further...

Best

JM