Object Relations

Wednesday 24 August 2005 6:56:32 am

I'm coming to think this is probably some sort of a bug. Or maybe it's intentional but in any case, different behavior would probably be better.

I'll try to figure out what to do when I get the time. In the mean time if someone feels like writing a bug report, do so.

Visit http://triligon.org

Wednesday 24 August 2005 9:06:18 am

Xavier,

Before trying

{def $objects=fetch( content, reverse_related_objects, hash( object_id, $node.contentobject_id, attribute_identifier, 'books/authors' ) )}

I changed kernel/classes/ezcontentobject.php as you said. I assumed this was necessary before I tried the fetch function. Did I assume wrong?

Anyways, after I changed the file and cleared the chaches, I erased some relations created before this kernel change, and then created new relations. For my susprise, when I go to the admin page for either books or authors, I still get:
//Relations [0]
//Related objects [0]
//The item being viewed does not make use of any other objects.
//Reverse related objects [0]
//The item being viewed is not in use by any other objects.

So, what change of behaviour should I have looked for, after changing the kernel file?

thanks you all for the efforts so far!
Roberto

PS: I tried the suggested function
(Note: Authors [Enhanced Object relation] (id:227))

        {def $objects=fetch( content, reverse_related_objects, hash( object_id, $node.contentobject_id, attribute_identifier, 227 ) )}
            {foreach $objects as $object}
                 {$object.object.name}<BR />
            {/foreach}
        {undef $objects}

but to no avail...

Thursday 25 August 2005 7:53:22 am

Xavier (and all)

The fetch reverse_related_objects (+attribute parameter) <i>is working!</i> I actually made a mistake using it. It seems though that this fetch function doesn't have a "sort_order" parameter, so I am working to make the books appear in alphabetical order. I'm almost there, but if anyone knows of a good solution for this, (ie, a simple way to sort the output of fetch reverse_related_objects) please let me know.

As to
"1) the patch was supposed to let you get your reverse_related_contentobject_array properly filed"
I still don't see the effects of applying the patch as when I look a either books or authors in the admin interface, I get
//Relations [0]
//Related objects [0]
//The item being viewed does not make use of any other objects.
//Reverse related objects [0]
//The item being viewed is not in use by any other objects.

But then, this doesn't matter too much, as the problem itself is solved (showing the books by an author). I thank you guys so much for your time and patience and I learned a lot with you.

Thursday 25 August 2005 10:36:23 am

As for why the fetch doesn't have a sort_order: a relation is, at the bottom of it, really nothing more than the ID the object is pointing to. So making sort_order work is somewhat complicated as you don't know just what sort of object you'll be dealing with in advance (tho sorting by the usual suspects should still be possible).

You might want to submit this as improvement suggestion to ez if you don't want to hack the kernel yourself.

Visit http://triligon.org

Friday 26 August 2005 6:08:50 am

Hello,

I had the same problem yesterday but I did not find the solution.

Please Roberto, could you post the code of the fetch that did it ?

Is it necessary to change the code like Xavier tell us or not ?

Xavier are you french ? If you speak french are you on the frence communauty too of ez ?

Is this extrension ok if the site have more than 1 000 categories used to make relations with article, news, products ? Is ez powerful enough for taht kind of use ?

Thanks...

Friday 26 August 2005 4:00:41 pm

I can tell you WHY it happens:

SELECT
                                               count( ezcontentobject_link.from_contentobject_id ) as count
                                             FROM
                                               ezcontentobject,
                                               ezcontentobject_link
                                             WHERE
                                               ezcontentobject.id=ezcontentobject_link.to_contentobject_id AND
                                               ezcontentobject.status=1 AND
                                               ezcontentobject_link.from_contentobject_id='141' AND
                                               ezcontentobject_link.from_contentobject_version='1' AND
                           contentclassattribute_id=0

and similarly

SELECT count( DISTINCT ezcontentobject.id ) AS count
                                             FROM
                                               ezcontentobject, ezcontentobject_link
                                             WHERE
                                               ezcontentobject.id=ezcontentobject_link.from_contentobject_id AND
                                               ezcontentobject.status=1 AND
                                               ezcontentobject_link.to_contentobject_id=141 AND
                                               ezcontentobject_link.from_contentobject_version=ezcontentobject.current_version AND
                           ezcontentobject_link.contentclassattribute_id=0

Look at the last line of each query. Personally, I don't think it should be there, at all! Each object that points to some other object should list that fact, no matter if it's on the object or the attribute fact!

Visit http://triligon.org

Monday 29 August 2005 6:12:19 am

Hello,

There really seems to be nothing wrong with the fetch function. But I agree that there must be a bug as to why don't the relations show in the admin GUI?

For the records and for those who have the same needs as I do, here's what I've done so far:

