Forums / Suggestions / XML block, links and related objects

XML block, links and related objects

Author Message

Kristof Coomans

Saturday 25 March 2006 6:07:08 am

I'm wondering if it could be a good idea to let the XML block datatype make object relations for links of the type ezobject: (and maybe eznode: too, but that would have some complications because the object in a node can be swapped with another object) .

I'm currently making a wiki and it would be very ez to track orphan pages if the XML datatype had this feature.

Any plans to have this as an option (will have to be enabled with an INI setting because of backwards compatibility)?

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Gabriel Ambuehl

Saturday 25 March 2006 7:04:08 am

Personally, I was inclined to add the very feature (for similar reasons) you mention to my XHTML datatype but somehow never really had time to implement it.

Standard XML block does something along those lines: The code is very convoluted, but there is eZURLObjectLink being used at places. I think it however is used to track external links.

As for a wiki, this might be a neat addition to my own ;)

Visit http://triligon.org

Kirill Subbotin

Wednesday 29 March 2006 7:27:22 am

2Kristof:
Good idea, seems like we just missed this. My opinion is that they should be added by default, as we already have this behavior for "embed" tag. Probably we will include this to 3.8beta release.

Xavier Dutoit

Wednesday 29 March 2006 7:58:00 am

+1

Yes it makes sense, and it should have been the default behaviour (as it's done for the embed already). In fact, I was sure that was how it's done already.

General question/discussion:

When you embed something (say an image) into a ezxml field, it:
1) create a relation between this image and the current object (without attributeid in the relation)
2) add the embed tag into the ezxml field, with the proper ezobject id

The problem we all face is that you don't know if an object is related to the current one because that's a real relation or because it's embeded into an ezxml field.
( In fact, that's why I wrote this extension
http://ez.no/community/contribs/template_plugins/getobjects_extension )

That's going to be the same with the links.

What I suggest as evolution of ez:
1) when you add an embed whatever (from the online editor or the brand new xeditor that's on pubsvn) it adds the attributeid of the ezxml field (like it's done with the enhanced object relation attribute or all the object relations/list attributes).

2) On the default admin template, display all the related objects (with an info about the attribute if any) and not only the one with the attributeid not defined. We've had this discussion before when adding the attributeid field on the relation table, I think that we made a mistake by not displaying the related objects with the attributeid set.

What do you think ?

X+

http://www.sydesy.com

Gabriel Ambuehl

Wednesday 29 March 2006 8:04:33 am

Actually if you link it from the attribute to the other object (which is what the proper behavior would be anyway in my eyes), you can easily tell where the relation came from, as ezxmltext won't otherwise create relations.

It's also the only way possible to deal with relations upon changes of the ezxmltext content.

Visit http://triligon.org

Xavier Dutoit

Wednesday 29 March 2006 8:10:48 am

My point, and that's the same for the embed objects.

However, the relations to the embeded objects aren't stored with the reference of the ezxml field where they are used (that's stored as "default" related objects, without the attribute id stored).

What I'm trying to say is that we shouldn't do the same mistake for the links (ie we need to store the ezxml field attribute id in the relation), and fix the wrong behavior for the embed objects and store the attribute id.

Is that clearer ?

X+

http://www.sydesy.com

Kirill Subbotin

Wednesday 29 March 2006 8:34:54 am

