K
kenhenry123
i'm doing my due diligiance here to make sure I'm not re-inventing the
wheel
I'm looking for a really dynamic gridview control that I can use for
updating database tables. I already have a library that I've use in
ASP projects that I could move to .net but I am looking to see if
asp.net has this capabiltiy built in.
Basically I create a table in my database that contains columns for my
entity name and create,read,update,delete commands. The fields for
create,read,update, delete contain sql or stored procedure
statements. the read field has the select statement using joins if
necessary, or just refers to a view. the create,update,delete fields
contain the field names wrapped in a deliminator that the user control
can insert the values in during runtime. One more useful feature is
if a '*' char is put in the create,update,delete fields, the command
are done with updateable recordsets.
other template files (conditional asp include files) provide
opportunity to specifiy combo boxes or other controls as edit
templates when a grid row is being edited. Similar to asp.net 2.0
gridview, an id column can be used in a template to allow editing the
row on a hard programmed forms-view page if necssary.
Just so you know how the internal logic works, when a recordset is
retieved with the read command, a copy of the data is stored in xml
and saved in the user session. The create,updates,deletes are stored
as datagrams in the xml. (the changes to the recordset are stored as
nodes off the original row node with the new field values). A general
purpose function commits the changes to the database with the
information in the entity-crud table.
One really usefull thing about this system is it allows for very rapid
prototyping. During the first stages of a project, I only put '*'
values in the entity-crud table which causes the rows to be updated
with updateable recordsets. In this case the underlying tables can
can be radically changed without breaking the code. (the cell edit
templates won't break either, they are just ignored or a debug message
written to screen if the field they are attached to disappears) When
the application is closer to being finished and performance is more
important then explicit sql and stored procs can be put in the table.
The other nice thing about the design is it shuts up anal database
admins who want all the application specific logic in the database.
wheel
I'm looking for a really dynamic gridview control that I can use for
updating database tables. I already have a library that I've use in
ASP projects that I could move to .net but I am looking to see if
asp.net has this capabiltiy built in.
Basically I create a table in my database that contains columns for my
entity name and create,read,update,delete commands. The fields for
create,read,update, delete contain sql or stored procedure
statements. the read field has the select statement using joins if
necessary, or just refers to a view. the create,update,delete fields
contain the field names wrapped in a deliminator that the user control
can insert the values in during runtime. One more useful feature is
if a '*' char is put in the create,update,delete fields, the command
are done with updateable recordsets.
other template files (conditional asp include files) provide
opportunity to specifiy combo boxes or other controls as edit
templates when a grid row is being edited. Similar to asp.net 2.0
gridview, an id column can be used in a template to allow editing the
row on a hard programmed forms-view page if necssary.
Just so you know how the internal logic works, when a recordset is
retieved with the read command, a copy of the data is stored in xml
and saved in the user session. The create,updates,deletes are stored
as datagrams in the xml. (the changes to the recordset are stored as
nodes off the original row node with the new field values). A general
purpose function commits the changes to the database with the
information in the entity-crud table.
One really usefull thing about this system is it allows for very rapid
prototyping. During the first stages of a project, I only put '*'
values in the entity-crud table which causes the rows to be updated
with updateable recordsets. In this case the underlying tables can
can be radically changed without breaking the code. (the cell edit
templates won't break either, they are just ignored or a debug message
written to screen if the field they are attached to disappears) When
the application is closer to being finished and performance is more
important then explicit sql and stored procs can be put in the table.
The other nice thing about the design is it shuts up anal database
admins who want all the application specific logic in the database.