This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Forums » Setup & design » Grouping classes and enabling lists...

Grouping classes and enabling lists of objects

Grouping classes and enabling lists of objects

Tuesday 15 November 2011 10:58:35 pm - 5 replies

I'm building a basic CMS as a test for our larger project and I'm running into some road blocks getting things going.

For this test, writers need to be able to create a recipe.  The recipe needs a title, description, picture, and a list of ingredients.  Each ingredient consists of three attributes: An enum type (cups, tbsp, etc), a numeric count, and a text line name.

I'm running into two issues:

1) What is the best way to group the three elements of the ingredient object so they are always added to a recipe as a group?

2) How do I enable the writer to add as many ingredient objects to a recipe as they need dynamically?

Tuesday 15 November 2011 11:19:40 pm

Hello Ian,

Welcome to the eZ Community!

I'm not certain the best answer here but did want to point out one important key here.


The eZ Publish 'enum' datatype has been deprecated for a very very long time,


So you really really do not want to use this datatype in your solution.

A recommended replacement for past 'enum' usage is the 'selection' datatype,


Although for more complicated use cases like your recipe class you might consider if the 'matrix' datatype serves your needs more completely,


Re: #1 - I'm not certain the best way to accomplish this requirement. Can you explain it in greater detail?


Re: #2 You might want to think about creating a separate 'ingredient' class and use an 'object relations' datatype attribute in your 'recipe' class. This will allow you to add unlimited 'ingredient objects' to your 'recipe'.


I hope this helps ...




Wednesday 16 November 2011 12:04:45 am

Thank you for your quick reply!

You're totally right about the enum.  I'll stick to the Selection class.

I've reconstructed my recipe example and I think I have the answer to #1 based on what you said for #2: Create a single ingredient class with the attributes described above.

Now that I have a Recipe class with an Object Relations attribute that points to my Ingredients class, I see that the Object Creation page for new Recipes wants to link to existing objects.  Is there any way to have it create the linked objects inline?

For example, here's a mockup of a Recipe being created with the ability to add multiple Ingredients inline:

Modified on Wednesday 16 November 2011 12:05:44 am by Ian Maddox

Wednesday 16 November 2011 1:18:15 am

Digging further into the Object Relations datatype, I see that it *should* allow inline creation of related objects. However, the documentation seems to be referring to features that don't exist:

In addition to allowing relations to existing objects, this datatype makes it possible to create new objects and automatically relate them to the one that is being edited. Note that this currently works with all selection methods except the "Browse" method. In order to use this feature, you need to specify which type of object that should be created and where the newly created objects should be placed. This can be done by making use of the "Object class" dropdown list in the "New objects" section and the "Default location" section. If the "Object class" dropdown is set to "none", it will not be possible to create new objects from within the object edit interface.

The bolded sections refer to an "Object class" dropdown that doesn't exist in the Class editor in community version 2011.9.  Am I looking in the wrong place?

Wednesday 16 November 2011 1:48:14 am

Hello Ian,

Your very welcome. We are here to help.


It is good to hear you agree to avoid the deprecated.

And I'm even more pleased to hear you may have

a better grasp on your eZ Publish requirements.


I took a look at your static mockup png.

I like the idea, but sadly to my knowledge

such a feature does not exist by default / out-of-the-box


Though if I really needed this feature here is how I would create it.

First I would create template overrides for the templates involved in the content/edit datatype edit form templates in a project specific extension design available to both front end and backend siteaccesses, this provides for the ability to affect display changes to the html involved. (Note: If the overrides available don't suite your needs or you actually want to change something more specific in the datatype PHP, I've been known to create custom datatypes based on default datatypes in some use cases. IE: Copy of the ezobjectrelationlisttype datatype (PHP+ini settings) into a xyzobjectrelationlistadjaxtype datatype and customize as needed.)



The second thing I would do is to is also override the content/edit templates for your 'recipe' class (customize one used by both siteaccesses as needed, i'm envisioning creating a solution which works for both admin and user siteaccesses) to inject ezscript_require (relies on ezjscore) to include your custom javascript (only on the edit form of specific content classes ie: recipe) to provide the features needed to accept and process input from user and transmit that input via ajax to a custom module view (simple) or ezjscore call (best).


Which ever method you choose the result is the same server site eZ Publish based PHP which accepts the input sent from the client browser, tests for an existing object with the same input and if none is found a new 'ingredient' object is created and the created object id is returned to the client browser javascript which in turn transforms the content/edit html form contents to contain the received contentobject_id(s) in the html form. I believe the ezobjectrelationlisttype datatype accepts an array of ids for this by default.


I think in this way you will implement a flexible solution which can be easily and gracefully expanded (with all the template overrides in place, most of the work will go into the custom javascript (submit form to ezjscore/call or module view, get contentobject_id of ingrediant object created (or found), add id to hidden html form field (specific ez co attribute datatype based one), reset ingrediant input form and await for further directions) and ezjscore/call or module view PHP (create ingrediant object and return id)


With this base you could easily make the form much more user friendly (thinking displaying ingredients and some way that makes them very enjoyable to add to the recipe being edited/created (so many other possibilities).


I hope this helps ...




Wednesday 16 November 2011 2:46:46 am

Hello Ian,

It is good to hear you digging in deeper into reading the available documentation (it's a valuable resource, i esp love the resource section of the technical manual).

And as it turns out your right, I had never used this feature before today. I followed the directions within the documentation and it worked (sorry, only had access to ezp 4.4.0 install tonight).

In short, re-read the documentation again as it does guide you through the use case fairly clearly.

These were the object relations datatype (look for the s, if you don't have it your trying to use the wrong (deprecated) one) class attribute settings I used to re-create the feature described in the documentation.

  • datatype attribute name: attribute-bla
  • datatype attribute identifier: attribute-bla
  • datatype attribute description: attribute-bla
  • datatype attribute searchable: (unchecked as not needed)
  • datatype attribute Selection method: 'Template based, multi'
  • datatype attribute New Objects
  • datatype attribute New Objects -> Object class: 'Article'
  • datatype attribute New Objects -> Placing new objects under: 'Choose new folder named 'Company'' (See default location)
  • datatype attribute New Objects -> Default location: 'Company' (Type: Folder, Section: Standard)


Indeed it does allow for creation of content objects within the object relation edit templates (but it did require me to press the store draft feature to work ...) and sadly it is limited to only accepting an object name and no other attribute input.

I looked and while it might be possible to extend this behavior within a modified copy of the datatype PHP, I still think the method I described above is much more preferable, flexible and expandable ...


I hope this helps ...





You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from