Also see #1346214: [meta] Unified Entity Field API and #1540656: [META] Entity Serialization API for web services (e.g. content staging).

Let’s add metadata about all entity properties, so any module can leverage this data and/or add more metadata around properties. The metadata should include a human readable label, optionally a description and a precise description of the data.

Reasoning

The entity API module introduces already hook_entity_property_info() for Drupal 7 (see here), but it sometimes requires additional data wrangling (getter, setter callbacks) and the use of wrapper objects. However, the goal for Drupal 8 should be to make this additional abstraction layer obsolete - by having properties matching their metadata in the first place, as well as an native and simple to use API that allows easy access to properties.

Why, for what and when is it useful?

  • For improving entity-related DX! Based upon property information we can improve the entity API helpers, e.g. just use $comment->get('node')->get('user') to get a comment's node's author.
  • Generally, as foundation for all property based APIs (see #1346214: [meta] Unified Entity Field API). It’s like having field info, without the restriction of having a field.
  • As helper when transforming / exporting / importing data: Knowing your data and in particular relationships helps a lot when exporting/importing. Example: Restful services can add pointers as URIs (e.g. as seen here), UUIDs could be exported and “resolved” upon import, ...
  • RDFa / microdata modules can define their mappings based upon the defined properties
  • Basic default token replacements could be provided based upon property metadata.

Next, modules in contrib could do/do already:

  • Search API already builds upon entity property metadata to know which properties can be indexed and how to get the values.
  • Rules needs to know about properties for providing data-selection.
  • Rules needs the metadata to know which property can be written too and what kind of data is suited.
  • CTools’ context relationship API could re-use metadata about entity relationships.
  • Probably many more...

Related, it's establishing a way to describe data in drupal (=metadata). That's needed in many places so we should settle on a single way to do so. E.g. a new Rules or a new Actions API for core would have to describe needed action paramters, or a block required contextual data.

But moreover, I think it’s crucial for the entity API to evolve based upon a property API. It potentially enables developments like:

  • Auto-generating db-schema based upon property information (Yes, similar to fields.)
  • Auto-generate forms based upon property information (like widgets)
  • Auto-generate entity display components based upon property information (like formatters)
  • Apply validations based upon metadata (validate it's a integer, or has to be a mail address). Think REST services.

see #1346214: [meta] Unified Entity Field API

Status

WIP. Code is being working on in the "entity-property-*" branches of the sandbox at http://drupal.org/sandbox/fago/1497344

CommentFileSizeAuthor
#10 d8-entity-property.patch43.83 KBfago
#5 d8-entity-property.patch42.78 KBfago
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Xano’s picture

There are a lot of hooks that provide metadata for 'data structures', such as:
- hook_schema()
- hook_views_data()
- hook_token_info()
- hook_entity_info()
- hook_entity_property_info()

We should think about centralizing (duplicate) metadata in a single hook, say hook_metadata_info() for lack of a better name at this point.

This hook would purely describe data, not storage. DB backends would have to convert the metadata into correct MySQL or PostgreSQL column types, for instance. Token would know exactly what properties are available, etc. Views would perhaps require an extra property to verify a data structures metadata maps to a DB table, so it can get the data using a query. An integer property would have a minimum and a maximum value, which would allow basic validation, like fago already suggested, but would also allow DB backends to determine the size of the integer column to create and whether it needs to be signed or not.

Data structures do not necessarily have to be entities, nor do they have to be available to Views. The hook itself would only describe the data in a general way. Specific users of the hook (Views, Token, DB layer) can require extra metadata for integration.

Also see #1374068: hook_metadata_info().

sun’s picture

Issue tags: +Entity system
fago’s picture

We should think about centralizing (duplicate) metadata in a single hook, say hook_metadata_info() for lack of a better name at this point.

This hook would purely describe data, not storage.

Exactly. That's 100% what entity property info is about. It describes the data the entity represents. Modules might indeed generate quite some bits of its generation data based upon that metadata, what I'm already experimenting with the entity api module for D7, e.g. generating views integration.

Also see #1374068: hook_metadata_info().

Well, metadata about what? hook_X_info() already says that we are describing X, thus adding metadata for it. I'd argue we should create more targeted hooks and avoid over-generic stuff. Thus, once the need the for non-entity metadata comes up we can add a hook for it.

fago’s picture

Issue summary: View changes

Updated issue summary.

fago’s picture

Issue summary: View changes

Updated issue summary.

fago’s picture

Issue summary: View changes

Updated issue summary.

fago’s picture

I've started working on that during the entity translation code sprint in Denver, where we (klausi, sun, plach, gabor, dawehner, plach, me and others) discussed the general idea and the initial code. Code can be found here.

As of now we've added the basic system and improved the Entity API (entity_create(), getters and setters) to make use of the metadata. For now, property info has been added for comments and the test entity.

The current system does not yet add in property info for fields, that's TODO and will be implemented just by having field.module implementing the regular hook. Also, it does not yet add a hook for registering and describing further compound data types (such as new field types).

E.g. this is how comment properties are described right now:


/**
 * Implements hook_entity_property_info().
 */
function comment_entity_property_info() {
  $info = array();

  $info['comment']['properties']['cid'] = array(
    'label' => t('Comment ID'),
    'description' => t('The unique ID of the comment.'),
    'type' => 'integer',
  );
  $info['comment']['properties']['subject'] = array(
    'label' => t('Subject'),
    'description' => t('The subject of the comment.'),
    'type' => 'text',
    'required' => TRUE,
  );
  $info['comment']['properties']['created'] = array(
    'label' => t('Date created'),
    'description' => t('The date the comment was posted.'),
    'type' => 'date',
  );
  $info['comment']['properties']['node'] = array(
    'label' => t('Node'),
    'description' => t('The node the comment was posted to.'),
    'type' => 'entity',
    'entity type' => 'node',
    'required' => TRUE,
    'storage field' => 'nid',
  );
  $info['comment']['properties']['user'] = array(
    'label' => t('User'),
    'description' => t('The author of the comment.'),
    'type' => 'entity',
    'entity type' => 'user',
    'required' => TRUE,
    'storage field' => 'uid',
  );
....
}

With that information in place comments can now be created like that:

    $comment = entity_create('comment', array('node' => $node));
    $comment->save();

Then, e.g. a comment's author can be retrieved or updated that way:

// Get user account.
$account = $comment->get('user');

// Just get the uid:
$uid = $comment->getRawValue('user');

// Update the author by uid:
$comment->set('user', 1);
$comment->save();

// Update the author using an entity:
$comment->set('user', $account);
$comment->save();

Once, we'll have field.module support implemented field values (and field based entity references) will be supported exactly the same way.

fago’s picture

Status: Active » Needs review
FileSize
42.78 KB

Also, here is a first patch for the test-bot. Includes the RTBC patch from #1277776: Add generic field/property getters/setters (with optional language support) for entities.

Status: Needs review » Needs work

The last submitted patch, d8-entity-property.patch, failed testing.

fmizzell’s picture

Status: Needs work » Active

First of all I would like to say that I think the metadata wrappers functionality in D7 is great, and I am glad to see that there will be a more native support of this kind of functionality (no more wrapping to get useful setters and getters ☺).

In ECK, I am mainly interested in “bundles” of reusable logic that can be shared between multiple entity types. This is why I am interested in the entity property metadata as it will set the precedent on how these things are done.

Currently you can connect a property with a setter, a getter, and a validation function (I know a lot more can be done, but I am currently concerned with logic). This functionality can get you a long way, but in some cases it might be too restrictive.

For example, let’s say we have an application that keeps track of points in a Cartesian plane, and of whom created them. Having a setter and a getter for each x, y and the user will take us a long way, but when we need more useful functions that are aware of the link between x and y (ex. addPoint( Point p) ), the property info does not have any way to describe this. Some might argue that the fact that this function is linking multiple properties means that this is logic that should be at the entity and not at the property level. What I would argue is that having these two levels of logic is unnatural.

The way I would like to encapsulate my logic is by creating a Point class with all of the necessary methods that I need to manipulate my data. I could easily implement my idea in D8 since we will have classed objects that can have all sorts of methods, my question is, how is the property metadata concerned with these extra methods (How can Rules know that I have all sorts of other useful methods beyond a getter and a setter?), and what about the user reference? I really don’t want to add a user variable to my Point class, since they don’t interact in any way. What I would like is for that logic to be somewhere else (I could use the entity info as-is to connect some logic with my user property just fine).

There is a chance that the entity property info can already do what I am talking about or that these constraints have already been addressed in the D8 implementation of things (fago’s sandbox which I have not looked at yet), but either way I would like to be involved (help out) as this will affect how ECK’s functionality evolves.

fmizzell’s picture

Status: Active » Needs work

Sorry I guess we posted at the same time, did not mean to change the status

fago’s picture

Status: Needs work » Needs review

Sounds like you'd need support for complex data-types being non-entities. For d7 that's already possible, e.g. have a look at the implementions for field types like image-fields or formatted text fields of the entity api module.

For d8 complex data-types are todo. I've just started creating some issues for figuring that out in D8 over at the sandbox. Let's discuss details over at:
#1525812: add support for complex data types
#1525816: add support for fields
#1525896: improve date and duration handling
and others.

fago’s picture

FileSize
43.83 KB

also, I've updated the patch/branch to fix test failures. The entity translation still fails due to missing field support though.

Status: Needs review » Needs work

The last submitted patch, d8-entity-property.patch, failed testing.

pounard’s picture

Are you sure that the property info definition accessor belongs to the entity itself?

fago’s picture

That's just a shortcut, there is entity_get_property_info() as well (just as for entity info). Still, I think that accessor is very helpful? It's already used in getters/setters and allows for code like

foreach ($entity->propertyInfo() as $name => $info) {
  // Do something with the property.
}
pounard’s picture

Yes maybe, I'm not sure if that's what I imagined for properties at the very begining, I must admit this is very introspectable, but also subject to a lot of code indirection for fetching and setting properties. I don't have a strong opinion yet.

What I'm afraid of is that with a heavily metadata array based property system is that we may end up with an in-memory array nightmare such as the Entity API module does, and a really hard to debug system. At least this module does not keep those array copies in each object, but I'm still not persuaded this is really good.

I imagined an API for storing and querying those properties would be a good start, but metadata introspectability may not be crucial at first because specific entity classes would be able to expose clean accessor with direct access to those properties, without having to know anything thought metadata, metadata may only help to do black voodoo magic such as views does, but I'm not convinced that black voodoo magic always is the answer, I tend to think the opposite.

fago’s picture

>..but also subject to a lot of code indirection for fetching and setting properties
What indirection do you mean? All it does is handling entity references and translations - wouldn't you expect getters/setters to do so?

>because specific entity classes would be able to expose clean accessor with direct access to those properties,
Sure, we could hand-code accessors for all properties provided by an entity type. But that would never work for module provided properties or fields. Thus we'd end up with an even more inconsistent DX as in d7, which works fine for some hand-picked properties and leaves you alone with the rest.

I'm not sure what you mean with doing black voodoo magic? Working based upon array definitions / configuration? Sure, we'll have to keep an eye on memory-use and debuggability. But still, imo working based upon array definitions / configuration is the core of Drupal's flexibility and so of what makes Drupal Drupal.

pounard’s picture

By magic, I was speaking about fat ass big arrays, that the user would manipulate directly in order to fetch data, but arrays are not self-documenting, there is no compile check (no way to determine bad code before runtime) and cannot be source of autocompletion in editors.

Those are only questions, I admit we clearly have to go towards a maximum of flexibility for module added properties, things such as a subset of the Flags module for example could be implemented using this, and this would be awesome. I'm just asking myself existential questions about the design. And some really bad experiences with Entity API also make me raise some red flags.

Also, something else worries me, is that if everything is info based, let's say including the node status, does that mean that an info_alter hook somewhere would allow me to drop the status property? I guess by design it would possible, but I also guess this would make the whole framework to bug, throw exceptions and fail. What is the good tradeoff here, and how could we make some properties to be hardcoded by definition and not removable?

I think the info based properties are good, but they are a subset of properties, not their definition. I think that making everything info based is not really straightforward and somehow dangerous (and slow by definition). Maybe starting by clean interfaces for property discovery/introspection is the way before even starting to implement all of them as info based.

Plus, this method implies there is a global info fatass array somewhere, it's not really scalable and it's global state, it's bad.

For example, I would prefer that we'd speak raw abstract design first, and worry about the implementation later, I see something like this:

interface PropertyDefinition {
  public function getType();
  public function getName();
  public function getDescription();
}

interface PropertyContainer {
  /**
   * @return array Key/value pairs, keys are names values are PropertyDefinition instances
   */
  public function getAllPropertiesDefinition();
  /**
   * @param string $name
   * @return PropertyDefinition
   * @throws UnknownPropertyException
   */
  public function getPropertyDefinition($name);
}

interface PropertyObject {
  /**
   * @return PropertyContainer
   */
  public function getPropertyProvider();
  /**
   * @return array Array of mixed values
   */
  public function getAllProperties();
  /**
   * @param string $name
   * @param boolean $throwException
   * @return mixed
   * @throws UnknownPropertyException
   */
  public function getProperty($name, $throwException = true);
  /**
   * @param string $name
   * @param mixed $value
   * @throws UnknownPropertyException
   */
  public function setProperty($name, $value);
}

// Missing the "bundle" layer here, this is for sample purposes only.
interface EntityControler extends PropertyContainer { /* ... */ }

interface Entity extends PropertyObject { /* ... */ }

which looks like more a real abstract introspection API, and which can work without global state: this removes the global info state, and hide the implementation behind explicit interfaces. From this you can derivate a default implementation of PropertyContainer able to aggregate properties from multiple sources (info hook, database, configuration, hardcoded), from which you can inherit for making node specific implementation, comment specific implementation, etc... This allow you to build straightforward and safe code for common business object and properties, while still behind extendable.

I may be off-topic here, but I think having code right away, basing all on info hooks, without taking into account other initiative advancements (WSCCI, CMI, etc...) removing global state, relying on container, while almost copying/pasting code from the Entity API module, which has its drawbacks, seems dangerous to me.

I know my post may be a bit late and against the actual direction this issue is taking, but it's because I didn't have the chance to participate to other discussions, and I know you done a sprint in Denver, and you probably made some serious decisions there based on real needs, but are those needs really worth it to have a huge fatass property array hanging in memory while having a more granular/local introspection based approach might fit best with the global state removal attempt of core and might be less performance intensive for common operations the framework would run on a day basis? Plus the info array options is not interface based, and provide zero flexibility for people that would need to implement it differently (I'm thinking about proxy pattern to external data or other libraries objects, for example).

Basically, having a runtime introspectable library at local level would allow to implement views or rules introspection as easily, even more easily, than it is now, thanks to an interface based design.

fago’s picture

Also, something else worries me, is that if everything is info based, let's say including the node status, does that mean that an info_alter hook somewhere would allow me to drop the status property?

No. Having info hooks does not mean we support every possible alterations of them. You can already screw a lot with altering stuff that is not intended to be altered, so you are on your own if you decide to do so. That's the way we currently do it.

From this you can derivate a default implementation of PropertyContainer able to aggregate properties from multiple sources (info hook, database, configuration, hardcoded), from which you can inherit for making node specific implementation, comment specific implementation, etc... This allow you to build straightforward and safe code for common business object and properties, while still behind extendable.

I actually like the idea of having a propertyInfo() method in the storage controller very much, still that does not mean we cannot have a global info hook in the back.

interface PropertyDefinition {
  public function getType();
  public function getName();
  public function getDescription();
}

I've been thinking about using classes instead of array for providing metadata too. I must admit the advantages are very nice, however it does not play with Drupal's modular approach. E.g., it's not possible for a module to define a new PropertyDefinition method/key and to annotate existing properties using that key. For example the microdata module currently does that in D7 and I do think the ability to extend property metadata definitions is rather important.

Also, I'd like to stay focused on what we want to achieve and go with common patterns/solutions. Improving the info-hook system really is another issue and out of scope for doing entity property metadata. Thus, the switch to classes in info hooks should be its separate discussion, whose outcome then should be applied to all of Drupal.

I may be off-topic here, but I think having code right away, basing all on info hooks, without taking into account other initiative advancements (WSCCI, CMI, etc...) removing global state, relying on container, ...

I'd be happy to follow any improvements that the initiatives make. Still, "global" info arrays have not (yet?) been replaced nor I'm unaware of of clear trend/plan here?

I also fail to see how we are introducing global state? Yes, we've a list of registered entity types which is "global to the system" already. This is about adding metadata about properties to them, which are likewise "global". I'd be happy to get enlightened here, but I fail to see how a system should work without "global" registration mechanisms + I feel like it's a separate discussion to have.

...while almost copying/pasting code from the Entity API module, which has its drawbacks, seems dangerous to me.

The code is actually to 99% rewritten, as the d7 entity api module hat to wrap all data while this is about adding native support + takes experiences into account. That said, I'd love to hear about your bad experiences with the d7 entity api.

I know my post may be a bit late and against the actual direction this issue is taking, but ...

Your input is very much welcome. I don't think it goes against the direction of this issue but helps to improve it! :-)

...but are those needs really worth it to have a huge fatass property array hanging in memory while having a more granular/local introspection based approach might fit best with the global state removal attempt of core and might be less performance intensive for common operations the framework would run on a day basis?

Yes, we'll need to make the info-access most specific as possible so we can reduce any performance impacts. I.e. avoid access the global array of info if possible.

Plus the info array options is not interface based, and provide zero flexibility for people that would need to implement it differently (I'm thinking about proxy pattern to external data or other libraries objects, for example).

I don't think the interface based approach brings more flexibility into the game as you can totally control the contents of the info-hook too. It might be more efficient to convert existing metadata on the fly instead of retrieving it from the cache in some places, but that means you'd have to run hooks/alterations on the fly too. Given you cannot know what modules need to do to retrieve any possible added in metadata, I think it still makes sense to retrieve the entity-property metadata once and cache it then.

Basically, having a runtime introspectable library at local level would allow to implement views or rules introspection as easily, even more easily, than it is now, thanks to an interface based design.

That's the idea. I'm not sure it needs to be interface based for that though, but as said I like the idea of adding metadata accessors where suiting. It makes retrieval easier and encourages specific access (vs. getting all info).

For example, I would prefer that we'd speak raw abstract design first, and worry about the implementation later, I see something like this:

Yep, we should discuss the high-level implementation first. I tried to start over at http://drupal.org/node/1525812#comment-5852274

sun’s picture

I agree with @fago's "defense" and would like us to move forward with the existing proposal/patch.

Can we get a re-roll here without the changes of #1277776: Add generic field/property getters/setters (with optional language support) for entities that landed already?

pounard’s picture

That's the way we currently do it.

That's still dangerous and fragile.

I actually like the idea of having a propertyInfo() method in the storage controller very much, still that does not mean we cannot have a global info hook in the back.

I wasn't saying we couldn't have a hook as a module extension point, we definitely can, but this shouldn't be the first class API, but just one alternative property provider for easing extension by modules. Having a clear OOP API would make development around properties so much easier (I speaking discoverability because you already have figured out object interfaces with primary accessors). BTW propertyInfo() would be a getter, may I suggest it would be called getPropertyInfo() in order to avoid confusion with methods that do something.

I've been thinking about using classes instead of array for providing metadata too. I must admit the advantages are very nice, however it does not play with Drupal's modular approach.

It can be compatible with current Drupal approach, and it would make it easier to migrate if that approach changes. By defining an clear and abstract interface based API we could plug anything behind as soon as the approach changes and keep the discoverability API stable at the same time (backend/frontend separation).

Also, I'd like to stay focused on what we want to achieve and go with common patterns/solutions.

Having a common API is achieving a common pattern, core then would implement its own solution, and the modules would be able to either use it or either implement their own for performance or practical reason, and keep it API compatible at the same time very easily.

I'd be happy to follow any improvements that the initiatives make. Still, "global" info arrays have not (yet?) been replaced nor I'm unaware of of clear trend/plan here?

Global is being wiped out, we can see it with the Symfony's kernel and dependency injection container inclusion in core. Basically, those two make language, url and menu controler discovery driven by listeners more instead of being hardcoded or info based. This is not totally true for menu yet, and there will always be some kind of registration mecanisms, but the real important point is that it hides the way it's being done behind interfaces or containers. Which is somehow what I'm saying about properties here: having a complete public interface based API may allows us to be more flexible about how those information gets into the user hands.

I also fail to see how we are introducing global state? Yes, we've a list of registered entity types which is "global to the system" already.

This is exactly the definition of global state, indeed, you're not failing here.

I don't think the interface based approach brings more flexibility into the game as you can totally control the contents of the info-hook too. It might be more efficient to convert existing metadata on the fly instead of retrieving it from the cache in some places, but that means you'd have to run hooks/alterations on the fly too.

Some (a lot of) properties will probably be the reflexion of how it's being stored and consumed in the code, I don't see the point (at all) of allowing their alteration. The important part is allowing modules to add some, not to alter the existing ones. Yes, maybe the alteration is the most flexible way, but it's also the most dangerous and the most fragile one. Having an interface based API actually is more flexible for the implementor, because he's not tied to the info array and he can provide straightforward implementation of his own for his own properties. The challenge here would move to the way to register new properties, but if the core implementor allows it either by aggregating multiple provider behind a proxy pattern either by using an info array internally, or both, then it still as flexible as the alteration mecanism.

That's the idea. I'm not sure it needs to be interface based for that though

Indeed, it doesn't if you go for info array to be the only provider possible, but if you allow other registration mecanisms, then you'll need it to be interface based. You could achieve anything using inheritance magic or such, but that's probably a lot harder to maintain over time.

Hope it answers some of your questions.

Berdir’s picture

- I *think* the idea is to move from info hooks which return (more or less static) arrays to CRUD functions based on the config system, so something like entity_add_property_info($entity_type, $name, array $info). I guess there are still quite a few things to figure out (like a translation system for config) before that is ready and there is no reason to wait until that is complete.

- The PropertyDefinition interface could be made extendable by adding a generic get($name) or so. However, I think using classes like that makes it more complex to persist the information. Because with the config system, we essentially support storing name/value pairs + nesting. Maps very nicely to associative arrays. Objects? Not so much... We have been discussing this also for our Translation Management Tools project, where we use a form-api like structure (because we need nesting) to store extracted text pieces, we'd like to replace that with objects which are easier to use but have no idea on how to properly persist that...

- There are a few things which I do not like about Entity API properties in 7.x but I think most of them are because it is a contrib module built on top of an existing and limited entity system in core:

1. Having enormous entity and property information arrays in every single metadata wrapper combined with the fact that every single property itself is again an entity wrapper.
=> This has been fixed recently in 8.x by removing the info property from entity classes.

2. Entity Wrappers. I understand their purpose but it's a mess because you often need to check if it's a wrapper or not, even just to get the id of an entity and it doesn't play nicely with many API's, like token_replace(). Also, their attempt to be pseudo-backward compatible. They can't be because (int) $user->uid will throw an exception as it's an object and there's no __toInt(), just as an example).
=> Entity classes provide the functionality that wrappers do, so I hope we won't need them in 8.x :)

3. Debugging wrapped things is hard, because var_dump()'ing them (or print_r()) is longer than the lord of the rings books and dpm() doesn't give you anything at all. There is also a lot of indirection and magic function calls involved.
=> Better thanks to the removed entity info properties from objects, we can teach dpm() to talk with entity classes and extract information based on property info I think and I have hope that we can simplify things if we don't have to use magic methods to try and fake being not a wrapper :)

So as a conclusion, I have hope that entity properties will be much easier to work with in 8.x than they are in 7.x :) And sorry for the long text, that wasn't planned..

pounard’s picture

Maps very nicely to associative arrays. Objects? Not so much...

You can map anything into objects, they are complex only if you think them complex, I think people are just using too much arrays to see that. It's a false affirmation.

Entity Wrappers. I understand their purpose but it's a mess because you often need to check if it's a wrapper or not, even just to get the id of an entity and it doesn't play nicely with many API's

Indeed, @fago you were asking about the problems I got with entity wrappers, this is one of them.

Debugging wrapped things is hard, because var_dump()'ing them (or print_r()) is longer than the lord of the rings books and dpm() doesn't give you anything at all.

Yes, this is one of the side effects, but I don't call that debugging, I use xdebug (devel is obsolete for me in that regard, except for performance logging and generate features which are the only two I may use from this module).

Nevertheless, I understand your point of view and I agree about the fact that the current design doesn't store properties into entities directly, which makes the whole system a lot more easy to debug than the Entity API; Nevertheless it still couples the objects with global state functions and registry.

jfk24’s picture

I must confess I am just a lowly newbie in this game.

However, based on what I am trying to do right now (which is describing attachments), I would prefer to have the metadata as part of the database as fields or subfields (in essence turning the attachment into a nodetype).

This means that for well known attachment types it would be relatively simple to provide modules that could strip the info directly from the file and autopopulate the database, while still enabling the easy addition of metadata about the file from sources other than the file itself.

fmizzell’s picture

[Edit: Silly me, after going through all of the metadata related issues, I realized that most of the "fears" expressed in the now irrelevant comment (below) are meant to be addressed here #1525812: add support for complex data types]

I was just taking a look at the patch, and I noticed that the Entity class is doing a lot of the heavy lifting that the Wrapper used to do in D7. Is this the way we want to go? At the beginning I was kind of excited about not having to wrap my entities, but the more I play with the metadata stuff the more I wish for a SUPER DataWrapper that I can throw any data to (xml, array, json, object, string), and some info about how it is structure and it will do all sorts of amazing things for me (validate, give me forms so users can set my data, store for me, etc). From the patch it seems like D7 was closer to that idea than the current patch. I guess I am just wondering what the end game looks like?

fmizzell’s picture

Issue summary: View changes

Updated issue summary.

fago’s picture

Status: Needs work » Postponed
Gábor Hojtsy’s picture

This would be duplicate in that case, no?

fago’s picture

Status: Postponed » Closed (duplicate)

Oh, yep that fits better - thanks.

fago’s picture

Issue summary: View changes

Updated issue summary.