Jump to:
| Project: | packgr |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
i am loving this installation profile and feel like it's opening up the possibilities of d6's new installation process. i've also been enjoying the improvements to the forms api, especially the built in ajax support. i'm going to be looking into the possibilities of using some of the new ajax fanciness to make my packgr packages interact better with each other, and would be happy to get some input from other knowledgeable folks.
the way this profile seems to work is that on installation you can select one or more packages to include in the process. Each of these packages may have one or more of its own configuration forms, which shows up as a new step in the setup. even though there's a basic separation of task type ('settings', 'configure', 'enable'), they seem to have little functional difference.
what i would like to be able to do is, for each of my packages, combine similar or common tasks into a single step. so, for example, i might have a blog package, an seo package, and an ecommerce package. for each of these, i may want to fine tune which specific modules are on/off, so i'd like a single 'modules' task that combines the specific modules selection from all enabled packages. each package will likely have it's own content types as well, so similarly i'd like one step that is content type customizations... etc etc.
i believe this will involve something like the following:
tasks with forms associated to them will need to get a basic, ajax-ready form definition from the packgr profile itself. That form definition will call out to any installed packages with that same task name enabled, and add / remove fields from the form accordingly. this way we can avoid having 10+ step installations while still making them as customizable as possible.
thoughts / suggestions?
Comments
#1
ok this was actually a lot simpler than i was making it out to be, and doesn't need any ajax fanciness to work just fine. i have set up my default profile (which will always be used) to have its own hooks... calling out for customizable modules using packgr_load_callback('modules'); ... so now in any other package i create, i include a package_NAME_modules function that lists the modules i would like the user to have control over. those are all combined onto a single form by my default package, which then sets variables and ultimately install the modules.
so a single module form for all packages is working! i plan to keep using this model so that i can have a dozen+ packages included in my install but only add two or three tasks / forms to the process.