Posted by mki on December 15, 2006 at 1:49pm
The most abstract concept in my opinion: "everything is a field" (fully atomic value) instead of "everything is a node". CCK is ardent proof that this idea could work. If that's the case, we can share the same field (as regards value), node is just a set of fields tie together by new relationships system, whereas content type is a predefined set of relationships between fields.
This is also promising for wanted feature at number 4 in Relationships-categorization wanted features, where every field will have described meaning.
Please compare this problem to: Global CCK fields and A controversial(?) point: store translations as nodes.
Comments
Everything is a field - Everything is a node
My point of view : actually the main Drupal concept is "everything is a node".
I have no objections against implement a translation system system that permits the translation only of
single fields, but at now, it would be a very hard work and every non-core modules related to node should
be rewritten.
In fact I see a main basic problem that prevents us to easily select a translation engine and implement
it without too much effort : we don't have a model concept.
Actually we have SQL code spread everywhere and it is very difficult in this manner to implement a translation
system based on field basis.
Having an active record pattern like in Ruby on Rails or CakePHP would be of great help not only to
implement a translation system, but also to improve the code management.
I mean a structure where a model directory contains all models of different objects / tables and some
API like, for example, :
node_find($nid)
node_findall($where, $order)
with some hooks inside this API you could translate the single fields without the need to touch
to much code.
--
http://www.speedtech.it
--
http://www.speedtech.it
Nodes are OK, but separated from its fields
Main problem connected with node concept is that nodes (instead of fully atomic fields) are used to storing data. This have impractical consequences:
For these reasons, we can't displaying node fields that can be free selected on account of not only content type, but also user preference, localization, permission, and the like.
To do this, we must separate nodes from its fields. (In CCK this idea comed to true, but not completely and with limitations, so this needs changing.)
For example:
Node: "Teletubbies" TV program.
Which field to display:
Node: Search result / view.
Which field to display:
Result for both: a set of fields meet the above requirements.
But... we have sea of fields and we need efficient fishing pole (relationships-categorization system) to select right fields. E.g. to sharing fields between nodes we probably need many to many relationships system.
As you can see, I don't want to give up node concept, so modules changes will take place in an evolutionary, painfree manner. I believe that CCK can be the best point of departure for implement this idea. There we can find (and improve) data access layer -- we have a lot of functions to manage fields, field types, content types etc, and SQL code is defined in one place. For now many modules use CCK for its content types, other use own created tables or "node" table becouse CCK is not a part of Drupal core. If these functions will be included to Drupal core, will evolved from module towards "official" and recommend, we will get rid of this problem.
Moreover, we can provide additional module that will do "translation" from old nodes base API ("old-fashioned" modules will use this) into new fileds base API implemented in Drupal core, and we will not in a hurry to update all modules of a sudden. Now Drupal work on nodes base and we don't have the benefits of fields base, so why we must provide these benefits for all modules so suddenly and at one go? We can't but this can wait.
I put forward this idea becouse I don't want new i18n system based on insufficient node base. We need to look to the future instead of conservative approach. Otherwise, our solution may by insufficient.
code can be reworked
Drupal is not one of the content management systems, which tries to stick old insufficient implementations around. The philosophy here allows for code refactoring and rewriting when new releases emerge.
Anyway, we would need to support i18n for node types, where a field concept is not in place. Unless reworked, all core node types fall into this scheme (title, body and status flags all tied closely into the node). Most of the contrib node types are also in this area. To support these types, we need to implement node based translation anyway (or we would only support the new field based model if that comes around, without the older node types being supported).
For nodes to get reworked for this field based model, you are free to start with the simple pieces: freeing nodes of their titles bodies, teasers, authors, flags (published, promoted, sticky), permissions. Also push revisioning onto the field level. What's left for nodes is the node id as it seems. Everything else seems to be required on the field level to fulfill the outlined needs. This is a fundamental change, so feel free to bring this up on the development mailing list, create patches, get them into core.
As you pointed out, such conversion of existing node types will not happen at once. As long as all the conversion is not done, we need to support the "old" node based model, so it does not seem to be a waste of time to work on an implementation using this model. We can adapt to the field based model too if an implementation comes around.
Many thanks for
Many thanks for conversation, after thought this sounds convincing to me: the natural course of events is that at present we need support node based model.
Much as I'd like to help, I don't have adequate knowledge about informatics and Drupal (all the more time to teach oneself) -- this is only my end-user (non IT specialist) reflection. But this concerning Drupal future, so I decided that I will post this here and get a conversation going for Drupal auspiciousness. So everyone who are intrested in this, please step into the breach.
I agree with your
I agree with your abstraction, Field would have been a better starting point instead of node.
But I am thinking all is not lost and we can achieve your goals a slightly different route, achieving what you are suggesting in spirit.
I am thinking CCK Sub-forms module can help address that.
1. Here we can create CCK content types with one or more fields in it. We could think of this as a grouping of shared fields.
2. We then create a main CCK content type with one or more of the content-types created in (1) above.
This allows for CCK-content-types to be treated like a field or group of fields, which can then be viewed/edited through a main page that might bring one or more of these CCK-sub-content-types together on a single page. This will allow separate versioning and access control of these field groups.
Will this approach meet the needs you have described.
Searching for strategic, not stopgap solution
Thanks for your support for fields idea. My personal needs are currently satisfied among other things by great subform module, but I hope your alternative to fields base will useful for someone. At present we are talking about long-term and strategic cause.
I am thinking sub-forms or
I am thinking sub-forms or some enhanced version of it, could be the foundation we are looking for, to realize your idea.
And I am not thinking of it as a stop gap solution at all.
It seems to has all the advantages you are refering and some more.
Sarvi
Subform will be one of inspirations
Subform module above all is useful UI for content management. In relationships layer, subform provide some similar solutions like several other modules. Please see Relationship module features and then you see how powerfull and abstract such system should be.
Despite everything, we need to grasp all possible solutions. In my opinion, Subform will be one of inspirations, but it's not very probable that we will take it as foundation stone for relationships system. All what we need is stoic calmness and patience in looking for some consolidated concept in this area, that will perform well.
Need to separate Model and View
Just a snippet of two cents worth here:
Apart from the great difficulty in getting subform to work at all, which agreed is "overcomable", there is an important consideration here: cleanly dividing the relationships part (the business objects (nodes) and the relationships they have (model)) from the user interface implementation. In other words, I shouldn't have to use subforms to get the relationships. I should have relationships that you can somehow use in Views, for example, and it should be straightforward to set up different forms of user interface based on the model.
Victor Kane
http://awebfactory.com.ar
Victor Kane
http://awebfactory.com
Certainly
This is power of Drupal, that we have one common business object (node), that are extended by every module. The same should concern relationships system.
Subform, as the name itself indicates, was to be designed most likely as UI, and own relationships system was privided ad hoc to fill the void as long as we don't have relationships system in Drupal core.
I agree with all that ur
I agree with all that ur saying. I understand the separation ur suggesting. I am not necessarily attached to subforms in the long run, though it seems to be the one closest to addressing my problem space for now.
The reason I even brought it was to point out that the current node based mechanism with relationships between them and UI mechanism(View, Subforms or whatever) would work pretty well. Meaning, current nodes will do well and that we don't have to start over with fields again like this thread is suggesting.
Sarvi
good idea, but the implementation is not there
Strategically, it sounds good to think on the field basis. But at present there is a very big amount of features concentrating around nodes. There is no support for field revision control, field level permissions, field level search, etc. Fields are a good future prospect, but basing Drupal on fields instead of nodes has a long way to go. Unsurprisingly Drupal 5 will come out with a custom node type UI, without support for custom field features. Drupal as a whole evolves around nodes at present, and we need to keep this in mind. It is of course not a problem to provide implementation and form a strategy around fields as base objects.
Please read my reply to
Please read my reply to Roberto, he commented first so I posted there but in fact I replied to you both.
CCK addresses this with autonormalization
by only 'breaking out' fields that are present in >1 node / content type, CCK already makes the best distinction; a difference when there is one, and not when there isn't.