@Michael: thank you for the clear explanation. I'll sure try the module. <div><br></div><div>@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. </div>
<div><br><div class="gmail_quote">On Thu, Oct 20, 2011 at 12:07 PM, Simon Hobbs <span dir="ltr"><<a href="mailto:simon@hobbs.id.au">simon@hobbs.id.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hey Mukesh<br>
<br>
There is really nothing wrong with the approach in core, and making it<br>
generic. It fits a wide variety of use-cases.<br>
<br>
But, sure, maybe we don't always want it that way. That's why Drupal<br>
is awesome. Entity API and other hooks.<br>
<br>
I'm waiting/looking for a module (call it "cheesefields"):<br>
1. Your DBA makes a pretty table.<br>
2. You expose the info (via hook_schema) to drupal<br>
3. You implement hook_cheesefields_info() and to say which field is<br>
the key and which entity type it maps to.<br>
4. cheesefields then implements the entity api hooks based on our<br>
tables fields and their data types. We get widgets and everything,<br>
with the ability to do an alter on the autodetected widgets and<br>
specify alternative widgets.<br>
<br>
To put it a different way, all your fields in one table is not<br>
different to a field module that defines multiple fields. We just need<br>
to expose it correctly.<br>
<font color="#888888"><br>
Simon<br>
</font><br>
PS. If you know of this cheesefields module please tell me.<br>
<div><div></div><div class="h5"><br>
<br>
<br>
<br>
On 20 October 2011 17:11, Mukesh Agarwal <<a href="mailto:mukesh.agarwal17@gmail.com">mukesh.agarwal17@gmail.com</a>> wrote:<br>
> Thank you Ernst for the advice.<br>
> I think we could have achieved different revisions for each field by marking<br>
> a field in UI as something that requires revision which would mean only<br>
> those fields that require a different revision can do that. Same goes for<br>
> translation. I think the entire field entities API is nice and makes<br>
> programmers life easier. But in trying to make things generic, we have added<br>
> a lot of overhead on Drupal core - content management system.<br>
> Using MongoDb is a good option. I like the idea but since the support system<br>
> for the same is not that strong, I'm sure clients will have a concern.<br>
> I'm not sure if I want to chuck Drupal as a solution to our problem. Will<br>
> have to find different ways.<br>
> Not convinced with the separate fields idea though.<br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Cheers,<div>Mukesh Agarwal</div><div>________________________________</div><div><font color="#999999"><a href="http://www.innoraft.com" target="_blank">Innoraft Solutions</a> || </font><span style="color:rgb(153, 153, 153)">+91 8017220799</span></div>
<br>
</div>