Forums

Controller save(): knowing if you're coming from edit.php or add.php

Permalink
Howdy,

I have a custom block that properly saves data in its controller's save() method, but only when coming from add.php. It works when coming from there as I originally coded my save method to handle that/do SQL inserts. I need to be able to tell though whether the user is coming from adding or updating in order to run the proper SQL for those actions.

Is there a C5 method/way of checking for this?

Cheers
Landson
 
mkly replied on at Permalink Best Answer Reply
mkly
I'm curious about this as well. My current way of doing this is
function save($args) {
  if($args['update']) {
    // do update
  } else {
    // do add
  }
}

Add actually provides $args['_add'] but I usually just check for the update.
Landson replied on at Permalink Reply
Landson
Thanks mkly, that technique will work great! Perhaps I'll eventually come across an official way to do this, but for now that will more than suffice.
jordanlev replied on at Permalink Reply
jordanlev
I think this is the official way -- maybe it's not documented (this is the first I've heard of it), but if C5 is providing you with the "update" argument, then that's about as official as these things get :)
Shotster replied on at Permalink Reply
Shotster
Perhaps I don't fully understand your block design, but there should be no need to code custom SQL into your save method. C5 handles the DB interaction for you. The save() method of your block controller is passed an array of data to be saved. If necessary, those data can be modified before saving, but the save() method works for both adding and editing a block instance. You just have to make sure that the array of data is passed to the parent class of your block controller...

parent::save( $args );


-Steve
jordanlev replied on at Permalink Reply
jordanlev
C5 only handles DB interaction for the block's primary table. But many blocks have secondary tables as well. The most common example of this is the slideshow block, or any block that has an image gallery where users choose individual images instead of just a file set -- you have one table that's for the block itself and any block-wide settings (so there's one record for each placement of the block on the site), and then another table that stores the file id's and captions and display orders for each individual image that's displayed by one block (so there's a one-to-many relationship between the two).
Shotster replied on at Permalink Reply
Shotster
> C5 only handles DB interaction for the block's primary table.

Aha, thanks for that info, Jordan! I have noticed multiple tables in some blocks but have not yet developed a multi-table block myself. I guess I would have found out at some point, though, as I have an idea for a block that might require more advanced relations.

Interestingly, one block I developed does indeed store the ID's and display order of DB items, but my implementation did not require a separate DB table. Instead, I opted to keep it simple and "serialize" the ID's into a comma-delimited string and store that in a text column of the block's table. It works well but would obviously not be the right choice for a large or more complex data set.

Thanks again for pointing that out,

-Steve
Landson replied on at Permalink Reply
Landson
Thanks for looking out for me Shotster. I do indeed need to write custom SQL though, as like jordanlev's example I have a one-to-many relationship in my block.
Shotster replied on at Permalink Reply
Shotster
> I have a one-to-many relationship in my block.

Yeah sorry, I was suffering from tunnel vision.

:-/

-Steve