Snippet properties and package update

MODX Staff
12,272 Posts

Ryan Thrash Reply #11, 17 years, 9 months ago

What would be interesting ... really really really interesting ... is to have the ability to edit a bunch of settings in this grid and save it as a config. Default would always be default and uneditable. Change one thing and it’s no longer default and requires a named title to save it.

That way you could have different settings set via a grid, run more than one setting on a site, have your prized settings saved across upgrades and maybe even a handy way to exchange configurations via some sort of export mechanism.

[[spfForm? &cfg=`bobsBadAssConfig`]]

Ryan Thrash, MODX Co-Founder
Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me

4,213 Posts

doze Reply #12, 17 years, 9 months ago

Yes, that would be great! 1+

"He can have a lollipop any time he wants to. That's what it means to be a programmer."

MODX Staff
10,725 Posts

opengeek Reply #13, 17 years, 9 months ago

Alright, I still need help conceiving of and designing the UI elements for this, but revision 4515 now includes the ability to use named property sets when calling Elements as tags. The tag format for referring to these persistent named property sets is simple:

[[ElementName@PropertySet]]

You can still use filters and override properties directly:

[[ElementName@PropertySet:ucase? &property=`overrides value in PropertySet`]]

To verify that this new capability works, you can execute the following command line script (from the root of your Revo install) to create a TestChunk and some property sets:

<?php
require_once('_build/build.config.php');
require_once('core/model/modx/modx.class.php');
$modx= new modX();

$modx->initialize('mgr');

$testChunk = $modx->newObject('modChunk');
$testChunk->set('name', 'TestChunk');
$testChunk->set('description', 'A test chunk');
$testChunk->setContent('<pre>
[[+param1]]
[[+param2]]
[[+param3]]
</pre>');
$testChunk->setProperties(array(
  'param1' => 
  array (
    'name' => 'param1',
    'desc' => 'parameter 1',
    'type' => 'textfield',
    'options' => 
    array (
    ),
    'value' => 'This is default.param1',
  ),
));
$testChunk->save();

$set = $modx->newObject('modPropertySet');
$set->set('name', 'config1');
$set->set('description', 'Test property set 1');
$set->set('properties', array(
    'param1' => 'This is config1.param1!',
    'param2' => 'This is config1.param2!'
));
$set->save();

$testChunk->addPropertySet($set);

$set = $modx->newObject('modPropertySet');
$set->set('name', 'config2');
$set->set('description', 'Test property set 1');
$set->set('properties', array(
    'param2' => 'This is config2.param2!',
    'param3' => 'This is config2.param3!'
));
$set->save();

$testChunk->addPropertySet($set);

Then, create a document and place calls to the chunk to test the new feature...

[[$TestChunk@config1]]
[[$TestChunk@config2]]
[[$TestChunk@config2? &param3=`This is overridden config2.param3`]]

Now we can attach custom property sets to elements (even share named property sets with multiple elements of different types) and call them easily with tags or even directly with code and not worry about the default property sets getting overwritten on upgrades.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

24,544 Posts

BobRay Reply #14, 17 years, 9 months ago

Custom property sets are a *very* cool feature and I can see a lot of uses for them. I’m still trying to get my head around how it would work for the less tech-savvy user and how the user will modify those properties.

For snippets, will there be a Custom Properties tab next to the current Properties tab with it’s own grid? Will I (as a developer) be duplicating properties so they’ll appear on both the default and the custom tab? Will users be moving or duplicating properties from one tab to the other when they want to modify them? If there are tabs and they have different properties, how will the user know where to look for a property? If properties are duplicated on both tabs, will users modify the wrong one and wonder why it got overwritten later? What if a developer needs to rename a property?

I don’t mean to be difficult, but I still don’t see the down side to my original idea of letting developers preserve the current settings in the properties grid on update other than that it’s not how we’re used to thinking about default properties. It think it could be done with a validator-type resolver that would just serialize the properties and save them for restoration later in the build. That would still give the developer the option to add or overwrite specific properties in a PHP resolver later. It also gives the developer complete control over what happens to individual properties during an update, which might come in handy (e.g. for bug fixes and renaming properties).

It gives developers more flexibility, which IMO is a good thing, its use would be optional and, as I mentioned earlier, properties that you don’t want users to mess with casually could be left out of the grid and set in the element’s code. This would let everyone work the way they want, which is why I came to MODx in the first place.

I’m probably missing something obvious and important, but I’ve thought really hard about this and can’t see what it is.

Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting

577 Posts

Carsten Reply #15, 17 years, 9 months ago

One problem I see is when the developer adds in a new configuration parameter or conversely deprecates a parameter.

1.) Why not just make it simple and have the default available as plain text next to the input field?
2.) Have the ability to return to default (reset/clear). Either in a all or singular fashion.

I, personally, always worry about what happens if I F’up the config and worry about how to get back to the original default without having to re-do to the whole set of config values.

If I understand Jason’s idea correctly, it looks like you can have multiple configuration settings. Now that is cool. Is this page, user, or for a lack of a better word "theme" based?

Tangent-Warrior

MODX Staff
10,725 Posts

opengeek Reply #16, 17 years, 9 months ago

Quote from: BobRay at Dec 05, 2008, 12:05 AM

