I can't go back

You know, an idea just struck me (I should recover in a few days ).

It would be not be too difficult to create a module with a form for generating the desired config file for the major snippets; the module would be tabbed, with forms for Wayfinder, Ditto, MaxiGallery with the ability to easily add more tabs for more parameter-prolific snippets as desired (sort of like the help module I did a little while ago).

Basically just have a field for each possible parameter, and the processor ignores the empty fields and generates a config file (file name would be the first field) and puts it in an appropriate folder. Then all you need to do is set the &config parameter in the snippet to point to wherever that file gets written.

Or set this up in the Config tab for each snippet, that would probably be even better. Basically what you get after you enter something in the config field, only it would already be laid out in the nice way you get once you’ve put in the &blah=BlahBlah;type;blah &etc stuff (which I can never remember how it goes). Of course this would mean that the snippet coder would have to make some kind of standardized listing of available parameters plus brief description for the script to parse. Perhaps a separate file that goes in the snippet’s assets/snippets/snippetname folder, that would reduce the footprint of the snippet code as well.

That would be amazing Susan !

On second thought, skip the part about setting this up as part of the snippet’s configuration. This needs to be customized on a per-use basis, not for the whole snippet. That’s why the parameter lists in the first place.

So a module where the file gets generated with the given name it would have to be.

The module would have to be configured to write to a specified folder, which would need to be created with appropriate write permissions. Perhaps a general assets/snippets/configs folder? Or would it be better for each snippet’s form to write to its own assets/snippets/snippetname/configs folder? It would need to be created and have the appropriate write permissions for each snippet in that case.

Why not just use the built-in parameter-sharing features of modules? Then you could set the configs in there and the snippet could automatically access them. People who write bigger snippets could package configuration modules with them (based on a default module).

The only minor complication that I can see to this method is that the module would need to store multiple configurations for snippets that are used in more than one location/context, but I think that would just be a matter of storing them as an array and selecting which config set you want in the snippet call (e.g., [[Ditto? &modConfigs=`basic`]]).

I have thought that a wizard type tool to help create snippet calls would be great, but not really realistic once you get into all the different possibilities. But the config idea is even better and not to difficult to implement since it is basically a form (although there are quite a bit of parameters to cover in snippets like ditto and wayfinder, so I think that this will take time to build).

I am thinking the low tech route (modules are beyond my ability to understand at the moment), have the config file output in a text field after filling out the form ’wizard’ and the user can then copy+paste into a file and put it where it should go. My issue with the module idea would be covering snippet updates, you could have an outdated module once you update a snippet or the other way around, have a new module and an old snippet and have the config not work. With a remote ’wizard’ you can make sure it is up-to-date.

Anyway, one more great idea from sottwell

Yes, of course, each snippet would display a list of existing available configs, but the main point here is to allow people to generate their own custom config files. You could even select one of the existing files, which would fill the form with its values, then change only the ones you want different, and give it another name to save your new config file.

It would work on the principle of a "default" language file, so the only thing that would need to be changed in the case of an upgrade would be the default file, which would be loaded for a "new" config. The displayed list of configs would come from a reading of the relevant folder, so that would present no problem with upgrades.

That’s a great idea and would be an awesome resource. Have you thought about it anymore Susan? Need any help?

Quote from: dev_cw at Feb 07, 2008, 07:33 AM

I have thought that a wizard type tool to help create snippet calls would be great, but not really realistic once you get into all the different possibilities. But the config idea is even better and not to difficult to implement since it is basically a form (although there are quite a bit of parameters to cover in snippets like ditto and wayfinder, so I think that this will take time to build).

I am thinking the low tech route (modules are beyond my ability to understand at the moment), have the config file output in a text field after filling out the form ’wizard’ and the user can then copy+paste into a file and put it where it should go. My issue with the module idea would be covering snippet updates, you could have an outdated module once you update a snippet or the other way around, have a new module and an old snippet and have the config not work. With a remote ’wizard’ you can make sure it is up-to-date.

Anyway, one more great idea from sottwell

Sounds like a great idea. Done the way you’re suggesting, it wouldn’t even have to be distributed. There could just be a page at modxcms.com (or somewhere) that did what you describe and the user could cut and paste from the output. That would also help with the update and compatibility issues.

Bob

Quote from: Sulman at Jan 27, 2008, 01:13 PM

I couldn’t agree more...

I just came back from Drupal... *shudder* . It’s a powerful CMS, it just drove me to tears :’(

I re-installed ModX and literally had my site with all my own design running in 1 hour and 30 minutes flat.

ModX truly closes the distance between "What I want" and "What I need to do to get there". That’s the best way I can describe it.

But I have to admit, I am very envious of the user base/community in Drupal and Joomla. That’s why I really want to get ModX out there so everyone knows how great of a CMS it is...so we also have a gazillion users crawling around the forums, creating things, helping people out and keeping the project alive. So we have more than two or three people trying to create a new version. This CMS can be GREAT...someone pretty high up in the Joomla forums even said: "The CMS itself needs refinement, but once it’s mature, it’ll be a great competitor for Joomla!, similar to what Drupal is right now." ...in response to a post I made about ModX...

We need to get ModX out there (tactfully) !!!

Sulman,

What were the problems you hit with Drupal? I ask because I have a large community/org that I am looking to use drupal with and wanted to know the problems you saw with it. Were you using it for basic sites, business, community?

Thanks,
Chuck

Hey Chuck,

My major problem with Drupal really stemmed from one thing: Templating.

There were also several other minor problems I had like inability to really understand the interface intuitively, but I’m sure that would have been smoothed over with time. Templating just gave me a headache from the start. If you can handle that and the steep learning curve, I think you’ll be fine.