Forums / Developer / Adding _new attributes_ to _existing objects_ (like in 3.0.2-1)?

Adding _new attributes_ to _existing objects_ (like in 3.0.2-1)?

Author Message

Sven Ryen

Friday 04 July 2003 12:26:33 pm

In 3.0.1-2, it was possible to modify classes after you have started creating objects. The objects would be updated to reflect your changes. Attributes that were deleted from a class would be dropped, and new attributes would be added.

This seems to be gone in 3.1-1. When I modify my classes, I have to delete existing nodes/objects and recreate them in order to get access to the new attributes.

Is this a bug or a feature? I preferred the way this was implemented in 3.0.2-1, as it allowed for attributes to be added to classes after some objects had already been created.

Sven Ryen

Friday 04 July 2003 12:52:45 pm

.. not even new objects that are created _after_ the class has been modified gain access to the new attributes. New objects also use the old ones!

I can tell for sure that my class now contains an xml data text datatype. However, when editing or creating new objects, I still get the old attribute, a simple text field.

Any ideas?

Sven Ryen

Friday 04 July 2003 1:21:07 pm

There's definitely something peculiar going on here..

To me it seems like the EZ Developers have made an attempt at adding versioning to class data (at least I'm seeing versions 0 and 1 stored for the classes I've edited with 3.1-1. Oddly enough, I never get a version 2, just 0 and 1, no matter how many revisions I perform om my classes).

The /content/edit module does not seem to have caught up with this change, and is still using the version 0 attributes for editing, both for old and new objects.

If your intention by this change in behavior is to make sure old objects stay intact, thus enforcing the original attributes no matter how many changes we make to the classes, you should at the very least display a warning, or lock up the classes to prevent editing once an object has been created.

It's frustrating to make a change, and not having it applied, you know..

I really hope this bug will be fixed in a maintenance release of 3.1, so that I won't have to wait until 3.2 for this to work properly. Of course, if anybody sees a qucik fix, feel free to post code modifications for solving the bug.

Paul Borgermans

Friday 04 July 2003 1:30:09 pm

Sven,

I cannot reproduce this here. Additional fields do show up. Did you press the "Store" button when changing your class? It may otherwise still be a draft.

--paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Sven Ryen

Saturday 05 July 2003 1:17:03 am

Paul.

Perhaps the interface is to blame?

There is absolutely no visual indication anywhere that I'm editing a draft, and I'm never alerted that my changes will not be kept if I don't press "Store" or "Apply".

Furthermore, I'm fooled by the feedback message saying "Your input was stored successfully". I mistakenly assumed that message to mean "Your input has been stored, just as if you clicked the Store button". A better wording would be (if I understand the behavior of class editing correctly) "Your changes has been saved in the Draft of this Class. To store your changes, click the Store button".

EZ Publish also seems to keep my Draft, and _reopen_ the same Draft when I later click the pencil button to edit the Class. This further confuses the user by giving the impression that his changes has indeed been saved.

Better solutions would be to either
- discard the old Draft when the pencil was clicked.
- display some icon (or an asterix) next to the class to indicate that the last Draft has not been stored
- display a proper message when the Draft of a Class is opened for editing, so that the user knows he has opened a Draft.

Any other suggestions? How can the EZ team make the behavior clearer? Am I just a "stupid user" who should keep his hands away from editing and leave this to somebody else?

Please share your opinions.

Bård Farstad

Saturday 05 July 2003 4:30:28 am

Sven, the interface is to blame here. The problem is that "apply" is really store draft. The purpose of this button is mostly as a tool during development of new datatypes.

We should definetly make this clearer to the user.

The only button which really changes the class setup is "Store", all other actions are temporary.

--bård

Documentation: http://ez.no/doc