XML block, links and related objects

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

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

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

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

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

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

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?

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.

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

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}