Editing a limited set of object's attributes

Thursday 27 December 2007 4:04:48 am

I've observed apparently different behaviors of eZ Publish when editing a subset of object's attributes:
a) new version of an object is created out of new values of the attributes being edited + previous version of all other attributes
b) new version of an object is created out of new values of the attributes being edited + empty values of other attributes, no matter what the previous versions were.

My questions:
1) What's the desired, default way that eZ Publish should handle such editing?
2) Should one the above behaviors be considered a bug or maybe an illegal operation on the content model?
3) Is there a configuration setting for controlling/switching the above?

I'd be grateful for any help on that subject,
Piotrek

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Wednesday 16 January 2008 12:28:28 pm

Hello Maxime,

I can't actually believe that this issue has drawn attention eventually ;)

Yes, in what you're saying might be the thing behind single attribute edit - it seems to me that it's encouraged to concentrate on content objects as smallest editable entities, because of version control as well as other issues. From that perspective, what you're describing as an issue, I would call following the model. I may not like the idea that I've only edited one character and eZ produces another db load of data, but it seems like a good idea when looking from the perspective of an object.

There's another way - that is direct data modification in existing objects and their attributes. I've recently written few extensions that rely on this approach. For example, an object view counter that stores view counts in its custom DB table, but periodically synchronizes (cronjob) an integer of my choice within last version of objects of given class, so that later I can sort and filter the objects based on their dynamically changing popularity or whatever. This obviously breaks the model, there's no version created in between synchronizations. Is that a wrong approach, though? I'd be grateful for pros and cons.

My latest tests have shown, that for majority of basic datatypes it is possible to skip attributes (the earlier problems with attributes being wiped out must have been datatype-related, I think). Is that desired, is that a feature or a bug - don't know yet ;)

Greetings,
Piotrek

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Monday 02 June 2008 1:13:54 am

I agree with the other comments, it all depends on the data you need to change without affecting the version, but without versioning there could be some pitfalls.

I have my own extension that allows editing selected attributes of the current version without affecting the version, that allows me to change the status of an object attribute without entering /content/edit. I have been using this for a number of content classes that usually have only one modifier or owner. This is handy if you are trying to give certain users the ability to modify their own content quickly and without slowing them down by forcing them to create a new version every time they need to change attribute_a value from 1 to 0 or visa versa.

I do however limit the use to one user if I can help it, if you're talking about allowing multiple users to manipulate one attribute you could run into issues where 2 people are editing the same object at the same time which will either cause an error on publish or wipe out the change made to the single attribute by one of the users by forcing it back a version.

I'm currently setting up a ticket system that enables admin's to change the status of a ticket in one click (open/closed), so this will be a good field test of the single attribute edit extension. My guess is that there will be the odd occasion where 2 people will try to change the same attribute of the same object at the same time. I'm yet to figure out a way to circumvent this exact scenario short of using full blown versioning? All of that said I am currently running this ability on a production site and so far (3 years) I haven't encountered an issue though I have limited its use to the owner of the object so its practically impossible to have 2 people editing it at the same time.

Once I have figured out the best way to allow multiple users to edit synchronously (with and without AJAX) I'll release the extension to public, but first I want to make sure its 100% stable and reliable.

As for your issue I'd say it really is a matter of the content that you need to edit and weigh up the likelihood of multiple users editing synchronously, if that's very low allow it if its high you might be better off forcing full version editing?

I hope that helps, probably not exatly what you were after though?

Cheers
Nathan.

Pardon me while I burst into flames...