Question on Delagate class [SOLVED]

[jhenry]

I have a table used to store a maintenance checklist for certain types of equipment. When I add a record for a workorder I want to grab the associated checklist for the specific equipment and I assume this is done with the beforeInsert method. When I call this in the delegate class file can I make it dynamically create a grid to edit this associated record. Thanks.

Jason

[shannah]

What do you mean by automatically create a grid to edit the associated record? Do you mean that after inserting the record you want to redirect the user to edit the associated record rather than return him back to the edit form (default behavior)? Or something else?

-Steve

[jhenry]

Sorry i kind of ran around in circles on that one. I can statically create a grid to edit the associated checklist for each work order. The problem is each model equipment may have a different checklist. I am creating a seperate table for each model equipment and will be keyed with the workorder_id. So when I select new record it will search for the appropriate checklist and add it to the form to edit. I guess my question is can I use an if/then statement in the delegate class that defines a grid for a record instead of the fields.ini?

[shannah]

I'm still not sure I fully understand what you are trying to accomplish. Why is it that you are choosing to create a new table for each model? Why not just store them in one table?

By "grid" are you referring to the grid widget? or something else?

Are you meaning the on the new record form, you want to dynamically change the contents of one field that uses the grid widget depending on the selection of workorder_id?

[jhenry]

Sorry I am not being clear each workorder needs to have a checklist that list what activities we're completed on the workorder. The checklist is specific to the model of equipment the workorder is for. Because the checklists are specific to each model it can't be part of the workorder but needs to be a seperate table. If I create a grid entry in the fields.ini for the workorder table it will atach 1 model checklist that may not be the correct one for that model. So when I create a new workorder I select the specific equipment it is for and then have the system allow me to edit the correct checklist for that model in the workorder. I hope that helps.

TIA
Jason

[shannah]

What does your table structure look like as it pertains to this feature?

[jhenry]

Tables:
Work_Orders
workorder_id Primary Key
control_number Foreign key to Equipment.control_number

Equipment
control_number Primary Key
makemodel_id Foreign key to MakeModel.mm_id

MakeModel
mm_id Primary Key
mm_code //Description of Model

checklist_general //This is added to all workorders and contains items checked regardless of model
list_id Primary Key
workorder_id Foreign Key to Work_Orders.workorder_id

checklist_defib //This checklist will only be used if the equipment selected in the workorder is a defib model
list_id //Primary Key
workorder_id //Foreign Key to Work_Orders.workorder_id
mm_id //Foreign Key to MakeModel.mm_id
verify_output
verify_paddles

checklist_ivpump //This checklist will only be used if the equipment in the workorder is an infusion pump
list_id //Primary Key
workorder_id //Foreign Key to Work_Orders.workorder_id
mm_id //Foreign Key to MakeModel.mm_id
verify_flow
verify_occlusion



I added a grid entry to the fields.ini of the Work_Order table to be able to edit the entry for the checklist_general:
[Checklist_grid]
transient=1
relationship=checklist_general
widget:type=grid
widget:columns="electrical_safety,resistance,leakage,physical_condition,powercord_condition"
widget:label = "Checklist"
tab = checklist

As stated this will show up on all workorders regardless of model. What I need to be able to do is when I select the link to add a new workorder and enter the equipment control_number the correct checklist for that model will be added as a grid in the workorder record. So for instance I add a workorder for a defib it will pull the checklist_defib into the workorder as a grid like the checklist_general above. But if I add a workorder on an infusion pump model it will add a checklist_ivpump. I hope that makes it a little more clear.

TIA
Jason

[shannah]

So is it the case the each work order would only be related to one checklist record of each type? i.e how many records in the checklist_ivpump table can have the same workorder_id?

[jhenry]

You are correct there will only be one model specific checklist per workorder.

TIA,

Jason

[shannah]

Since the workorder to checklist relationship is 1 to 1 (for each type of checklist) it doesn't fit the mold of a typical relationship (they are generally 1 to n).

There are a few ways to work with this type of setup. Some that come to mind are:

1. Create separate relationships for each type of checklist. Use the action:condition directives in each's relationships.ini file to hide/show them appropriately depending on which relationship should be active at any given time. You could still use the grid widget for editing each of these relationships (and use javascript to hide show the appropriate fields when options are changed on the workorder form). The only thing is that the grid widget is kind of expecting to be able to have multiple rows and in this case that wouldn't happen - so I'm not sure what the outcome would be.

2. Use the __join__ feature (scarcely documented at this time) of Xataface and specify each checklist as a join table of the workorder table. You would do this by adding a section to the workorders fields.ini file:

Code: Select all

[__join__]
checklist_general="General Checklist"
checklist_deflib="DefLib Checklist"
... etc..


This would create subtabs in your edit form for "General Checklist" and "Deflib Checklist" with separate forms that edit those records. For this to work, however, it assumes that the primary key of the "join" tables correspond to the primary key of the source table. So your primary key for the checklist tables would have to be workorder_id. (I must ask, if a checklist is going to be unique on workorder_id, why not just use the workorder_id as the primary key and do away with the list_id?)

