I am working on a module where it's looking like I'm going to need a way of creating an object representing an input format that properly holds the roles, filters, and the filters' settings... details here: #1064572: input formats.

It seems that exactly what you've got in your module, but the extra dependencies of exportables, ctools, and strongarm are rather a lot for what I need.

Would you consider splitting input formats module into two modules in the same project, so there is a base API module which provides code for getting fully loaded input formats from the database?
I'm envisaging it would be a function filter_api_filter_formats which would then have input_formats_get_settings, input_formats_get_roles, and input_formats_get_filters and the various helpers.

I'd be happy to do some of the work on a patch, as I'm going to be coding this either way :D

CommentFileSizeAuthor
#10 1083314.input_formats.api-module.patch9.56 KBjoachim

Comments

dagmar’s picture

dagmar
Primary language Spanish
Location Argentina
commented
Status: Active » Postponed (maintainer needs more info)

I don't have problems with that. However I think this requires a new branch, something like input_formats-6.x-2.x.

Would you like to take care about that branch?

joachim’s picture

joachim commented

Sorry for the delay in getting back to you...

Yup, a new branch is a good idea. I'm not sure I can take care of the whole of that branch myself as I don't know much about how the exportable side of things works, but I can certainly take care of the API module.

dagmar’s picture

dagmar
Primary language Spanish
Location Argentina
commented
Status: Postponed (maintainer needs more info) » Fixed

Ok, go ahead and create a 2.x branch.

joachim’s picture

joachim commented

You'll need to give me commit access if you want me to make the branch -- otherwise, I can post a patch when it's ready :)

dagmar’s picture

dagmar
Primary language Spanish
Location Argentina
commented

I gave you access last week.

joachim’s picture

joachim commented

You did? I tried making a branch and git complained. Also, wouldn't that mean I get listed on http://drupal.org/node/818826/committers ?

wojtha’s picture

wojtha commented

subscribing - interested in 2.x release, sounds promising....

joachim’s picture

joachim commented

Ok that worked this time :)

I've created two branches, 6.x-1.x for ongoing work and 6.x-2.x for the new stuff.

Probably will start looking at this next week.

joachim’s picture

joachim commented
Status: Fixed » Active

Reopening, as I'll use this issue for the actual creation of the module :P

joachim’s picture

joachim commented
Status: Active » Fixed
StatusFileSize
new 1083314.input_formats.api-module.patch9.56 KB

I've added the basics of an API module, but there's going to be more work needed I think.

I was trying to go backwards from the functions in the main module and encountering too many problems. So I worked the other way, and the result is something that loads all current input formats along with their filters and settings. It's going to need more work to be CTools compatible though, and so this patch doesn't make any changes to the main module.

One of the things I was trying to change was the way settings are stored in the format object as form API-style arrays with descriptions and values -- which doesn't seem necessary, and would make use of settings in something like #1286642: input format tools: reports and conversion have to jump through hoops. But I don't know how deep in the input_formats exporting system this goes.

Here's the patch I've committed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.