ezobjectrelationlist new objects

Next topic

Author	Message
Benjamin Choquet	Wednesday 06 July 2011 2:11:47 am Hi, i'm puzzled by what I think is a forgotten feature and would like to know more about it and get some feedback on why and on what's planned. First, what I found out I discovered the datatype ezobjectrelationlist can allow to create new objects while editing the main one, but not in browse mode. Current implementation only lets you enter a name and creates an empty object when you save the main one. You have then to manually browse to your new object and the edit it. A different behavior was formerly used for browse mode. it has been deprecated around version 3.5 but can be turned on with a backward compatibility setting (AdvancedObjectRelationList). You could then allow inline edition and creation, that is having an object editing form within your main editing form. And now for my thoughts : object relations are no lesser part of eZPublish strongest point : its data model. They allow content reuse and better indexing. We, at Heliopsis, particularly use ezobjectrelationlist datatypes to link images to content, in browse mode. The weak part is that a webmaster has to create his images in the media section before editing content which is quite poor user experience. Unfortunately, both the existing approaches to related object creation have their drawbacks and result in poor UX too : Creating an empty object you have to edit later does not dramatically change the process and, I guess, tend to result in many useless objects when used by unrigourous webmasters Inline editing BC mode is not very user friendly, buggy when using JS features like ezie and according to site.ini's comments creates nodeless objects A better UX would IMHO use the following process (say an article related to images) : Edit article Edit some attributes Click on "Create new image" button Get to a full image editing form Save new image Get redirected to article form, new image being related Edit some more attributes Save article Questions I'm sure there was a reason deprecating object creation in browse mode, can anybody explain it ? Are there plans to change that datatype's behavior at eZ's or wherever else ? What would be the pitfalls of my proposed process ? Am I missing something ? Thanks for your help.
Damien Pobel	Thursday 07 July 2011 12:23:44 am Hi Benjamin, that's a very interesting topic that came lately (last week) in the engineering team discussion... I'll try to answer to questions. " I'm sure there was a reason deprecating object creation in browse mode, can anybody explain it ? " I'm not sure what is the exact reason, it's probably a mix between UX issues (like you mentionned) and some buggy behaviour that are/were probably difficult to handle. " Are there plans to change that datatype's behavior at eZ's or wherever else ? " Unfortunately, I'm not able to answer to this question... What I'm sure, is that we're not going to work on this in the next month, so if you don't know what to do at the beach, don't hesitate ;-) Seriously, if you're really interested in working on this topic and given the size of what has to be done, I'd suggest you to send your ideas to sdk-public@lists.ez.no so that it can be discussed in details before spending time on code or I would be happy to welcome a new developer in the admin2pp team ;-) " What would be the pitfalls of my proposed process ? " I think that could work, the biggest issue would be to fill the object relation list with newly created object, but that's far from being impossible ;-) When I think about this feature, it would be also possible to create the related object in a kind of lightbox (in AJAX obviously) and if the object you want to create also has an objectrelation attribute with the same behaviour you can just stack a new lightbox with the required form. I know, this is a bit more complicated than what you propose, but also a bit sexier ;-) And I also think that would require very few changes (or perhaps no changes) in the existing code ! Cheers Damien Planet eZ Publish.fr : http://www.planet-ezpublish.fr Certification : http://auth.ez.no/certification/verify/372448 Publications about eZ Publish : http://pwet.fr/tags/keywords/weblog/ez_publish
Benjamin Choquet	Thursday 07 July 2011 1:29:28 am Hi Damien, thanks for your answer. I'm definitely willing to work on this though my summer schedule is pretty busy. The lightbox idea is good indeed (even better UX) but I'm not sure about stacking them for it could become messy. I was thinking about using a custom action but I guess it can be done with a js server call. I'm not very familiar with the admin JS API, can you tell me where I should look ? Is there such an API for lightboxes or is it managed by each feature ? BTW, is there any policy regarding JSless fallbacks in admin interface ?

Author

