[davidoster]

As we grow old we get wiser!

So, in that sense I wanted to point out the use of the invisible field.

When we make for example a callback_before_insert (as the above example code states) we might need to exclude some fields from the add form but still want to pass some value to these fields that will be stored on the database.

 

The solution to this is actually quite simple.

We just use the fields function to state all of the fields that will take part on the insert process and this means also the fields that should not be showing up.

Then in order to "hide" the unwanted fields, hence the ones we want not to be displayed at the form and by hand pass them some value we mask them with the use of the field_type function with the use of the invisible type.

This gets quite handy and easy to use when we want for example to insert some extra data about the record that is saved on the database.

For example when we want to save the date/time of insertion, or if we need to know the user that inserted this record, or if we want to encrypt some sort of information like a password. The possibilites are just endless and the mecanism is there to help us out, straight out of the box!

[web-johnny]

I like this post. I will link it to the documentation :-)

 

Thanks for your time to write this down.

[edramirez]

I'd like to share my experience with the use of invisible fields. Based on the user requirements, the table should have the

following structure:

 

year - varchar(4), NN

refno - varchar(10), NN

date - date, NN

custcode - varchar(10), NN

with the primary key as year + refno

 

Many tutorials out there would suggest you to implement this in MySql this way:

 

id - integer AUTOINCREMENT

year - varchar(4), NN

refno - varchar(10), NN

date - date, NN

custcode - varchar(10), NN

with the primary key as id

 

However, this gets really messy since records are not entered according to the proper sequence in real life. So, getting a

correct tabular view with proper sorting (year + refno) won't work. Doing it that way would result in a longer performance

for certain kinds of reports. So, what would be the better way to do it?

 

Here's how the fields should be laid out to get better performance and to get an accurate sort-view:

 

id - varchar(14), NN

year - varchar(4), NN

refno - varchar(10), NN

date - date, NN

custcode - varchar(10), NN

with the primary key as id

 

The id field would be derived from the fields year + refno. To accomplish this, you need to incorporate invisible fields like so:

 

$crud->fields('id','year','refno','date','custcode');

$crud->field_type('id','invisible');

 

Then you need to incorporate a callback for add and edit operations:

 

$crud->callback_before_insert(array($this,'createkey'));

$crud->callback_before_update(array($this,'createkey'));

 

Your callback function should look like this:

 

public function createkey($post_array)

{

  $post_array['id'] = $post_array['year'] . $post_array['refno'];

  return $post_array;

}

 

By doing it this way, you could get rid of autoincrement fields for similar kinds of table structures and have primary keys that are in step with the way that the file should be properly sorted.

 

Isn't that great!

[davidoster]

Amazing post-example [member=edramirez]!!!

Thanks a lot for sharing!

It's extremely useful.

 

P.S. It just needs some caution on possible duplicates because of user error.

[seth]

hi guys i would like to seek your expertise on what is the code on how to calculate an average of two rows in the callback that will show on the list table. Thank you very much!