Jump to:
| Project: | ecard |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Hi there,
A couple of suggestion on which I want your opinion. We basically need to extends the features of the ecard module to suit our needs and I want to know it this approach could get some community interrest and thus should be engineered as a patch on 7.x-1.x-dev version or if it's a no-go for the module maintainers. If so I'll end up on forking the project.
What I miss the most is the ability to have more than the basic field in the ecard submission form.
A good idea might be :
1. Make ecard fieldable : this is basically tweaking the entity_info ;
2. Make ecard have different bundles : same as above ;
3. Provide an admin UI through entity API to manage bundle ;
4. Make the existing fields that are not mandatory (name_from, name_to, text, ...) standard fields attached to the appropriate ecard bundle (text would become a regular 'body').
Amongst that, I think that ecards should have a regular integer entity/revision identifier to better integrate with the Entity API. The hash should be a field with a unique constraint if we think unicity is mandatory.
Comments
#1
Hi
first: You are always very welcome to enhance the module! So just provide patches as you like :D
In this case my thoughts are if the E-Card module will get bloated and the use case will be more complicated?
How would we select the bundle of the E-Card Entity that is used for the form?
This could be a select-box in the E-Card field type.
How will we build programmatically the E-Card creation form?
For the current module we did decide to create a simple form by hand as we know all input that can happen there. If we make the entity fieldable we would need to use an common core stuff which seems bloatet to me. Need some more input here please.
Keep it simple
Anything else seems like an optional addition and should be fine. Just keep in mind that there should be a relative clear use case of this module and we should make as much as possible work out of the box.
#2
Absolutely.
Well, all we need is to add
field_attach_form,field_attach_form_validate&field_attach_form_submitto existing hooks.I do recognize that the setup of the module in its current form is pretty straightforward and should remain so. I think if the whole stuff is "fieldized" and "bundlized" the module will have to provide a default bundle with default fields present to mimic the current behavior.
I think I will try to make all those changes in a add-on module but I'll certainly need some adjustement in the core module. Maybe extendability/override hooks in various places will help.
I keep you posted.
#3
No need for an add on. Currently it seems easier to me to keep this in the main module as it doesn't seem to change a lot. My idea was to create a features module feature for a default configuration. So we could add the field stuff easily there as well.
#4
I second the 'Feature' option as a way to provide default configuration.
We're in the process of integrating ecard in a project right now. I'm getting back to you when I've a chance to tidy those things up and share code.
Meanwhile, you can checkout another piece of code we sandboxed recently : a ecard resource provider for Service 3.x API.
http://drupal.org/sandbox/garphy/1372416