Spokes - Plugins on Steroids

[liferealized]

I'd like to start chatting about a new features in wheels, namely self contained application logic that can be shared between developers with a single distribution. All logic in these self contained applications could be overridden if need be, including controller, model and views. It would be similar in scope to Engines in Rails. http://guides.rubyonrails.org/engines.html

Each spoke would have a folder structure similar to wheels and would include:

- config
- controllers
- events
- models
- tests
- views

An update to event processes would be necessary to load spokes at an appropriate time to allow for the framework to load spoke specific settings before the application settings. An update would also be necessary for all controller, model and view paths to be one OR many items that would need to be looked through to find the appropriate logic to run.

Spokes, similar to plugins, would have a cfc to apply functionality to the core application.

There have been discussions on the group about functionality like this and I wanted to take the liberty of trying to name the feature and start a more in depth conversation about the possibilities and the scope of work necessary to complete such an undertaking.

• Add struct for spokes that are added to the app
• All application events need to be able to run events in each spoke, running spoke events first then application events
• modelPath, viewPath need to be lists and looped over
• need a configurable path for where spokes go
• need to be able to load spokes before settings
• since spokes are loaded before settings, we'll be able to run through each spoke to include their settings then include app settings to override if necessary
• routes need to be able to be loaded from each spoke then load application routes
• when loading controllers/models/views, we look in normal locations first, then spoke locations
• core object is needed to load spokes and update application settings
• need to decide how developers should install spokes (.zip like plugins or git submodule)

[perdjurner]

Sounds amazing :)

Is there a way to integrate it into plugins somehow instead?
Is it really necessary to treat is a new feature I mean?

There's probably a lot of overlapping needs between spokes and plugins anyway so it might make sense if they're all the same thing?

[liferealized]

Rails specifically keeps the two strategies separate although you are correct that they do share similar functionality. I'd want to have them separate, but that is just my opinion.

[neokoenig]

I've played with this idea. Not being able serve views/js/img/ out of the plugins folder was really limiting. The Multimodule plugin was the closest in terms of functionality I found. I (almost) starting writing a modular CMS with that idea.

The concept was to have a "module loader" which was the required core, and then be able to select modules, a la Drupal: as they all lived in the /modules/ folder, then if you matched the path in say, /views/modulename/foo.cfm that would then override the version in /modules/modulename/views/foo.cfm; Would the multimodule plugin be a starting point for this?

[perdjurner]

I'd want to have them separate, but that is just my opinion.

Because it's easier to code the feature that way, or some other reason as well?

[liferealized]

I'd want to keep the backward compatibility of plugins so that we don't possibly lose plugins already developed.

[perdjurner]

Ok, makes sense.

[liferealized]

@neokoenig there could be an install() that moves specific assets to the correct folders. Or, the install would simply make folder link references.

[neokoenig]

What happens when you install 4 'spokes' each with their (slightly) different version of jQuery (for instance)? Also, loading order - it might be your app needs to load before another one to satisfy dependencies.

[liferealized]

Good questions. I'd like to start getting a list of them and work through each one before hand.

[chrisdpeters]

I think that the public assets makes this trickier for sure. Would an implementation of spokes without that element get us 80% of the way into usefulness without all of the pain?

RE: loading order, this is where box.json would come in handy. Want to determine the loading order? Specify it in box.json.

[liferealized]

@chrisdpeters that is certainly a possibility although I'm sure developers would be adding specific markup for styling / layout.

[liferealized]

haha, it would certainly make the job easier!

[liferealized]

I've updated the OP with a checklist of things that need to be done. I like chris' idea of just doing mvc logic and not fancy assets.

[perdjurner]

Closing this as we're using the issue tracker for bugs only from now on.
Please implement your feature suggestion as a plugin or make a pull request.
If you need feedback before starting, please consult the Google Group.

Thanks.