I'm building a "cheezefield" module right now myself. Perhaps this is pure Frankenstein, or maybe it's good:
I have a complex content type managing a variable number of files, with variable attributes and properties for each file. Also this content type has references to other nodes of the same type. To implement, I created a fieldset holding all of these possible fields, and generated 10 of them in a loop. For the UI, they appear as needed via jquery, and js validation makes only the fields appear that correspond with a given file type. The module's DB presence is my one table for the additional content type, and for each of the datatypes in the fieldset I have a big varchar field holding a serialized keyed array of values entered by the user. It's really simple to just assign my data arrays to the node, at insert/update serialize them and at load unserialize to recover my keyed arrays. I'm 75% of the way done with with after a day, expecting to wrap up today. Considering that serialize/unserialize can't be less performant than ooodles of DB calls, this looks like a winner to me... Sincerely, -Blake [email protected] www.BlakeSenftner.com www.Droplabs.net www.MissingUbercartManual.com On Oct 20, 2011, at 1:29 AM, Simon Hobbs wrote: > Coolio. Like I say, it might already exist, I'm going to have a closer > look at the properties module myself. I had a situation where I was > mapping Netsuite entities to content types and the fields tables were > getting out of hand, IMO. I had content types with dozens of fields > and to display the full content type with a view could feasibly break > the 61 join limit of MySQL 5.x. You might never get there, but if you > do you can bet it's late in the build and you will be crying into your > free beer. > > .s > > On 20 October 2011 17:53, Mukesh Agarwal <[email protected]> wrote: >> @Michael: thank you for the clear explanation. I'll sure try the module. >> @Simon: In the current scenario of my application, I might end up building >> the "cheesefields" module (wonder whether you add cheese to name your >> modules :P) and then contributing it to the community. >> On Thu, Oct 20, 2011 at 12:07 PM, Simon Hobbs <[email protected]> wrote: >>> >>> Hey Mukesh >>> >>> There is really nothing wrong with the approach in core, and making it >>> generic. It fits a wide variety of use-cases. >>> >>> But, sure, maybe we don't always want it that way. That's why Drupal >>> is awesome. Entity API and other hooks. >>> >>> I'm waiting/looking for a module (call it "cheesefields"): >>> 1. Your DBA makes a pretty table. >>> 2. You expose the info (via hook_schema) to drupal >>> 3. You implement hook_cheesefields_info() and to say which field is >>> the key and which entity type it maps to. >>> 4. cheesefields then implements the entity api hooks based on our >>> tables fields and their data types. We get widgets and everything, >>> with the ability to do an alter on the autodetected widgets and >>> specify alternative widgets. >>> >>> To put it a different way, all your fields in one table is not >>> different to a field module that defines multiple fields. We just need >>> to expose it correctly. >>> >>> Simon >>> >>> PS. If you know of this cheesefields module please tell me. >>> >>> >>> >>> >>> On 20 October 2011 17:11, Mukesh Agarwal <[email protected]> >>> wrote: >>>> Thank you Ernst for the advice. >>>> I think we could have achieved different revisions for each field by >>>> marking >>>> a field in UI as something that requires revision which would mean only >>>> those fields that require a different revision can do that. Same goes >>>> for >>>> translation. I think the entire field entities API is nice and makes >>>> programmers life easier. But in trying to make things generic, we have >>>> added >>>> a lot of overhead on Drupal core - content management system. >>>> Using MongoDb is a good option. I like the idea but since the support >>>> system >>>> for the same is not that strong, I'm sure clients will have a concern. >>>> I'm not sure if I want to chuck Drupal as a solution to our problem. >>>> Will >>>> have to find different ways. >>>> Not convinced with the separate fields idea though. >>>> >> >> >> >> -- >> Cheers, >> Mukesh Agarwal >> ________________________________ >> Innoraft Solutions || +91 8017220799 >>