This solution wouldn't correspond with using the grid widget though.

3. Create transient fields on the workorder form, and use the afterSave() or beforeSave() methods to update the appropriate checklist table depending on the values of these transient fields. You'd also have to worry about setting the default values of these fields.

4. Use custom blocks/slots to add your own custom fields on the edit form for workorder, and use the beforeSave() trigger to update the database with input from your custom fields.

5. Don't have the tables related directly at all.. just add links in logical places of the interface to link to the appropriate checklist form.

[jhenry]

I think the link idea may be the easiest to implement. I haven't used a 1 to 1 relationship before. Using the workorder id would be fine. Is there a way to set up a link from the workorder form that grabs the current workorder id and opens the appriate checklist with that id? That would actually be best as some workorders
don't require a checklist so you would only have to select the link if necessary. I wouldn't even need the relationship as when repoting I could just query and grab all the records with id's that were equal.

TIA,

Jason

[shannah]

A couple of pointers:

1. You can always obtain the current record using:

Code: Select all

$record = Dataface_Application::getInstance()->getRecord();


Always check if the record is null (it will be if no records are found in the current request) before using it.
e.g.

Code: Select all

if ( $record ){
    // do some stuff with the record.
}


2. You can always get a list of the available slots and blocks that can be overridden by adding the following to the beginning of your conf.ini file:

Code: Select all

debug=1


An alternative approach would be to use actions to create your link. In this case, you might just add something like this to your actions.ini file (and create the actions.ini file if it doesn't exist already).

Code: Select all

[general_checklist]
    url="{$site_href}?-table=general_checklist&workorder_id={$record->val('workorder_id')}"
    url_condition="$query['-table'] == 'workorders' and $record"
    condition="$query['-table'] == 'workorders' and $record"
    category=record_actions
    icon="http://example.com/path/to/myicon.gif"
    label="General Checklist"


This will add a link, button, or tab to the appropriate part of your application. The url directive specifies where the link goes. The url_condition directive is necessary to tell Xataface when it is OK to attempt to execute the url directive (in this case we need to make sure that $record is not null because the url directive calls a method on it).
The condition directive specifies when the action is visible in the interface. In this case we say that it is only visible in the workorders table.
The icon directive specifies what icon to use.
The category directive specifies where in the interface the action should show up. In this case we specify record_actions which will place the action along with things like "Export XML" etc.. Some common categories you can use include: table_actions, table_tabs, find_actions, result_list_actions, record_actions, related_list_actions, selected_result_actions, summary_actions, and a few more.

[jhenry]

That looks like it should work. Can I use an sql statement in the actions.ini to grab the appropriate checklist to link to? I think what I will need to do is set up a table that justs references makemodel and checklist pairs so that I can query that and assign the appropriate table to a variable then use the variable for the table designation in the url.

Jason

[shannah]

Can I use an sql statement in the actions.ini to grab the appropriate checklist to link to?

What I would do is create a calculated field on the workorders table that generates the link to the correct checklist record. Then use that field in your url.

e.g.

Code: Select all

function field__checklist_url($record){
    // do some stuff to find out where the checklist is and return the url.
}


Then in your action:

Code: Select all

url="{$record->val('checklist_url')}"


[jhenry]

I really did not like the way it was set up in the actions.ini and I could not get it to take the url field but I think I have another solution that seems like it would be more applicable for what I need.

I created a table that stores the equipment type and a link to the checklist:

Code: Select all

CREATE TABLE IF NOT EXISTS `equipment_type` (
  `type_id` int(11) NOT NULL auto_increment,
  `description` varchar(50) NOT NULL,
  `checklist` varchar(50) default NULL,
  `checklist_url` varchar(100) default NULL,
  PRIMARY KEY  (`type_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=9 ;


INSERT INTO `equipment_type` (`type_id`, `description`, `checklist`, `checklist_url`) VALUES
(1, 'Infusion Pump', NULL, NULL),
(2, 'Defibrillator', 'checklist_defib', '{$site_href}?-action=new&-table=checklist_defib'),
(3, 'EKG Machine', NULL, NULL),
(4, 'Patient Bed', NULL, NULL),
(5, 'Bipap', NULL, NULL),
(6, 'Patient Lift', NULL, NULL),
(7, 'Nurse Call System', NULL, NULL),
(8, 'Ceiling Mounted Equipment Arm', NULL, NULL);


I added the checklist and checklist_url field to the __sql__ directive in the fields.ini of the Work_Orders table. So they can be used in a $record->val('checklist');
call. Then I put the following in the fields.ini to create a link on the label of the checklist field:

Code: Select all

[checklist]
  transient = 1
  tab = checklist
  label_link = "$record->val('checklist_url')"
  visibility:list = hidden


The label does turn into a link but it tries to go to "http://192.168.0.11/infinity/$record->val('checklist_url')" instead of the actual url.

Is there a different syntax to pull in the $record call in the "label_link" call in the fields.ini?