I have an override template for the AUTHORS class, which shows the Author's Name, Birth and Death dates, his Biography, and then Links to his available books. Books are in another class, "book", and here's what I did in order to show the books, alphabetically ordered:

        {def $sAutorId=$node.object.id}

        {* GETTING THIS AUTHOR'S BOOKS *}
        {* Note: Authors [Enhanced Object relation] (id:227) *}
        {def $books=fetch( content,
                           reverse_related_objects,
                           hash( object_id, $node.contentobject_id,
                                 attribute_identifier, 227
                                )
                          )
        }


        {* BUILDING AN ARRAY WITH OBJECT_IDs AND BOOKS' TITLES *}
        {def $japassou=0}
        {def $name='?'}
        {def $nodeid=0}
        {foreach $books as $thisbook}
          {set $name=$thisbook.name}
          {set $nodeid=$thisbook.id}
          {if eq($japassou,0)}
            {set $japassou=1}
            {* 1ST TIME: def ARRAY $lista *}
            {def $lista=array($nodeid,$name)}
          {else}
            {* N-th TIME: SET/APPEND TO ARRAY $lista *}
            {set $lista=$lista|append($nodeid,$name)}
          {/if}
        {/foreach}
        {undef $books, $thisbook, $name, $nodeid, $japassou}

        {* ORDERING OBJECTS/TITLES ARRAY BY TITLE*}
        {* "sort" operator returns this kind of array: *}
        {* Array ( [0]=> 6 [1] => 112 [2] => Casa Velha [3] => 111 [4] => Memórias Póstumas de Brás Cubas [5] => 130 [6] => Sempre não ) *}
        {* i.e., an array(objectid, title, objectid, title...) titles already alphabetically ordered, first cell= sizeof array *}
        {set lista = $lista|sort}

        {* SWEEPING THE ARRAY AND BUILDING THE HREF LINKS *}
        {* Note: $lista.0 contains the size of the array *}
        {def $sizeoflista=$lista.0}
        {def $i=1}
        {def $j=1}
        {def $titulo=''}
        {while lt($i,$sizeoflista)}
          {* WE NEED THE OBJECT'S NODE_ID, NOT ITS OBJECT_IDs, SO... LET'S GET IT *}
          {def $object=fetch( 'content', 'object', hash( 'object_id', $lista[$i] ) )}
          {def $nodeid=$object.main_node_id}
          {undef $object}
          {set $j=inc($i)}
          {set $titulo=$lista[$j]|wash}
           <a href={concat('/content/view/full/',$nodeid)|ezurl}>{$titulo}</a><BR />
          {undef $object, $nodeid, $titulo}
          {set $i=sum($i,2)}
        {/while}

        {undef}

And here is the sort function, which I put in index.php:

function my_sort($array) {
  $i=0;
  while ($i<sizeof($array)) {
    $j=$i+1;
    $node=$array[$i];
    $nome=$array[$j];
    $newarray["$node"]=$nome;
    $i=$i+2;
  }
  asort($newarray);
  reset($newarray);
  $lista="";
  while (list ($key, $val) = each ($newarray) ) {
    if ($lista<>"") {
      $lista.="ÿ";
    }
    $lista.=$key."ÿ".$val;
  }
  $newarray=explode("ÿ",$lista);

  array_unshift($newarray, sizeof($newarray)); // puts sizeof $newarray into it's 1st cell

  return $newarray;
}

I hope this helps. If anyone could do all this in a more ellegant way, please share!

Roberto

Tuesday 30 August 2005 3:05:20 am

2 Roberto:

If you want all relations to be displayed in admin interface and returned by 'related_contentobject_array' now you can do a simple hack:

In /kernel/classes/ezcontentobject.php find the function 'relatedContentObjectArray' for related or 'reverseRelatedObjectList' for reverse-related objects and just remove the line "contentclassattribute_id=$attributeID" from SQL query.

Tuesday 30 August 2005 4:35:44 am

I fully agree with Xavier here. It did in FACT return everything (simply because it didn't know about the attribute_id stuff Xavier had added way back when enhancedobjectrelation was first implemented).

So in essence, you didn't preserve backward compatibility with this (at least not in all ways).

I still think that the admin interface should display them all (for reasons pointed out above, it did so in the past) as it's rather confusing for people not to see the relations.

In order to keep the API as it is, why not simply interprete negative ints passed to the attribute_identifier parameter as a wildcard to return EVERYTHING? If adding a boolean for "return_all" is possible, that would be much preferred of course.

OTOH, a new function to deal with this things wouldn't be all bad either as then it could return a array of the following format:

$reverse_related_object=array();
$reverse_related_object['contentobject_level']=array(/*all non attribute specific relations/*)
$reverse_related_object['attribute_identifier#1']=array(/*all  attribute specific relations for attribute_identifier#1/*)
$reverse_related_object['attribute_identifier#2']=array(/*all  attribute specific relations for attribute_identifier#2/*)

Or maybe, providing the same info but in a different structure:

$reverse_related_object=array();
$reverse_related_object[]=array("attribute_idenfier",  $related_object)

Am I making sense?

And while we're at it, the analog functionality for "forward" relations could potentially be quite handy, too.

Visit http://triligon.org

Tuesday 30 August 2005 5:09:01 am

2 Gabriel:

You first structure type makes sense. Also I think we need additional parameter to enable this advanced structure. And of course this feature should be added to both reverse and straight functions.
And also.. should we use attribute_identifier or attribute_id in the returned array ?