Snippet properties and package update

I’ve been thinking about new versus update package installs and had a disturbing thought about snippet properties.

If the properties are set in the main build script and the user modifies them, updating that snippet will overwrite the user’s changes. To avoid this, the properties can be set in a script resolver, which is aware of whether an update or new install is going on.

The disturbing thought I had was: What happens to existing snippet properties in an update install of a new version of the snippet? If they’re wiped out and the PHP resolver doesn’t set them (because it’s an update), the snippet ends up with no properties at all after the update.

My strong preference would be that they’re preserved on update unless deliberately overwritten in a PHP resolver. That way the user’s changes are protected, but the snippet developer can still have complete control of the end result via the PHP resolver.

I can’t test what happens now since you can only update packages that come from the WTF, so I thought I’d ask.

Bump ...

I’ve confirmed that a re-install wipes out the user’s snippet property changes (which I’m hoping there’s a way to avoid). Still wondering about what would happen with an update.

Quote from: BobRay at Dec 01, 2008, 06:31 PM

Bump ...

I’ve confirmed that a re-install wipes out the user’s snippet property changes (which I’m hoping there’s a way to avoid). Still wondering about what would happen with an update.

These are default properties, so on reinstall/update (which is the same thing except update downloads a new version first), the default properties would be updated. Default properties for an element are for, well, the default. So if those default properties are changed, you would want to manually update the snippet I guess, and you would have to manually fix any changes to default properties. I do not see a way to resolve this conflict, and to be honest, the default properties should be just that, defaults defined by the author, that should be overridden by explicit calls to the snippet.

Quote from: OpenGeek at Dec 02, 2008, 09:11 AM

These are default properties, so on reinstall/update (which is the same thing except update downloads a new version first), the default properties would be updated. Default properties for an element are for, well, the default. So if those default properties are changed, you would want to manually update the snippet I guess, and you would have to manually fix any changes to default properties. I do not see a way to resolve this conflict, and to be honest, the default properties should be just that, defaults defined by the author, that should be overridden by explicit calls to the snippet.

I was afraid you’d say that.

I had hoped that the point of creating the new properties grid was to give users an alternative way of setting properties (and, with the properties grid there, users *will* set them that way even if we tell them not to). If they could be set safely in the grid, they would be "default" properties for that site, rather than for all users everywhere, and users could change them from site-to-site.

I’m still hoping that we can create an option for developers that want to use the grid this way (say, adding a PRESERVE_PROPERTIES attribute, or something similar).

As a user myself, I’d also like to be able to set (and check) the properties in the grid for some snippets, especially ones like SPForm which has over 75 settings that might often change in response to spamming attempts.

Maintaining the property values in the grid between upgrades sure sounds like a reasonable request to me.

Quote from: rthrash at Dec 02, 2008, 04:13 PM

Maintaining the property values in the grid between upgrades sure sounds like a reasonable request to me.

Then you would need to prevent the snippet object from being updated and script the update using a resolver somehow, as updating specific fields of an object is not possible using a basic Vehicle at this time.

But I still disagree, the default properties in the grid are just that, defaults and when I get a new version of a component, I want the new defaults that show me what the default properties of the element will be when no properties are passed to it via tag properties or via another script.

I really feel like we are blurring the lines between what is the realm of an Element producer and what is that of the Element consumer. As a developer, I want to be able to mess with and manage the default properties of an Element. But I don’t necessarily ever want an Element consumer (i.e. someone who simply uses the Element in a content tag to make use of it) to have to even go into the Element editor. What we are wanting is something like the RTE for inserting MODx tags and selecting element-specific properties based on the the defaults the producer provides.

I see where Bob’s coming from though. He wants the defaults to be the initial defaults in what he’s perceiving as something that users are going to change. And inevitably an upgrade will wipe out their settings so we should probably chat about this some more. I smell lots of support requests on the horizon!

Quote from: rthrash at Dec 02, 2008, 09:50 PM

I see where Bob’s coming from though. He wants the defaults to be the initial defaults in what he’s perceiving as something that users are going to change. And inevitably an upgrade will wipe out their settings so we should probably chat about this some more. I smell lots of support requests on the horizon!

I personally agree with Jason, and think that "default" properties are default by provider state and not by user.

If there are settings that the user is going to change, why not make them System Settings? Those are more appropriate for user-adjustable settings.

Quote from: splittingred at Dec 02, 2008, 11:00 PM

Quote from: rthrash at Dec 02, 2008, 09:50 PM

I see where Bob’s coming from though. He wants the defaults to be the initial defaults in what he’s perceiving as something that users are going to change. And inevitably an upgrade will wipe out their settings so we should probably chat about this some more. I smell lots of support requests on the horizon!

I personally agree with Jason, and think that "default" properties are default by provider state and not by user.

If there are settings that the user is going to change, why not make them System Settings? Those are more appropriate for user-adjustable settings.

I imagined that they could be "default" properties for a particular site. I’ve got over 70 properties for SPForm and many of them might be changed often as users decide to turn spam-proofing options like hidden field, timer, require mouse or keyboard, captcha, etc. on and off and different clients the developer serves would certainly want different options (especially about which violations result in a user warning). The five SMTP properties might need to be set on one site but not another. I’d hate to saddle a site with that many additional system settings or to make the user type in a preposterously long snippet call that might eat up a lot of time and be frustrating to debug.

If there are "default" options that we don’t want the user to mess with casually, they can be left out of the grid and set the old-fashioned way with the ternary operator in the snippet.

It’s so much easier to change properties in the grid than to edit multiple snippet calls, not to mention the potential for typos, single quotes, missing quotes, forgotten ampersands, and RTE mischief. And, let’s face it, some users *will* change them in the grid, update, and then ask us why all their carefully considered settings were trashed. I hate to be saying to end users: We have this great new, very convenient grid for editing snippet properties -- don’t use it.

It seems like it would be possible during a package install to have an option to check for current properties, save them, merge in any new ones, and then set them.