naked objects from stored procedures, interface generation
Hallo,
there exist many framework that 'backward' engineer from a programming
language to database to make the data persistent.
so: code >> db (generated)
eg. hibernate, turbogears many others
My question is, from db point of view, do we have such frameworks that
work the other way,
ie that forward engineer from a database to a user interface (web or
program),
maybe using the stored procedures available on the database (eg in the
same naked objects work)
so: exisiting db (possible + stored procedures) >> user interface (eg
crud or other)
mvg,
Wim
Hello
I know about one similar project - Garuda, but this project isn't open.
What it does:
* OOP - objects, properties, methods - not based on PostgreSQL OOP
* support of workflow - lifecycle for objects
* support of collection of objects
It was designed in plpgsql with special modules to PHP, where was
possible to work with Garuda objects like PHP objects.
Regards
Pavel Stehule
2010/12/23 Wim Bertels <wim.bertels@khleuven.be>:
Show quoted text
Hallo,
there exist many framework that 'backward' engineer from a programming
language to database to make the data persistent.
so: code >> db (generated)
eg. hibernate, turbogears many othersMy question is, from db point of view, do we have such frameworks that work
the other way,
ie that forward engineer from a database to a user interface (web or
program),
maybe using the stored procedures available on the database (eg in the same
naked objects work)
so: exisiting db (possible + stored procedures) >> user interface (eg crud
or other)mvg,
Wim--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 12/23/10 12:19 AM, Wim Bertels wrote:
My question is, from db point of view, do we have such frameworks that
work the other way,
ie that forward engineer from a database to a user interface (web or
program),
maybe using the stored procedures available on the database (eg in the
same naked objects work)
so: exisiting db (possible + stored procedures) >> user interface (eg
crud or other)
one database can serve many applications.
the database provides the persistent storage for the 'model' part of a
classic M-V-C system, and it can provide some to much of the 'model'
business logic, but its really not suitable for either the view or the
controller, those are better expressed in other domains