EOR and 3.9.2?

Monday 25 June 2007 1:20:47 pm

Bump.

Obviously, I am destined to remain an Object Virgin here in the land of Far, Far From Done. I'm never going to have Relations with an Object, much less exciting, Enhanced Object Relations, because there are no Object Relations Education classes at MY school, hence, my impending Object Virginity. Worse, I obviously need Enhanced Object Relations Viagra, because I can't get this to work at all.

Has ANYONE - <i>anyone at all</i> - ever gotten the Enhanced Object Relations extension/datatype to work? Is anyone here having Hot Monkey Object Relations? For that matter, would anyone like to shed light upon why enabling "AdvancedOjbectRelationList" (in either the site.ini or in the override) has no effect whatsoever upon the "Type" dropdown in this attribute? And if it DID work - what would happen, please? Would it (type) only enable the usage/creation of new nodes? And can somebody clarify the "Allowed Classes," "New Objects" and "Default Locations" functions in that attribute for me, PLEASE?

I need either Object Relations or Enhanced Object Relations to work for me, because I need it in lieu of CATEGORIES. My level of author needs simple selections - I can't let them go browsing around the backend. My only other alternative - to use multiple locations - is going to become impossible over time. SO, I would prefer to use the ease of selection by browsing pre-set (pre-created) nodes for those authors using the WebInterface - which means I need to make this work. If I can't, then this package isn't going to work for me, period. Placement by node is great for sites where the administrator places all the content, but for user-generated content, it's a whole different story.

Anyone at all out there with some insight on this? I'd appreciate,

Thanks,

Hitch

Monday 25 June 2007 6:00:47 pm

Hi, Bruce:

Before I delve into the (to me unfathomable) mysteries of EZP 3.9.2, is your blog url really supposed to be "SUFFandnonense?" Just curious.

So...onto the question at hand. I read in detail Xavier Dutoit's discussion about Enhanced Object Relations here: http://ez.no/community/forum/developer/category_sub_category_question_how_do_i_achieve_this/re_category_sub_category_question_how_do_i__4 whilst perusing the forums and documentation for a solution to my categorization issue. Very simply, I need to be able to categorize articles by more than one category, as described in Xavier's post. IOW, a user should be able to place an article in "News," and relate it as well to "Race Results" and "Jaguar" (Car types, to continue the car example), and have the article show up in all three frontpages for those nodes (News, Race Results and folder[s] for each type of car).