Custom property sets are a *very* cool feature and I can see a lot of uses for them. I’m still trying to get my head around how it would work for the less tech-savvy user and how the user will modify those properties.

I think the answer lies in a visual MODx Content Tag editor. Available to content-related text areas or even as a plugin to the rich-text editors, this could simplify life for everyone. We could have type-ahead support for available Elements that even know the default properties for placing inline, and the same would go for PropertySets; they could be selected by name and even provide access to view the property values in the set.

Of course, it’s just data, so how we present it in a manager theme is ultimately up to that theme.

Quote from: BobRay at Dec 05, 2008, 12:05 AM

For snippets, will there be a Custom Properties tab next to the current Properties tab with it’s own grid? Will I (as a developer) be duplicating properties so they’ll appear on both the default and the custom tab? Will users be moving or duplicating properties from one tab to the other when they want to modify them? If there are tabs and they have different properties, how will the user know where to look for a property? If properties are duplicated on both tabs, will users modify the wrong one and wonder why it got overwritten later? What if a developer needs to rename a property?

Having a standalone PropertySet editor (grid of PropertySets that opens up a Set editor), as well as access to it from a tab in each Element, or integrated into the default properties tab somehow is how I envisioned it.

PropertySets can exist in and of themselves. They are made available or accessible to an Element via a link table, so a single PropertySet can be related to multiple Elements, even of different classes (i.e. modChunk, modTemplateVar, modSnippet, modPlugin, etc.). Users would want to be able to create a new PropertySet from an Element’s Default Properties and modify it from there, or simply select from existing PropertySets and be able to view/edit the set, duplicate it, etc.

Quote from: BobRay at Dec 05, 2008, 12:05 AM

I don’t mean to be difficult, but I still don’t see the down side to my original idea of letting developers preserve the current settings in the properties grid on update other than that it’s not how we’re used to thinking about default properties. It think it could be done with a validator-type resolver that would just serialize the properties and save them for restoration later in the build...

That technique (using a validator to capture existing default property values to merge into the object) would still be useful for managing default properties on upgrade in ways specific to a component, I just know that the more common scenario will be users with 15 configurations of a reusable element that could easily be managed as PropertySets and remain undisturbed regardless of default property changes. Two different problems really, but the solution makes it less urgent for default property preservation in most cases, make upgrades smoother, and will help reinforce the idea that editing default properties of an element can be useful to both developers AND to all site managers to make site-wide default changes to all instances of an element.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

MODX Staff
10,725 Posts

opengeek Reply #17, 17 years, 9 months ago

Quote from: Carsten at Dec 10, 2008, 07:18 PM

One problem I see is when the developer adds in a new configuration parameter or conversely deprecates a parameter.

Exactly, it should be updated with the rest of the element, that way new properties are automatically available to the element via the defaults, without affecting the property sets. And property sets that have deprecated properties, well, those will simply be ignored.

Quote from: Carsten at Dec 10, 2008, 07:18 PM

1.) Why not just make it simple and have the default available as plain text next to the input field?
2.) Have the ability to return to default (reset/clear). Either in a all or singular fashion.

I, personally, always worry about what happens if I F’up the config and worry about how to get back to the original default without having to re-do to the whole set of config values.

Good point and suggestions Carsten. That should definitely be part of the Property Set editor interface.

Quote from: Carsten at Dec 10, 2008, 07:18 PM

If I understand Jason’s idea correctly, it looks like you can have multiple configuration settings. Now that is cool. Is this page, user, or for a lack of a better word "theme" based?

It’s not page, user or theme-based; it’s simply sets of reusable properties identified by unique names. A shortcut to typing/copy-and-pasting a whole set of properties in a tag with the added ability to share them with multiple Elements.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

24,544 Posts

BobRay Reply #18, 17 years, 9 months ago

I’m beginning to like the idea, based on some assumptions I’m getting from your description.

- User’s can easily create (and name) a full property set by duplicating the defaults.
- There’s a grid to edit them, just like the current grid.
- Maybe the defaults are still visible when editing the custom properties.
- Maybe there’s a "reset" button next to each one and a "reset all" button.
- Snippets then get called with something like [[snippet_name? &properties =`users_name_for_the_set`]]
- The values of any properties in that named set automatically replace the default values in the property array that arrives at the snippet.

Is this how you’re seeing it? I think it would be several orders of magnitude easier and more robust than trying to put that functionality into an editor.

Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting

MODX Staff
12,272 Posts

Ryan Thrash Reply #19, 17 years, 9 months ago

I think your assumptions are right Bob. And later we can take it one step further by making a handy little property set import/export button. It could generate or load an XML (or other format) config file that can be used to share settings more easily without having to go through the trials of building a full blown package.

Ryan Thrash, MODX Co-Founder
Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me

MODX Staff
10,725 Posts

opengeek Reply #20, 17 years, 9 months ago

Quote from: BobRay at Dec 11, 2008, 01:02 AM

- Snippets then get called with something like [[snippet_name? &properties =`users_name_for_the_set`]]

The proposed format is...

[[snippet_name@users_name_for_the_set? &this_overrides_property_in_set=`foo`]]

...and again, this works for all Elements, not just snippets.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek