How do you handle Module_Product_Update?

[Mike521w]

Hi all,

my shipping module is finished and working correctly, but I found a bug today.

I have a tab for some misc settings on the product edit screen. If you edit a product and make a random change (not related to my module), my module's `Module_Product_Update` runs, and accidentally blanks out the entries in the DB for that item.

I was thinking about checking to see if my module's tab is the active tab, but I suppose a user could make some changes to my shipping settings, then tab over to something else and make some changes, and then click update from there (expecting that all their changes from every tab will be saved).

I could also check to see if the data for my module is blank, and then do nothing. But what if the user really does want to blank out the existing data..

Anyway, I'm sure there's a best practice for handling this that I'm missing? I checked the LSK but nothing there was helpful for this situation

[Scot - ScotsScripts.com]

Run the update routine regardless of tab so it doesn't blank out your entries, or as you say, check to see if you are in your tab.

In my modules I usually check to see if I'm in my own tab since I would not expect someone to move to a new tab without saving, but it really just depends on your module design.

[Gordon - Phosphor Media]

Two things:

1. g.Tab will contain the current tab. Use it to make sure you are in your own lane.
2. If you add-on to a common screen, do not post the entire dataset every time you want to update. Learn to update ONLY your own data. It will probably mean rolling your own functions.

[Kent Multer]

If you look at some examples from the LSK, you'll see that the standard way to handle this is by having your Module_Product_Content function check the l.tab value. If the tab is for your module, it displays the text boxes, menus, etc. for your settings. If the tab is for some other module, your module puts all its settings values into hidden fields with the same names as the inputs.

This allows a user to click through several tabs, and make changes on all of them, but only click the Update button once when they finish making changes. It's a convenience to the user, and it makes the tabs function in the usual way: make changes to several tabs, and just click one button to save them all. It's also helpful in cases where the settings on one tab are related to something on another tab, since all the values will be available when Module_Product_Validate is called.

However, there is a quicker way to write the code for cases where you don't need the more advanced functionality. In this case, your code only uses l.tab to decide whether or not to display its settings. If l.tab has some other value, your module doesn't display anything, and it doesn't generate hidden fields. This requires the user to always click Update after making changes, before they click to some other tab. I think there's some built-in Javascript you can include on your page, so that users will be warned if they make changes and then try to click to another page before they hit Update.

If you use this shortcut approach, there's one other change you need to make. The code block that normally looks like this:

<MvIF EXPR="{ l.load_fields }">
... code to read your settings from the DB ...
</MvIF>

will need to be changed to:

<MvIF EXPR="{ NOT g.Data_Entry_Error }">
... code to read your settings from the DB ...
</MvIF>

This ensures that, when a user arrives at your module's page, the module will always load its settings values, unless they are already loaded and the user made an error that was caught by your Module_Product_Validate function.

Hope that's clear enough to be helpful?! --

[Mike521w]

thanks all! I ended up going with Kent's suggestion of adding hidden fields on `Module_Product_Content` if the user is on a different tab. I hadn't noticed that type of setup in the LSK before

Scot - ScotsScripts.com I agree that I wouldn't expect the user to make changes on multiple tabs and click update just once.. I usually click update on each tab I'm on. But.. people will do whatever they want, so I figure I'll try to make it work both ways

Kent Multer so I ended up making all of my changes in the `Module_Product_Content` function. Basically I'm storing my data in javascript variables attached to the parent window, and updating both the hidden fields (if not on my tab) and visible fields (if on my tab) from those js variables. If the user is on my tab and changes the fields, the js variables are also updated, so as soon as they click away, the hidden fields are shown again by Miva and updated by js. Just wondering if you do something similar? In any case, it's working now, no values are being lost

[Kent Multer]

Hi Mike, glad you got that working.

I've never used Javascript in the way you described. I always use one of the two approaches outlined in my previous post. I generally try to avoid using Javascript in my work. The Miva pages use a lot of JS, much of it undocumented. The source code is spread through multiple files with un-helpful names like scripts.js and helpers.js; and most of the admin code is not included in the LSK. So it seems like custom JS is more likely to conflict with the built-in code, or get broken when a new version of the store is installed; and it also tends to be hard to debug. Maybe it's me; I'm fine using JS for basic things, but I haven't really studied the more advanced features and techniques that have been added in recent years.

[Mike521w]

Got it, thanks again Kent! Yea I'm not usually a fan of adding js in this way, it feels clunky. I used unique variable names to avoid conflicts with Miva or other modules etc. Anyway it's working, so all good for now