Where my trolley leaves the tracks seems to be in a lack of understanding on my part about the three...."fields," for lack of a better word, that make up the allowed classes, object class and default location characteristics items within the attribute. When I attempt to implement this object relations attribute (for the article class, as an example), and then try to USE the attribute in creating a new article, I can't navigate (browse) out of the SAME folder in which I have placed the bloody article in the first place. In other words, if I navigate to the "article" folder, and create a new article (this is using the webinterface bar, as my users would), when I browse, I can only "relate" the article to the objects that exist within the folder in which I started - other objects (articles) within the selfsame article folder. I can't seem to browse "up" or "across" the content hierarchy to other folders to relate items to that other folder's content. It doesn't seem to change no matter WHAT selections I make in Allowed Classes or New Objects/object class or Default Location (and this is as an admin, with rights everywhere, so it's not that). Since my ability to browse "across" the heirarchy seems to not function or alter in any fashion no matter WHAT I change in these three items, it's making me rather crazed, as there is no process of elimination to help me "get" it.

There's ZIPPO in the documentation (or in "EZ Publish Basics," which I <b>bought</b> and read, OR "EZ Publish Content Management Basics," which I <b>bought</b> and read, OR "EZ Publish Website Interface User Guide," which I downloaded and read) as to what these three aspects or choices are supposed to actually <i>do</i>, so perhaps my inferences are wrong. I have downloaded the EOR "extension" on one testbed site, and I can't get that working at all; and I've described the difficulty I'm encountering in trying to get the "basic" OR working in 3.9.2 on my other testbed site (and I haven't even started trying to display it yet!).

I <i>need</i> multiple categorization. With my user group, I can't rely on a FETCH for the tags, because that assumes that everyone spells everything the same way, and that's...well, I needn't explain THAT as problematic. I'm already struggling with figuring out what to do for a less, errrr, rudimentary INTEGRATED forum product, and how to create classifieds with the product content class. If I can't figure out how to at least get over THIS hurdle - what should be simple news article or press release or blog categorization for <b>user-contributed content</b>, my head's going to be doing the Exorcist dance very, very soon.

If you have ANY insight, I would be grateful. Please speak VERY...VERY....slowly for those of us that are not programmers, please. I know just enough to get frustrated. :-s Good with databases, though.

In any event, thanks for reading and responding, no matter what; sorry for the length of my response.

Regards,

Hitch

Monday 25 June 2007 10:45:34 pm

Hi, Bruce:

Oh, I dunno...Snuff and Nonsense? Scuff? Hmmm...Buff and Nonsense? The latter invokes all sorts of fascinating imagery. :-)

Anyway, back to the issue at hand...what you have described:

You could add an attribute to the Article Content Class - object relation for a 1-1 relationship to categories or object relations for 1-many. You would only allow that Category content classes can be related. You can select the interface for selecting the related objects (radio, checkboxes, select etc)

...is precisely what I thought I understood that Object relation(s) would do, and it's what I'm trying to get it to do on <i>either</i> testbed ("regular" OR in 3.9.2 or the "enhanced" version from XD's contribution). My problem is that I cannot get (plain, old, unenhanced) object relations to WORK. I've set up dummy folders and articles and dummy category folders and categories...but I can never seem to navigate (browse) out of the SAME article folder in which I've placed the original article and <b>I cannot figure out WHY this is happening,</b> because it seems to happen no matter what choices I make for the last three "items" as I previously described. It's maddening. In other words, using your example:

+ Articles       [Folder]   
     + Article A    [Article]   
     + Article B    [Article]  
+Categories    [Folder]
   + Category 1 [Category]
   + Category 2 [Category]
   + Category 3 [Category] 

After having implemented the object relations attribute, I then attempt (using whichever user interface) to create Article C in the Article folder. When I use the browse mechanism in the article creation template to "relate" the (category) objects, I cannot "browse" out of the Article Folder. I can't "see" or select any of the categories in the category folder, nor can I "see" the Category Folder itself. All I can "see" to select would be (using your example) Article A or Article B. Not the other folder, Categories, or its children. THAT is my problem, in a nutshell.

If you have any idea what I'm doing or selecting wrong in those last three items within the OR attribute (it has to be one of those three - <b>Allowed Classes, New Objects or Default Location</b> - nothing else makes sense), please let me know. For that matter, if anyone would like to contribute to my own knowledge base what those three selections DO, <i>precisely</i>, maybe I could figure out my own error. As I said previously, perhaps my inference (since there is NO documentation on this part of the attribute whatsoever) as to what these items mean, do or are is incorrect, and I'm simply making incorrect selections based upon that incorrect inference. ARRRGGHHH.

Thanks, Bruce...I do appreciate your input (and you'll be "Buff and Nonsense" to me for all eternity; ilea iacta est). I am glad that what I think it is supposed to do (object relations) is correct, even if I cannot seem to make it do so....yet.

Regards,

Hitch

Saturday 07 July 2007 5:28:14 pm

Hello, Xavier and Bruce:

Perhaps I will do better if I am more precise. There are four "selections," past the basics (attribute name, browse, etc.) for lack of a better word, to be made when attempting to use this Object Relations attribute. They are:

<b>"TYPE"</b> - which in my installion, has "Only existing objects" as the sole selection. The mouseover states that you can change that by enabling "AdvancedObjectRelationList" in a site.ini configuration override, but I have NOT been able to get that to work. If I don't want my users to create new objects (nodes) on the fly, does this matter?

<b>"ALLOWED CLASSES,"</b> which is a selection for a type of class (NOT nodes - content classes). The mouseover states that this "selects which classes the user can create," which I find confusing. Classes of content? That makes no sense, as the user (would be) creating a specific content class item, e.g. an article, BEFORE he/she would encounter the object relation selection. Class of related object? If the previous selection is "only existing objects," doesn't this eliminate this choice? Can anyone explain this?

<b>"NEW OBJECTS"</b> - has an object content class selection. I am so befuddled by this...having set the selection, above, to "only existing objects," isn't this also moot? Or is this somehow referring to the article content object that is BEING created? And more bogglement - text which states <b>"Placing New Objects Under "see default location,'"</b> which I don't get, as haven't we just determined that either the object being related has to already exist, OR that the object being created is being created in the location in which the user is placing it? In other words, if a user is in the process of creating an article, he/she has already done the "create here" through the webnavbar, which "places" the article in its appropriate folder and node. The object being related - let's say, for the purposes of this example, a photo album - already exists in its place. What's the point of this item, please?

AND, <b>"Default Location,"</b> which is more of the same (see above) - if we're talking about the (for the purposes of our example) "article object," it's already being "located." If we're talking about an object being both created and related as the related object...I give up.

These last four "selections" seem to all be designed for the CREATION of a new object, (say, a photo) during the creation of an object (say, an article), and the placement of that new object (photo), rather than anything to do with the object (article) being created by the user. Since the documentation is utterly silent as to the existence of these four selections, much less what on earth they DO, I can't figure out what choices to make. Moreover, Xavier, I don't see any mechanism whatsoever to "filter what objects should be on the list" for selection by the user, e.g., content folders for makes of cars. As near as I can tell, if I can ever get it to work AT ALL, the users will be free to select whatever object they want from anywhere in the node tree, within a particular content class (which is another bogglement...one problem at a time, I guess).

Lastly (sorry, I know that this is long), when I have been able to get it to work, it doesn't function properly. If my test user has navigated to, say, "Cars>Ford" folder and selected "create here" for an article, when he/she tries to use Object Relation, he/she is only allowed to try to select objects within the "Cars>Ford" folder - NOT any other folder or article or photo album or...anything. I don't know if this is a bug due to the webnavbar implementation, or just some endless circle in which I keep going around...

It's bloody irksome, I don't mind telling you. Something as simple as a work-around for multiple categories shouldn't be this brain-damaging. Everyone SAYS that OR will do this or that, but no one seems to be able to say HOW. For my own sanity, does ANYONE have this working out of the box as an in-lieu for multiple category selection? With the website interface bar 1.2? Or did it take custom code? I'd appreciate any input...

thanks in advance,
Hitch

Tuesday 17 July 2007 1:09:31 pm

Hi,

Glad to hear you made it work ;)

The fetch reverse is rather simple. As always, simplier when you know, but they are exemples on the manual.

X+

http://www.sydesy.com

Tuesday 17 July 2007 2:16:09 pm

I've struggled with OR too. It's a bit confusing, but apparently "Default Location" limits the selection (i.e. it defines the "root" node for selecting the related object(s)). Furthermore, it's quite unfortunate that Object Relation_s_ datatype does not support attribute filtering. I tried to workaround by using an enhanced attribute filter (basically PHP code generating custom SQL), but I couldn't get it to work at all (the enhanced attribute filter was not used at all - I've still got no idea why not).

My pragmatic (albeit the opposite of optimized) solution was to fetch all nodes and filter them with a custom template operator. Not got on a conceptual level, but it works.

Accessible website starting from eZ publish 3.0 (currently: 4.1.0): http://pluspunkt.at

Thursday 19 July 2007 4:26:45 am

I'm using the eZObjectRelations to (optionally) relate blog entries to author objects. So no, it's not multiple categorization because I don't allow more than one author per blog entry. I tried using the simpler eZObjectRelation (no "s") datatype, but it would not provide the same simple user interface (a drop-down list) for my content editors.

As you can imagine, for a relatively busy blog, filtering by author is a must (especially since the content search unfortunately can't index eZObjectRelations attributes). At the moment, I've got around 150 weblog objects and ca. 50 author objects. The template operator is given a NodeID (of the author object, this could of course be easily extended for multiple valid IDs) and returns the filtered node list. The code uses two loops (to ensure uniqueness), so it's not particularly optimized, but seems to work fast enough for the time being (at least with view caching).

Until the blog doubles in size, I'd guess that things will be OK performance-wise. An extended attribute filter that works directly on the XML code stored in the ezcontentobject_attribute table would be better, but I haven't been able to get the template to actually call my filter code (I didn't even get an error message).

Accessible website starting from eZ publish 3.0 (currently: 4.1.0): http://pluspunkt.at

Friday 20 July 2007 2:02:51 am

<i>Vis-a-vis the author-to-blog relation: may I ask why you didn't FETCH this? I have not yet tried this - I want to have Author pages with links to each author's content, whether it's blogs, articles, posts, whatever - (you know, "read more by this author," or somesuch) and the standard discussion here on the forums has been to use a FETCH. Did you run into problems with that? Or is it that you have anonymous user contributions, so you're using a drop down in Object Relations to provide author names? Or...??</i>

You see, the concept of "author" is completely separated from the concept of an eZ Publish "user" on the page in question (http://pluspunkt.at). There are only a few users who enter content, which may be written by someone else. For the online version of a magazin, authors are entered using the eZAuthor datatype (basically an extendable list consisting of <name, mail address> tuples) and correlated to the author objects by a simple <i>fetch</i>. However, this is rather failure-prone with regards to spelling. It's OK for magazine articles (and also can't be changed because of historical content). It also has a few beneficial side effects (a magazin article can be written by a guest author who does not have an author object).

For the blog, other things had priority status: ease of use - more people write their own blog entries (using a single "weblog_editor" account), so requiring to manually enter their name would most likely result in nicknames being entered (and of course these couldn't be correlated to the right author object). eZObjectRelations gives them a simple selection box to do the same, completely eliminating the chance for spelling variations.

Accessible website starting from eZ publish 3.0 (currently: 4.1.0): http://pluspunkt.at