Yes, using this attribute_id field is the only real way to solve this. But what about backward compatibility problems, if we, say, do this in 3.8 ? They should be solved somehow. Probably this should be enabled by a setting. Or some conversion script should be provided (although it doesn't solve all possible problems, as old behavior may be used in templates).

ps. Currently seems like there is no time to add this to 3.8.0, but 3.8.1 is the real pretender.

Xavier Dutoit

Wednesday 29 March 2006 9:03:54 am

Hi,

Breaking backward compatibility ?

Ok, the feature suggested by Kristoff is new, nothing to break here if that's done the right way (attribute id set) since the start, right ?

As for the embeded objects, it would be a problem for people that use the reverse related objects to list the images embedded into the field and mixed with the regular related objects.

From what I read in the forums, people try to avoid the confusion between real related objects and related images added to embed them into an ezxml field.

In fact, I can't imagine any scenario where you'd want this confusion.

Do you have an example ?

X+

http://www.sydesy.com

Xavier Dutoit

Wednesday 29 March 2006 9:04:49 am

Gabriel, what about xeditor ?

Wouldn't it make sense to do it and store the attribute id when creating the relation ?

X+

http://www.sydesy.com

Gabriel Ambuehl

Wednesday 29 March 2006 12:29:16 pm

Sure. I had already plans to do that.

I agree that I don't see much sense in using regular object level related objects,...

Visit http://triligon.org

Kristof Coomans

Wednesday 29 March 2006 11:30:08 pm

When the object relations on attribute level were introduced (don't know anymore in which version that was), we had to update some of our templates too because this change actually wasn't fully backward compatible. The related_contentobject_array attribute of ezcontentobject suddenly returned only related objects on object level. The reverse_related_contentobject_array attribute first did the same, but this behavior has been changed recently ( http://ez.no/community/bugs/reverserelatedobjectlist_attributeid_0 ). Now these two attributes behave differently by default. Quite confusing if you ask me.

Of course we have to avoid any confusion and therefor I agree that there should be an INI setting to turn on the new behavior for object relations made by the XML block datatype.

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Xavier Dutoit

Wednesday 29 March 2006 11:49:33 pm

Hi,

For those of you interrested in archeology, Kirill details in this thread the reasons of the actual behavior.

http://ez.no/community/forum/general/object_relations/(offset)/20#msg82152

X+

http://www.sydesy.com

Kirill Subbotin

Thursday 30 March 2006 12:00:41 am

2Kristof Coomans:
Very strange bug and a strange fix. This is bad if that arrays behave differently now... I think that "fix" should be reverted.

And seems like you are not right about that array too. related_contentobject_array always returned only objects related on object level only, as it was an old behavior kept for compatibility.. Its more like that bugfix is wrong..

Kirill Subbotin

Thursday 30 March 2006 12:35:45 am

By the way... just thinking... Now many users have a problem to separate real object relations made on object level from relations made with embedded pictures.

Lets say we have implemented a feature to use attributeID of the XML attribute to store such relations. And we store both relations made with <link> and <embed> tags. Would not this be a problem again, as there is no possibility to distinguish between relations made with links and pictures?

Kristof Coomans

Thursday 30 March 2006 1:24:35 am

I's been a while ago, so I don't remember exactly what whas going wrong. We were probably using a community datatype that made object relations, like the enhanced object relation (problems mentioned by Xavier in the other forum thread).

The fix should be reverted indeed if the attribute always returned object relations only on object level.

But that's the past and I think we need to focus on the future :) So back on topic:

Maybe the XML block datatype's content can have a list with all it's relations and their types (link, embed), in case you need it.

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Kirill Subbotin

Thursday 30 March 2006 1:36:32 am

hm... XML block datatype's content already have this information inside itself. The question is what to store in a table (to make it possible to fetch reverse relations).

PS. That bugfix is already reverted in all branches. Unfortunately latest 3.5, 3.6, 3.7 releases have this wrong bugfix.

Kristof Coomans

Thursday 30 March 2006 2:11:45 am

Is it really useful to have the possibiliy to fetch reverse relations based on it's type (embed, link) in an XML block?

I just meant to have the possibility to get a nice list of relations inside an XML block attribute, like the getobjects extension currently allows for embeds, but then for links too.

eg.
{$attribute.content.relations} for a full list of relations with their type
and {$attribute.content.embed_relations} for relations made with embed
and {$attribute.content.link_relations} for relations made with link
...

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Xavier Dutoit

Thursday 30 March 2006 2:31:57 am

"Is it really useful to have the possibiliy to fetch reverse relations based on it's type (embed, link) in an XML block?"

I don't see any need myself.

eg.
{$attribute.content.relations} for a full list of relations with their type
and {$attribute.content.embed_relations} for relations made with embed
and {$attribute.content.link_relations} for relations made with link

I like the idea... and look forward to obsolete getobjects as it replaces it nicely !

X+

http://www.sydesy.com

Kristof Coomans

Tuesday 03 October 2006 12:18:02 am

It seems like this has been implemented on the trunk:
http://pubsvn.ez.no/nextgen/trunk/doc/features/3.9/xml_related_objects.txt

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Kirill Subbotin

Tuesday 03 October 2006 9:08:19 am

Yes, this has been implemented in trunk recently, although not fully finished yet.

Here is the latest version of the doc. Your impressions and opinions are welcome!

*Title: Improvements to related objects added from XML block text field.

*Documentation:

There are 4 types of relations between objects in the system:

- 'Common'. Relations of common type are created when user adds related
objects manually.

- 'XML linked'. Relations of this type are added automatically when you
save object containing XML fields with <link> tags referencing objects or nodes
(ex: <link href='ezobject://123>... ). Note that when you remove <link> tag
and store object, the corresponding relation will be automatically removed.

- 'XML embedded'. Relations of this type are added automatically when you save
object containing XML fields with <embed> tags embedding objects or nodes.
Note that when you remove <embed> tag and store object, the corresponding
relation will be automatically removed.

- 'by Attribute'. Relations made by attributes of "Object relation" and
"Object relation list" datatypes.


*Template fetch functions:

The following fetch functions have been modified: related_objects,
related_objects_count, reverse_related_objects, reverse_related_objects_count.

Parameter 'all_relations' now has mixed type. It could be boolean true/false
like it was in 3.8, but it can be also an array. Array may consists of the
following strings: 'common', 'xml_link', 'xml_embed', 'attribute'. Each of
them mean corresponding relation type. Types can be mixed and placed in any
order. Also this new parameter is fully compatible with other options.

Also the following functional attributes has been added to ezcontentobject
class:

linked_contentobject_array
embedded_contentobject_array
reverse_embedded_contentobject_array
reverse_linked_contentobject_array

They act like corresponding fetch functions return all related or reverse-related
objects of a specific type.

*Examples:

Both examples return array of objects "linked" to the object $my_object.

{def $linked = fetch( 'content', 'related_objects', hash( 'object_id', $my_object.id, 'all_relations', array( 'xml_link' ) ) )}
                                                        
{def $linked = $my_object.linked_contentobject_array}