Hello guys, while figuring out a good way to implement your (awesome) module I couldn't find a good explanation for why (the hell) there is a need to attach locations to nodes / taxonomy / users directly via the entity options? Shouldn't all the cool stuff be doable with fields only? I really don't see the point here. Please enlighten me! :)

Comments

ben kuper’s picture

ben kuper commented
Title: What exactly is the reason for having Locations attached to Nodes / Taxonomy / Directly when Fields can do that job? » Great Location CCK Module Conversion to use Entity API & Field API
Version: 7.x-4.x-dev » 7.x-3.x-dev
Category: support » task
Priority: Normal » Major

Hi,
we are discussing that on the issue : #1064666: Location CCK not saving for entities other than nodes.
What was said that the D7 version was ported straight from the D6 version which didn't have this workflow and api.

I was about to create a new issue about that, so i won't do duplicates.
Although, this is more likely a 7.x-3.x issue as many of us don't have access to the 4.x branch, and now that you have an answer, we can use that thread as a start to convert the actual cck_module into a fully field compliant module !

Shadlington’s picture

Shadlington commented

Subbing

rooby’s picture

rooby commented
Title: Great Location CCK Module Conversion to use Entity API & Field API » Merge node/user/taxonomy/cck locations to use fields API for everything
Version: 7.x-3.x-dev » 7.x-4.x-dev

Basically it is because the 7.x-3.x version is a direct port of the 6.x-3.x version so we would have a version for drupal 7 that has the functionality of drupal 6 in the fastest time possible.

Then the 7.x-4.x version is a complete rewrite to make everything fields API.

So 7.x-3.x is a direct port of the drupal 6 version with no new features (such as a rewrite for field API).

You can read my full post on this at #1064666-92: Location CCK not saving for entities other than nodes

So this is a 7.x-4.x issue.

ben kuper’s picture

ben kuper commented

Ok, no problem thanks for clearing that.
Is this already on or is it just planned ?

rooby’s picture

rooby commented

I'll make sure to put some more information on this around so everyone knows.

It is definitely planned for 7.x-4.x and bdragon has started on it but I'm not sure how far along it is at this stage.

fubhy’s picture

fubhy commented

This sounds really good. I was totaly confused when I saw that the D7 branch had direct entity attachment functionality. Its good to hear, that this is going to be removed in favor of Field API functionality. Thanks guys.

Jerome F’s picture

Jerome F commented

According to Joachim, Profile2's maintainer:

1. Profile2 relies on the user categories system provided by core -- in effect, a profile2 form is really a special type of user form. That may cause problems with things not getting triggered in FieldAPI.
2. Profile2 is built on EntityAPI module, which may have problems of its own,

Shadlington’s picture

Shadlington commented

Could you please support the Entity API module too? That'd smooth integration with other modules supporting Entity API, of which there are many. The most useful of which would be the Search API module.

paulgemini’s picture

paulgemini commented

subscribe

glottus’s picture

glottus commented

subscribe

naught101’s picture

naught101 commented

Seems like this should be a two-step process:
1. get location_cck working with core field api (and rename to location_field)
2. write a migration upgrade hook to move location_node and location_user etc. data to location_field.

Since I don't care about step 2, I definitely won't be working on it, but I might try to have a look at 1, if I get time.