1.7 Changes
1.7 Changes
Hello Allan,
Now that 1.7 is out and you've had a minute to breathe, I wanted to ask about how the new changes might be used.
For our system, we define each column with aoColumns for each table. We actually use a database to define our tables, then have the code automatically generated. Would there be any reason to change how we define the table based on 1.7 changes - other than new table options like scroll x/y etc?
Thanks,
Patrick
Now that 1.7 is out and you've had a minute to breathe, I wanted to ask about how the new changes might be used.
For our system, we define each column with aoColumns for each table. We actually use a database to define our tables, then have the code automatically generated. Would there be any reason to change how we define the table based on 1.7 changes - other than new table options like scroll x/y etc?
Thanks,
Patrick
This discussion has been closed.
Replies
aoColumnDefs offer a lot more flexibility than aoColumns - for example you could have definitions based on the class name of the column ("center", or "accounts_data" etc) which could then be applied to any table, rather than needing to specifically match the columns with aoColumns. Having said that, if aoColumns is working fine for you - don't change it unless you are fining it limiting. Support for aoColumns is not going to go anywhere - it can still be very useful. It's just that aoColumnDefs provides everything aoColumns does, with additional flexibility.
Regards,
Allan