Message

Wednesday 06 July 2011 2:11:47 am

Hi,

i'm puzzled by what I think is a forgotten feature and would like to know more about it and get some feedback on why and on what's planned.

First, what I found out

I discovered the datatype ezobjectrelationlist can allow to create new objects while editing the main one, but not in browse mode. Current implementation only lets you enter a name and creates an empty object when you save the main one. You have then to manually browse to your new object and the edit it.

A different behavior was formerly used for browse mode. it has been deprecated around version 3.5 but can be turned on with a backward compatibility setting (AdvancedObjectRelationList). You could then allow inline edition and creation, that is having an object editing form within your main editing form.

And now for my thoughts :

object relations are no lesser part of eZPublish strongest point : its data model. They allow content reuse and better indexing. We, at Heliopsis, particularly use ezobjectrelationlist datatypes to link images to content, in browse mode.

The weak part is that a webmaster has to create his images in the media section before editing content which is quite poor user experience.

Unfortunately, both the existing approaches to related object creation have their drawbacks and result in poor UX too :

Creating an empty object you have to edit later does not dramatically change the process and, I guess, tend to result in many useless objects when used by unrigourous webmasters
Inline editing BC mode is not very user friendly, buggy when using JS features like ezie and according to site.ini's comments creates nodeless objects

A better UX would IMHO use the following process (say an article related to images) :

Edit article
Edit some attributes
Click on "Create new image" button
Get to a full image editing form
Save new image
Get redirected to article form, new image being related
Edit some more attributes
Save article

Questions

I'm sure there was a reason deprecating object creation in browse mode, can anybody explain it ?

Are there plans to change that datatype's behavior at eZ's or wherever else ?

What would be the pitfalls of my proposed process ?

Am I missing something ?

Thanks for your help.

Damien Pobel

Thursday 07 July 2011 12:23:44 am

Hi Benjamin,

that's a very interesting topic that came lately (last week) in the engineering team discussion... I'll try to answer to questions.

I'm sure there was a reason deprecating object creation in browse mode, can anybody explain it ?

I'm not sure what is the exact reason, it's probably a mix between UX issues (like you mentionned) and some buggy behaviour that are/were probably difficult to handle.

Are there plans to change that datatype's behavior at eZ's or wherever else ?

Unfortunately, I'm not able to answer to this question... What I'm sure, is that we're not going to work on this in the next month, so if you don't know what to do at the beach, don't hesitate ;-) Seriously, if you're really interested in working on this topic and given the size of what has to be done, I'd suggest you to send your ideas to sdk-public@lists.ez.no so that it can be discussed in details before spending time on code or I would be happy to welcome a new developer in the admin2pp team ;-)

What would be the pitfalls of my proposed process ?

I think that could work, the biggest issue would be to fill the object relation list with newly created object, but that's far from being impossible ;-)

When I think about this feature, it would be also possible to create the related object in a kind of lightbox (in AJAX obviously) and if the object you want to create also has an objectrelation attribute with the same behaviour you can just stack a new lightbox with the required form. I know, this is a bit more complicated than what you propose, but also a bit sexier ;-) And I also think that would require very few changes (or perhaps no changes) in the existing code !

Cheers

Damien
Planet eZ Publish.fr : http://www.planet-ezpublish.fr
Certification : http://auth.ez.no/certification/verify/372448
Publications about eZ Publish : http://pwet.fr/tags/keywords/weblog/ez_publish

Benjamin Choquet

Thursday 07 July 2011 1:29:28 am

Hi Damien,

thanks for your answer. I'm definitely willing to work on this though my summer schedule is pretty busy.

The lightbox idea is good indeed (even better UX) but I'm not sure about stacking them for it could become messy. I was thinking about using a custom action but I guess it can be done with a js server call.

I'm not very familiar with the admin JS API, can you tell me where I should look ? Is there such an API for lightboxes or is it managed by each feature ?

BTW, is there any policy regarding JSless fallbacks in admin interface ?