We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 28471
    • 48 Posts
    Hi core coders,

    How are you guys/gals going with the resource installer (ie to install templates, snippets, chunks etc), Reason Im asking, is I was starting to work on a template installer module, which may not be neccassary if the resource installer is on its way.

    Also, is there a specific way to develop or package snippets, modules, chunks etc so they can be easily installed with the upcoming resource installer. As I have a few ideas about how these could be implemented if anyone is interested.

      • 32241
      • 1,495 Posts
      Sure thing, post up your ideas.

      If you have something that you already work on, feel free to post it in here, it might be helpful for our core team to use some of your code maybe for the future resources intaller.

      Lets start the discussion!
        Wendy Novianto
        [font=Verdana]PT DJAMOER Technology Media
        [font=Verdana]Xituz Media
        • 28471
        • 48 Posts
        Ok, just a rough scratch up of how snippets could be setup for instance.

        Each snippet could be packaged as a zip, (or txt if simple snippet) with a separate info file describing the snippet
        * version
        * author + email address
        * category
        * snippet homepage - for support and update info
        ...

        Now the resource manager(or whatever its called) could connect to a central resource server to list templates/snippets/modules etc (server could be defined in manager, allowing different access to different installations), and than modx would download the package, uncompress it into a dir, read the info file, insert the snippet data into database, add templates to a chunk and so forth. Snippets could also be updated in this method, like a 1 click or auto update.

        Also snippet packages could be uploaded similar to other systems.

        Each snippet could also have override files for installation, update, and uninstallation. In case the snippet needs to generate its own tables, directories, or do something unusual.

        The separate info file would contain all the info on how to use the snippet, define parameters default values and how to use them, and the core snippet code would be reduced to just code. Other snippets, modules, and templates will be able to read this info and somehow use it, the info will only be accessed when needed.

        I’ve just uploaded a quick overview of how it might be structured in the .zip.


        Templates:
        ------------
        As there is usually several templates on a site based on a similar type, ie one site template, and several templates based on the site template, but with different layouts. Each template package could contain different revisions of templates, or template styles.

        for example:

        templates/
           atemplate/
                 atemplate.tpl.html
                 atemplate_2col.tpl.html
                 atemplate_3col.tpl.html
                 atemplate_4col.tpl.html
        


        So you could have the main template installed, and the installer will list the other templates based on that template (could be defined in template info file) like so:
        With descriptions for each templatefile.

        example:
        $templatefiles[0]['name'] ='atemplate.tpl.htm';
        $templatefiles[0]['desc']  = 'Description for this file'];
        $templatefiles[1]['name'] ='atemplate_2col.tpl.htm';
        $templatefiles[1]['desc']  ='description for this revision';
        


        Again templates would contain a template info file or similar to define the template data, and possible override files again to install template variables, chunks and the like.
        * Author, Version, homepage, ....

        Or, something along these lines...so that modules, snippets, templates etc have some common way to be installed,updated and removed easily.

        More to come...
          • 32241
          • 1,495 Posts
          I would propose to have them generalize.

          So lets take an example of this folder layout.
          sample_resources.zip
            |- info.modx - Copyright , descriptionsm terms, and agreement maybe to be displayed on resouce installer
            |- install.modx - it can be xml or plain txt file for instruction in installing/upgrading provided resources
            |- templates/
              |- sample_template_name/
                |- resources/
                  |- template1.tpl.modx - automatically copied to template resources on MODx database
                  |- template2.tpl.modx - same as above
                |- langs/
                  |- en.lang.php
                  |- fr.lang.php
                |- styles/
                |- images/
            |- snippets/
              |- sample_snippet_name/
                |- resources/
                  |- snippet1.snippet.modx - automatically copied to snippet resources on MODx database
                |- db/
                  |- mysql.sql.modx
                |- langs/
                  |- en.lang.php
                  |- fr.lang.php
                |- snippet.class.inc.php
            |- plugins/ - Same like snippets structure above
            |- libs/ - Same like snippets structure above
            |- modules/ - Same like snippets structure above
          


          What do you guys think?
          I would also propose to have the installer review the files that are going to be modified, created, overwrite and etc, as well database that need to be made and populated, before the user install it.
            Wendy Novianto
            [font=Verdana]PT DJAMOER Technology Media
            [font=Verdana]Xituz Media
            • 28471
            • 48 Posts
            Yes, this is great, to have a standard layout structure, with the information on the resource loaded before any installation is performed.
            • Wendy, Stempy,

              Great ideas! I really like the direction this is taking. I just wondered if you’d considered using XML to define the directory structures and resource information.

              That way, you could define a common data schema that could be used across all the snippets/modules/plugins etc. - and keep the code for what it is, code smiley if that makes sense ...

              Cheers, Garry
                Garry Nutting
                Senior Developer
                MODX, LLC

                Email: [email protected]
                Twitter: @garryn
                Web: modx.com
              • Quote from: garryn at Mar 05, 2006, 03:40 AM

                I just wondered if you’d considered using XML to define the directory structures and resource information.

                A few formats to consider in addition to XML, are the more human readable and writable formats which are becoming popular in the more advanced dev frameworks, as well as the AJAX community, such as YAML or JSON, respectively. I particularly like JSON, as it makes AJAX development a piece of cake, is very lightweight, and with one more letter it would spell JASON grin
                • I think you should change your name.
                    Ryan Thrash, MODX Co-Founder
                    Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
                    • 34162
                    • 1 Posts
                    I want to offer a few thoughts on installer.

                    Mambo is using a zip file and a xml file that contain a list of all file to be installed. It works great but with a few problems:
                    . When install it is install as "nobody" and it cause lot of headache
                    . For developer it is a night mare to package lot of files to list in the xml file and it is a pain.

                    I propose when design this installer use a form of ftp so that it will be install as the user login not as "nobody" and list the folder rather then each individual file so it will be easier for developer to package his/her addon.

                    Just my 2 cents.

                    PS: The YAML and JSON both sound good! The only thing is it seems to be a new syntax to like rather than XML which is people getting over the hurdle on it, may be! And if the help of XSL you can make it look something more readable or with some XML editor’s help.

                    Thanks
                      • 28471
                      • 48 Posts
                      Quote from: chanh at Mar 06, 2006, 08:53 PM

                      I propose when design this installer use a form of ftp so that it will be install as the user login not as "nobody" and list the folder rather then each individual file so it will be easier for developer to package his/her addon.

                      Agreed with the xml, listing every file in the config is a pain, and I think unneccassary if its structured right.

                      Also, if the primary use of the config is for the installation/modification of the resources, than xml would be ideal, as its already widely used and understood, while JSON has good benefits for AJAX, I am unaware of what benefits it would provide for the resource packages?