Concrete5: Uniqueness of express entity attribute handles

[a3020]

Reproduce:

• Create two Express Objects: Product and Review
• Add an attribute called "Name" to both objects

The attribute handle names have to be unique. I suspect this will lead to problems soon. It basically means that right now, everything needs to be prefixed by the user (e.g. product_name, review_name).

Prefixes are not ideal, because the Express Object handle may change in the future. A possible solution could be to save the Express Object ID in the AttributeKeys table, just like we do with the akCategoryID.

[ahukkanen]

Yes! I actually thought this was just an oversight about to be fixed in the early versions (when I played with this the last time). A bit surprised to hear this is still an issue.

[cryophallion]

Hmmm. I have to be honest, looking at it from the approach of how packages deal with data, I'm not sure this will be flexible for package developers.

Currently, for example, topics can be named whatever. What this means is that when I am developing a package, and I name a topic tree and then call back for it in the package, I can't be assured I am getting the one I actually want (there is no getByHandle for topics, for example).

So again, when initiating code in a package that may use express, we need to be able to ensure that we can get that entity even without knowing what the id is on that particular system (for one system, it will be entity 23, on another it will be 28). So, let's say I go in and initialize an entity, and then I need to go edit it in an upgrade. If I search by the entity name "name", then I could get the name property for some other item! And the only other option is recursively looking down the entity chain, having to find something that looks like a name on this entity and... it becomes unworkable very quickly.

Taking it back to the original point, "the handle may have to change". Ummm, why? Yes, if something is renamed it's really nice for the handle to be renamed. But the end user doesn't see this, honestly. That changes with the Name property here. So even if something was handled "item_name" and you renamed the name to "Product Name" from "Item Name", the world can still exist.

I think the handle HAS to be able to be unique (which is a major issue I have with topics programmatically, it's a pain, and while I have a note that I'd love to code out a handle for topics, I don't know a good way to do it for existing topics). And I think it has to be able to be relied on.
Now, to be fair, of course customers could come in here and screw everything up if they have too great of permissions and they could change a handle. But I really, really, really feel like this needs to be cleanly and easily accessible by people coding packages, because that is how upgrades SHOULD be handled in a proper fashion. The way it is described here, removing handles will remove an annoyance, but remove flexibility and usability for the people who are creating extensions. I would be thrilled to be wrong, and have someone tell me an "easy" way to work around this. But there is a reason the boilerplate content most people have consists of "getByHandle", not "getByID". ID can change from install to install. Handle should be more reliable. Something needs to be reliable and unique. Or else the only way to change something is to go in and do every site by hand.

[mlocati]

I'd vote for not forcing global uniqueness of attribute handles.

This could simply be resolved with an approach like this:

• express objects must have an unique handle (eg product, customer, ...)
• attribute objects must have a handle that's unique *_only within its parent object`_
• to get an attribute object, we should force to specify both the object and the container handles (ideally something like getExpressAttributeByHandle($parentHandle, $attributeHandle).

This would simplify attribute handles naming a lot, and could help greatly reducing clashes between attributes defined by different packages

[cryophallion]

That works. It's an extra step/method but that seems a feasible solution.