Alex,
Any insight on using this?
I want to create an object, based on the Table object, such that "File" represents an uploaded/uploading file, or an in-process edited/editing file. Everything seems built on the GT:Base, so understanding and potentially using that seems to make sense.
Table is a good object to use as a guide, since it will fundamentally be a database record with a few extra flag fields, and the methods to operate on them. It's a subset of the Table object, really, that operates on a database record, not a table, but has to grab the table 'def' to start out.
It should ideally load the '.def' file for the table it's using, and add them to the "control fields" that are created when the object is initialized. For instance, an in-progress upload object would need to know where it's temporary files are -- temp_dir, temp_file, etc, while the database object only needs to know the final resting place.
The reason for this, is because a file lives as a real-world object on a disk, it has attributes that can be changed, and by creating a software object that represents it, properties such as name, location, or even existence can be much more easily, and properly modeled.
PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Plugins:http://LinkSQL.com/plugin
Any insight on using this?
I want to create an object, based on the Table object, such that "File" represents an uploaded/uploading file, or an in-process edited/editing file. Everything seems built on the GT:Base, so understanding and potentially using that seems to make sense.
Table is a good object to use as a guide, since it will fundamentally be a database record with a few extra flag fields, and the methods to operate on them. It's a subset of the Table object, really, that operates on a database record, not a table, but has to grab the table 'def' to start out.
It should ideally load the '.def' file for the table it's using, and add them to the "control fields" that are created when the object is initialized. For instance, an in-progress upload object would need to know where it's temporary files are -- temp_dir, temp_file, etc, while the database object only needs to know the final resting place.
The reason for this, is because a file lives as a real-world object on a disk, it has attributes that can be changed, and by creating a software object that represents it, properties such as name, location, or even existence can be much more easily, and properly modeled.
PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Plugins:http://LinkSQL.com/plugin
GT::Base clase ?