Add hooks for 3rd-party extensions #271
Comments
|
Issue #169 talks about this, too. |
|
It helps me to consider some use cases when I'm thinking about something as abstract as this. Do you have any in mind? I'm thinking along the lines of features where RA needs to provide a useful default but people might reasonably want to override that with one of several different options. A few I can think of offhand are authn, authz, history/auditing, ORM support, templates/skins/css. Are these the sort of things that you're thinking of? |
|
Yes, your examples are all good candidates for 3rd-party extensions. Another example I would give is the CKEditor patch. When this issue is resolve, the next step should be to take some of the existing code that has been merged into master and factor it into 3rd-party extensions to serve as examples of how to build extensions. |
|
I've created an extensions label for issues which I think are good candidates for extensions instead of core features. |
|
I'm copying over @slawosz comments #169 so I can close that issue. Going forward, this will be the canonical issue for our extensions API.
|
|
An official gem prefix would be a good idea. We'd name our gems like To find gems we would just run |
|
@gunn: I agree. I like the |
|
Another case, from another issue, seems to be uploaders (Paperclip/CarrierWave et al). |
|
Any ETA on this? Some extensions I've been thinking about:
|
ghost
assigned 
|
I'd be open to supporting an effort to standardize extensions across frameworks. We've already made pretty good progress in Spree. In particular, I think the concept of a |
|
What's the added value over classic Gemfile versioning? Spree extensions aren't classic gems? |
|
The advantage is that you peg certain "versions" of an extension to specific versions of the framework. For instance the same 1.0 version of an extension might work with Spree 0.60.x, 0.70.x, and edge (but not say version 0.30.x) We also wanted a way to convey edge versions of extensions (stuff on the master branch) and indicate likely compatibility with edge versions of Spree. (and yes, spree extensions are classic gems.) |
|
Added the field extensions generator, the action generator (with custom actions), and a theme generator. |
The exisiting structure used an Object as a cache where the keys are the
values of option elements, and values are the HTML content of the option
elements. In Javascript, if a numeric value in the form of a string is
assigned as a key, it gets converted to an integer. Optimization
routines would then order the object to ensure faster access to
elements. For example:
cache = {}
cache['2'] = "two"
cache['1'] = "one"
console.log(cache[2]) #=> "two"
console.log(cache[1]) #=> "one"
console.log(cache) #=> {1: "one", 2: "two"}
Note the coercion of strings to ints above. This messes with the
ordering of multiselect options list whenever there is a user input. To
avoid this from happening, the keys need to have a string that can't be
coerced automatically, and then preserve the value of the option
element.
I chose to use an object that stores the option value and the option
HTML as the value of the cache and a string of the format 'o_<option
value>' as the key. This ensures that the insertion order is preserved.
This is the new structure:
cache = {
'o_271': { id: 271, value: 'CartItem railsadminteam#271'},
'o_270': { id: 270, value: 'CartItem railsadminteam#270}'
}
The existing structure used an Object as a cache where the keys are the
values of option elements, and values are the HTML content of the option
elements. In Javascript, if a numeric value in the form of a string is
assigned as a key, it gets converted to an integer. Optimization
routines would then order the object to ensure faster access to
elements. For example:
cache = {}
cache['2'] = "two"
cache['1'] = "one"
console.log(cache[2]) #=> "two"
console.log(cache[1]) #=> "one"
console.log(cache) #=> {1: "one", 2: "two"}
Note the coercion of strings to ints above. This messes with the
ordering of multiselect options list whenever there is a user input. To
avoid this from happening, the keys need to have a string that can't be
coerced automatically, and then preserve the value of the option
element.
I chose to use an object that stores the option value and the option
HTML as the value of the cache and a string of the format 'o_<option
value>' as the key. This ensures that the insertion order is preserved.
This is the new structure:
cache = {
'o_271': { id: 271, value: 'CartItem railsadminteam#271'},
'o_270': { id: 270, value: 'CartItem railsadminteam#270}'
}
Everyone has a slightly different idea of what RailsAdmin should do. As a result, people have been submitting patches to extend RailsAdmin functionality. So far, the majority of these patches have been merged.
In general, I'm overjoyed with the number of people who want to contribute to this project. I don't want to discourage contributions in any way. At the same time, merging in every patch will eventually turn RailsAdmin in bloatware.
I believe the best solution to balance these interests is to create APIs that will allow developers to easily extend RailsAdmin. It may even be possible to do this with Railties.
Here are some goals:
I'm interested in getting feedback from those of you who have been submitting patches. Does this sound good? How could it be better?
The text was updated successfully, but these errors were encountered: