We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 48391
    • 6 Posts
    Quote from: BobRay at Jul 25, 2014, 06:50 PM
    On Form Customization: yes and no. It doesn't create the rules automatically, but you can add a resolver to create them (or add the creation code to an existing resolver). It probably will do them automatically someday.
    as form customization is commonly used feature it would be great if you can add support for it someday smiley


    Quote from: BobRay at Jul 25, 2014, 06:50 PM

    Namespaces: The package itself can have only one Namespace (a limitation of Package Manager). It might work to specify others (below the package namespace) in the 'namespaces' member of the project config file. If not, you could create them in a resolver as above (or maybe better -- in a validator, so they'll be there before installation). I try not to modify the build.transport.php file unless absolutely necessary. You can *almost* always accomplish what you want in a resolver. Once you list a custom resolver in the project config file and create it, it won't be touched by MyComponent. Just be sure it has a unique name or is named for the package.
    i absolutelly agree with you that a component should create only one namespace but it is legal to have more than one registerNamespace() call in your build.transport.php and it will work (tested against modx 2.2.14). i mean that you can generate the build.transport.php like this:

    $namespaces = include 'transport.namespaces.php';
    foreach($namespaces as $namespace) {
        $modx->registerNamespace($namespace['name'], ..........);
    }

    otherwise it will be better to change config key from 'namespaces' to just 'namespace' because currently it is a little bit misleading.

    Quote from: BobRay at Jul 25, 2014, 06:50 PM

    RemoveObjects nukes all the objects in MODX. If you run Bootstrap after that, they'll be recreated as described in the config file, then exported in that form by ExportObjects. That's why you're losing the rank. If you specify the 'rank' field in the project config file where you describe the TVs, it should be preserved, but I'm not 100% positive about that.
    you mean that Bootstrap will just read the project config file and create all listed objects without referencing the corresponding transport.<OBJECT>.php file?


    Quote from: BobRay at Jul 25, 2014, 06:50 PM

    Bootstrap is designed to be non-destructive so that you can add objects to the project config file and install them in MODX with Bootstrap without affecting existing objects. Doing it the way you suggest would overwrite objects in MODX based on the config file (which, much of the time, will not contain all the information you need for those objects - e.g., properties and TV options). You'd risk losing valuable work.
    i think installing a component with the packager will not overwrite any existing object. i'm not completely sure about that so i should retest. i didn't encounter any issues with the package manager yet
      • 3749
      • 24,544 Posts
      you mean that Bootstrap will just read the project config file and create all listed objects without referencing the corresponding transport.<OBJECT>.php file?

      TBH, I don't remember. wink I think it will reference the files for elements that have code files and for resources (assuming that ExportObjects has been run), and I think properties will be imported for those items. TVs don't have code files, so they will be created based on the config file. MC should probably check for TV properties files (if it doesn't already), but it won't happen anytime soon. wink

      You're absolutely right about registerNamespace() (and I was wrong about it being a limitation of Package Manager). Looking at the MC code, it appears that all namespaces described in the project config file will be created in MODX on Bootstrap. I'm not sure if they will make it into the package, though. Let me know if you try it. If not, I think I will just create a new resolver or validator to install them all.

      About overwriting objects when a package is installed: They will be overwritten if you have UPDATE_OBJECT set to true in the attributes. If you have UPDATE_OBJECT set to false, they will not be overwritten, but the catch is that they also won't be uninstalled when you uninstall the package. I've made a feature request to separate the two actions and provide separate constants for them, but for now, they go together.

      Bear in mind that you almost always want to update/overwrite the objects in an upgrade. By default, MC sets UPDATE_OBJECT to true except for Contexts, Context Settings, and System Settings.

      One final word about the build.transport.php file. There are some minor limitations caused by having a universal build.transport.php file, but I have over three-dozen extras and it's a tremendous advantage to be able to use the exact same build.transport.php file for all of them and any future ones. It also greatly simplifies putting existing projects under MyComponent control.



        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
        • 48391
        • 6 Posts
        Quote from: BobRay at Jul 26, 2014, 05:40 PM
        You're absolutely right about registerNamespace() (and I was wrong about it being a limitation of Package Manager). Looking at the MC code, it appears that all namespaces described in the project config file will be created in MODX on Bootstrap. I'm not sure if they will make it into the package, though. Let me know if you try it. If not, I think I will just create a new resolver or validator to install them all.
        All namespaces will be created on Bootstrap, but they WON'T be created on package install.

        I found another limitation with MC. When a TV is created on Bootstrap, object properties like 'input_properties' and 'output_properties' are completely ignored. ExportObjects preserves these properties. Is there any particular reason for this?
          • 3749
          • 24,544 Posts
          All namespaces will be created on Bootstrap, but they WON'T be created on package install.

          Thanks for checking. I'll have to try to fix that.

          found another limitation with MC. When a TV is created on Bootstrap, object properties like 'input_properties' and 'output_properties' are completely ignored. ExportObjects preserves these properties. Is there any particular reason for this?

          The only reason is that they're very difficult to specify correctly in the config file (and it would be easy to create a corrupted TV when trying). It's much easier and safer to do them in the Manager. If they're in the object in MODX and you run ExportObjects, they'll always be in the package.
            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