Refactor to allow different message processing
| Project: | Mailhandler |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Hi,
I need to allow users to create nodes via email. However, since will be used by users at large, I need to greatly simplify the syntax of the message bodies. In fact, I'd like to have my own grammar !
Currently, you have some really good code for creating nodes, including validation & default values and I don't want to shortcircuit that. I think it would be possible to decouple how the email message is parsed and how the node gets created and I could then plug in my own message parsing.
I'd be willing to do this "right", with a clean patch to apply to the D6 branch so I could benefit from further developments of mailhandler and its modules. However, before I go down the long road, I'd like to make sure that the maintainer is ok with this idea and supports it.
Thanks
#1
Sure. Do you have an example of such gramer/syntax, so we can understand your aims better?
Also, this sounds to me as something that can lead to fields support in mailhandler, and that's something which has a great demand for.
#2
@z.stolar : messages I want to parse will be very simple. Here is the mapping
Email subject => title and body
1st line => a taxonomy element from a specific vocabulary
attached file => the node's CCK imagefield element
That's it ! It's hardly even a grammar but really, it could be with the way I see it.
Here is my idea : split mailhandler_process_message in two. Then, give or take a few lines:
=> lines 226 to 230 stay where they are
=> lines 231 to 260 + 266 to 332 get put in a separate "default" module which gets called with a mailhandler processing hook
=> lines 262 to 264 get moved up above the previous lines
That way I can plug a different message parser using a custom module.
#3
@PGiro: it's hard to refer to line numbers. Try using function names, or actual code lines. A patch, even only a demonstrative one, is even easier to read.
Now: taxonomy is already supported, and there a module to deal with attachments: http://drupal.org/project/mailsave.
#4
z.stolar : yes, I know those modules and taxonomy is supported but I will never get my users to send messages that complicated. I want subject = body and contents = taxonomy on which I will be using the leveinshtein distance to compute the closest matches when none does.
I just wanted to make sure you'de be willing to deal with ironing out a patch to include in the project. Given our exchanges, I'll operate under the assumption that you are :)