eZ Community » Forums » Setup & design » Idea for a class or content structure...
expandshrink

Idea for a class or content structure covering additional, seasonal product information

Idea for a class or content structure covering additional, seasonal product information

Thursday 06 June 2013 8:17:48 pm - 5 replies

Hello folks!

We got the request to develop a logic to hold product related information for alternative product seasons (2012, 2013, 2014, and so on). This seems to be pretty easy going - but in the end it i not. We're still using eZ 4.7.

The information consists of four basic information types; each of them placed on different parts of our website.

It may be a set of subpages or a single page only.
The information may be linked with each other.
It also may have a alternative sub-structure for each season (different tree).

It shall be possible to set static (so the basic URL must not change) links from externally created PDFs as well as from other content providing systems based on the type of information and the season to the "landing page" of the information type, selecting the right information of the proper season.

The information must be indexable and searchable by eZ Find.

The information was not divided into different seasons yet, so there are already many pages present which shall be used.

We thought about (ab)using the language feature (each language resembling a season) but I didn't like that very much because this may lead to some strange behaviour in search or when using external modules.
Another idea was to build a container class which holds each season as a item and presents a selection. But that way each content class which has been a parent of the various infomation types must be adopted to the new content class as a possible child element.

I'm quite concerned about both ideas because somehow they both feel awkward. But most probably we just miss something - a simple and congenuine solution.

Regards and thanks in advance for any idea,

 

JT

Thursday 06 June 2013 11:53:38 pm

season - top node

-- info container X

---- info A

--------items

---- info B

--------items

---- info C

--------items

---- info D

--------items

what is the concern with this structure?

it allows you to use any class as "item", and have items which are multilocated.

 

Or...

- use 4 content classes for items, put them as children of info container X, use tpl of parent to display children, like a calendar class would. Url would look like:

/2003/contX/(type)/A/(offset)/10

Friday 07 June 2013 9:14:55 am

Alternatively, you could have the info and/or seasons as a related object (but it won't be as intuitive as what Gaetano suggested.)

Monday 10 June 2013 4:20:42 pm

Well, as described in the original posting the structure has to be integrated into the existing URL/CMS structure and the variety of information is located in a lot of directories owned by different units of the company.

Thus the following structure might be more reasonable:

- productline (page)
-- products (page)
--- producttype A (page)
---- product A1 (virtual page) (=> season 2012)
---- product A2 (virtual page) (=> season 2013)
--- producttype B (page)
---- product B1 (virtual page) (=> season 2013)
---- product B2 (virtual page) (=> season 2012)
---- product B3 (virtual page) (=> season 2011)
- information (page)
-- procuct facts (*should this still be a page? *)
--- product facts 2012 (page)
---- product facts 2012 topic a
---- product facts 2012 topic b
---- product facts 2012 topic c
--- product facts 2013 (page)
---- product facts 2013 topic a
---- product facts 2013 topic b
---- product facts 2013 topic d
-- area information (page)
--- area a (virtual page) [this is not in ez because it is provided by external partners]
---- 2012 (not a page at all - just SOAP content)
---- 2013 (not a page at all - just SOAP content)
--- area b [this is not in ez because it is provided by external partners]
---- 2012 (not a page at all - just SOAP content)
---- 2013 (not a page at all - just SOAP content)
- legal issues (*should this still be a page? *)
-- legal advices 2012 (page)
-- legal advices 2013 (page)

 

The products are not in eZ because eZ wouldn't be able to handle just-in-time all the details belonging to the products.

Till today there was no seasonality for the information. The current hierarchy is 

ROOT » information » product facts » product facts topic a
ROOT » information » product facts » product facts topic b
etc.

and

ROOT » area information » area a » season 2011
ROOT » area information » area a » season 2012
ROOT » area information » area a » season 2013
ROOT » area information » area b » season 2013
etc.

and

ROOT » legal advice » legal advice season 2012
ROOT » legal advice » legal advice season 2013
etc.

Links to "<domain>/information/product_facts/product_facts_topic_a" should be resolved to the current season version of the topic with a alternative selection form on the right side of the page. If the topic does not exist it should be linked to "<domain>/information/product_facts".
Links to "<domain>/legal_advice" should be resolved to the current season version with a alternative selection form on the right side of the page. Links to "<domain>/legal_advice_2012" should display "<domain>/legal_advice/legal_advice_2012" while the middle part "/legal_advice" is optional.

If you have a closer look there are three different flavours of information structure (which can't be changed due to company structure and organisational requirements). This structure is resembled by a bunch of different content classes/templates for each type.

Obviously we don't want to introduce a new content class for each existing content class including a season option because there a many objects that don't need this option.
Additionally I would prefer not to build or alter templates for all of them: the user should not have to learn new "object(ive)s" and I don't neither

  • want to build duplicated templates
  • nor do I want to duplicate the content classes
  • nor do I want to copy all attributes of the existing classes to one or a variety of new classes.

We wanted to introduce a "layer" object (an eZ container) to be inserted between the existing information –e.g. pages or just paragraphs– and the parent page object.

This is additionally pushed by the fact that every other content class and the contents of sister companies might get seasons at any point in time in the future.

The way described would render only some minor changes on these additional classes/templates in that case because it is modular and reusable. Else we have to edit a lot of classes and content.

Though, I wanted to hear alternative opinions by some experienced developers.



Tuesday 11 June 2013 12:25:16 pm

I am starting to think that what you are asking for needs at least one day of proper consulting. It is hard to grasp all the details from just a couple of forum posts blunk.gif Emoticon

Looking from 10km at your requirements, I'd say it is doable, and eZ is a good choice precisely because of its flexible content model.

I am unsure about the "best" solution, but the fact remains that you can:

- add a "season" attribute to tour products. You do not have to redo all existing classes, just alter them. For products with no valid season, use a "na" value. This allows you to fetch any desired products by season by using either an attribute filter or ezfind requests

- create seasons as a separate content tree and link products to seasons using either multilocation or an object-relation attribute (main difference between the 2 being the default editing GUI, roles&policies possibilities and the fact that obj. relation attributes are versioned, multilocations are not)

- create custom workflow events which make lives of editors easier by hiding most of the work underpinning this

- fetch anything anywhere using just the template language (and even create custom fetch functions)

- use custom modules/views to render you alternate taxonomies if creating content objects for all the intermediate levels of such taxonomies is too much of a pain

- add rewrite rules both in eZ and in the webserver to preserve the old URL layout

But of course you will need to do some work as well - not changing templates, content classes, content objects or anything else makes it difficult to add functionality...

Friday 21 June 2013 2:31:05 pm

Thank you very much for your suggestions.

 

Unfortunately all of them have one requirement: The products have to be stored in eZ. This, as described before, is not viable.

We would have to do product imports every couple of minutes with updated informations because the products are highly volatile in pricing and availability.

We tested a while ago importing the product data to ez but a single import run was about 5 hours. Additionally this would imply a two-way synnch between eZ and our main production system which is hosted on an HP-UX mainframe controlling production processes (they are stored in Cobol based data files, not a relational database).

That's essentially why we can't import the products in eZ.
Due to that fact there was developed a SOAP webservice which is transparently providing the products on the fly to a eZ module which includes the up-to-date, just-in-time product information in the pages.

eZ is just providing the pageframe and a navigational structure, but not the products. And that's why your ideas aren't applicable. And that's why I said it look's easy but it isn't.

 

Nevertheless I appreciate your thoughts.

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from