One of the main features of the upcoming Drupal 7 is the ability to add custom fields to content types in a user-friendly way. For example, one might add a content type called Recipe, where it has the following fields: Title, Ingredients, Instructions and Photo. On earlier versions of Drupal, such content type had to be hard-coded by a web programmer. With Drupal 7, a webmaster may create it with a few clicks.
Now imagine a generic content type called iContent that could be transformed into anything instantly by the average user. This content type would include all available types of fields (text, number, date, file, etc) with an unlimited cardinality (i.e. the fields could be repeated if necessary).
So let us suppose a user wants to enter a Recipe. He selects the iContent and starts building the structure on the fly. He adds the Title, then the Ingredients, later the Instructions, and finally a Photo. Now, he might want to enter a Movie. So he adds a Title, then the Director, later the Duration, then the Release Date, the Genre, a Picture, and finally the Plot. He might want to save both the Recipe and Movie structures for later use as templates. But notice that only one content type was necessary to build such different content structures.
This is a simple idea, but a very powerful one. It makes us rethink how we create information today. Email, for example. You only have the option to enter the Title and the Body. No other fields are allowed, with the exception of Attachments, which provide the flexibility we are looking for since it has an unlimited cardinality. Why not extend that same flexibility to the other fields? Blogs are another example. Imagine how much richer would the Web be (semantically) if blogs had this kind of flexibility?
I believe that is called “Wordpress” that has had custom per-post fields for years.
Very nice observation Damien! You are completely right:
http://codex.wordpress.org/Using_Custom_Fields
But I believe Drupals’ Fields are in a whole new level when compared with Wordpress’ Fields.
It would be best, imo, if there were a way for the administrator to set up a bunch of more-or-less generic fields, and then on the node addition page, a pop up menu would appear if the user wanted to add a ‘video’ (using video field or emfield), a podcast file (using filefield/ffpc), or an image (using imagefield).
That way the admin would still be able to control the fields, but the user would have a little less clutter/more freedom.
Wordpress’ fields are convenient for simple metadata, but they aren’t all that flexible (even if you are good with PHP).
This also called typo3 where you can add different types of content in any order to a page.
in order to avoid confusion and loads of content types we hardly have any use for, we could link this idea to the rdf semantic model. once the dynamic typing of the content is set, expected fields would naturally show up. new fields could be added, and depending on the website editor/manager some of the fields could be required.
this would help users creating new content, since choosing a content type usually restricts the user and adds a lot of confusion.
would like to help getting this idea implemented.
But I don’t see what the benefit is. You then have a bunch of unrelated content all under the same heading with no way to sort/filter/ it. The content is now delineated so you can tell where ‘field’ data starts and ends, but I don’t see how that is useful either.
Two things:
1. What about relationships between content types, that’s a most important thing for Drupal based website applications; for example a newspaper with editions and articles which point to those editions.
2. This functionality is available in Drupal 6, at least as you are presenting it, not just Drupal 7.
Victor Kane
http://awebfactory.com.ar
http://projectflowandtracker.com
@barraponto: Excellent comment! I hope to further discuss this with you at DrupalCon Brazil!
@dalin: You can still sort/filter by author, date and title. The main benefit is having this flexibility.
@victorkane: The key idea is empowering the average user with this flexibility (while still keeping it simple). Fields in core is an important step towards this goal.
@dalin integrating the “icontent” with rdf you can actually sort it the way we are all used to in drupal. but you can also have some fun with SPARQL and sort fields on a lot of different ways. and having it integrated on a SQL-database means it can run just as fast as we are used to.
@nick sure thing. now thinking about the ISS framework you’ve been developing for quite some time, i hope these ideas can fit together. i see icontent and iss as killer features for a blogger, since it means posts fields can be extended on the fly, rdf-support can help sort it out, the theme-layer can support some fields (we can actually have tables of rdf-support for themes) and feed readers can choose what to display (or not) to the end user (the reader).
Awesome barraponto! You got the point! Indeed this is part of ISS!