Ticket #1770 (new defect)

Opened 4 years ago

Last modified 4 years ago

Midcom doens't always query the class definitions

Reported by: redtr Assigned to: bergie
Priority: major Milestone: 8.09.10 Ragnaroek
Component: MidCOM core Version: 8.09 Ragnaroek
Keywords: midcom get_parent parent Cc:


Midcom searches classes without querying the class definitions

Case: For example after get_parent is called, midcom translates the given mgd_schema to a component, from which it gets the class name, so net_nehmer_discussion_post will result in net.nehmer.discussion and it will search the class definition there, result: net_nehmer_discussion_post_dba.

The behavoir could be that the component my.fork.discussion uses the net_nehmer_discussion_post mgdschema with class definition: my_fork_discussion_post_dba, but since the mgdschema is translated, net.nehmer.discussion will be searched for class definitions and will return net_nehmer_discussion_post_dba instead my_fork_discussion_post_dba.

Only this function is used for search for possible component names: dbclassloader.php > get_component_for_class() It should also verify the class definitions from the active plugin from where get_parent is called. So it should ask for the topics component instead.

<redtr> bergie? do you know midcom cores components good?
<@bergie> redtr: sure, what is your question?
<redtr> i made a fork out of n.n.discussion and renamed the classes to the new components name. m.t.discussion, but i kept the mgd_schema name n_n_discussion_post / thread and set class definition to m_t_discussion_post _dba / thread_dba. But midcom doesn't use the class definition and translates n_n_d_post to n.n.discussion component
<@bergie> redtr: did you see how n.n.wiki does that?
<redtr> bergie: yes it extends the midcom_db_article, but the wiki always uses the constructor with an id. So that works, since you use the class itself and give it an id to fill. The same problem there will occur if you call get_parent(). it will return midcom_db_article instead n.n.wiki.wikipage
<@bergie> ah, I see
<@bergie> that is a reflector issue then I think
<@bergie> can you post a ticket on trac?
<@bergie> the heuristics there need to figure out which of the inherited DBA classes should be used
<redtr> bergie: dbclassloader.php calls get_component_for_class() which only translates the mgdschema name and doesn't search the classdefinitions
<redtr> bergie: will do
<@bergie> redtr: yep, sounds like the issue indeed

Change History

04/26/10 14:58:34 changed by redtr

Jval asked if i could add some code example,

Lets say we have a component named my.fork.discussion which is a fork from net.nehmer.discussion. Since its a fork we still use the same mgdschema.


    'mgdschema_class_name' => 'net_nehmer_discussion_post',
    'midcom_class_name' => 'my_fork_discussion_post_dba'


class my_fork_discussion_post_dba extends midcom_core_dbaobject
    ... code ... unrelated ...

We did the default stuff for the component, right now we have some records, lets say we have 2 posts, one is parent from the other post, they're stored in the mgdschema net_nehmer_discussion. We load one of the posts and ask its parent. This is another post.

/some file from the component.php

$post = new my_fork_discussion_post_dba($id);
$parent = $post->get_parent();
echo get_class($parent);

This last part of code will show: net_nehmer_discussion_post_dba and not my_fork_discussion_post_dba like we pointed to in de class definitions.

04/26/10 15:57:22 changed by jval

$classname = $_MIDCOM->dbclassloader->get_midcom_class_name_for_mgdschema_object($object);

...returns incorrect class name.

The method is located in midcom_services_dbclassloader: http://trac.midgard-project.org/browser/branches/ragnaroek/midcom/midcom.core/midcom/services/dbclassloader.php?rev=24773#L763

The actual bug here is that the following call in the method:

$component = $this->get_component_for_class($classname);

...returns incorrect component. Which in turn happens because class name is directly translated into component name without any additional logic.

04/26/10 16:03:23 changed by jval

One (perhaps hacky but working) solution would be to fetch parent until topic is found and then read the correct component value from the topic. This was redtr's idea and it should at least work.

It will be a bit slow in theory because then we need to do multiple database queries in some cases. But I'm not sure if there are other solutions unless this is fixed somehow in a way the calling side includes information about what to expect etc...