This site has been archived. To learn more about our current products Ibexa Content, Ibexa Experience, Ibexa Commerce head over to the Ibexa Developer Portal

eZ Community » Forums » Developer » Storing a timetable in a matrix

Storing a timetable in a matrix

Storing a timetable in a matrix

Monday 02 January 2012 6:02:30 am - 5 replies


I need to store information in a timetable, and need to have a datatype like a matrix that can store time/date datatypes.

I searched for a datatype that can suit my needs in but no luck.

Any ideas on how to do this?


Monday 02 January 2012 9:11:48 am

Hello Fátima,


I wonder if you could create a custom datatype which was designed to meet your unique needs?

Perhaps some combination of the ideas presented in the ezdatetime datatype and ezmatrix datatype?

Fátima could take a bit more time and describe your datatype requirements in more greater written detail?

When you share additional details it greatly helps others in the community make more accurate recommendations on possible alternatives or even more direct solutions, more quickly for certain!


Sorry you could not find an existing datatype which more closely matched your requirements.

I took a look myself, but while there are quite a few custom date datatypes, I could not find anything very quickly that matched what you are describing,


It may help others here also to mention the decent starting points available when reviewing the existing default datatypes as a reference,


Post some more details, who knows another might have just the answer your looking for!


If anyone has any suggestions today, please share here in this thread happy.gif Emoticon


I hope this helps ...




Monday 02 January 2012 2:06:09 pm

Heath, thanks a lot for your answer. Sorry, I didn't describe exactly what are my requirements.

I need to store information about a time schedule of all the 365 days of a year, and for 2 specific cities (later I will need to add more cities). This schedule differs for day to day, and for city to city, but not for year to year. In my homepage, I need to display the time schedule of the current day for the current user's location.

Above an example of what my current timetable looks like.

City X

January                                                .....       December

Date     time_a    time_b    time_c                   time_a    time_b    time_c

1          4:45        12:03      19:46                       4:40        12:00      19:29

2          4:46        12:03      19:47                       4:40        12:00      19:30

...         .......                                                       .........

30        5:04        11:53      19:55                       4:44        12:02      19:45


I'm considering the possibility of creating a datatype, I had a look to the following article: But I'll have to study a little bit more how to to this.

If anyone has more ideas, please help me.


Monday 02 January 2012 8:41:37 pm

Hello Fátima,


Thank you very much for sharing additional written details regarding the requirements/needs of your custom datatype!


While I hate to admit this. I do not recommend (any longer) the article you linked to in your latest post. It was not maintained for very long and is more about zeta components than eZ Publish datatypes :P

Sadly we could really use a better / replacement article on creating custom datatypes ...


Creating a custom datatype can at times (especially for newer developers) be very trying and time consuming process. I recommend eZ training and or relying on a more experienced developer to implement your requirements in a more effective and reliable way on your behalf as an alternative to doing all the work on your own alone.


Alternatively, have you considered that this could be implemented today using simply a slightly larger content class? I'll explain what I'm thinking ...


It just seems like you could create a custom 'Schedule by City' custom content object class which stores it's dates in ezdatetime attributes. All which are features available by default.


Within this custom class, add several attributes. Add an attribute (object relation) to link to your 'city' content object if you have one to create a relationship between the two. Add an attribute (ezdatetime) for every date storage point you need in your 'schedule' of dates, this step could be considered the most tedius, and it is but it will work very well and perform even better than other solutions as content objects can have a lot of attributes without the performance problems you might incorrectly expect.


My main point in suggesting this is that it completely avoids the 'perception' that you require a custom datatype when ... you really don't, unless you insist it must be solved through a datatype style implementation, most limits in eZ are often based in specific perceptions on what is best in a given situation ...

While a datatype might be best, in some regards/aspects, it is hardly the only way to implement the requirements your presenting.


Creating the custom class I describe would take some time, and population of your content object data would take further time (and patience) given the number of dates involved. But it would work! And you could use other tools to make this job even simpler.


1. Don't input this content object data by hand. It's too tedius and error prone. Import your data using simple content import solutions available today using either sqlimport extension or csv import scripts provided by default (what I would do first)!


This suggestion saves you a lot of hassle long term as it avoids the need to maintain the data using the object editor (unless you desire to use it), you can simply update these 'scheduled by city' content objects again using csv import tools. This ensures a repeatable process you can re-use again and again to push content changes quickly into eZ (yes in real time if desired). This is what I would do to solve the requirements you present today off the top of my head.


Another benefit of this solution is that the content can be made available to the search engine and so the resulting stored content is -greatly- more indexed accurately than most custom datatype's search engine implementation functionality features would prolly provide right out of the box.  In short this solution recommended above is more search engine friendly overall right out of the box.


This solution is flexible and extendable fairly simply and directly. You can change this solution very easily at any time in the future if your requirements change, like say while unexpected I'd imagine, if the schedules change in some way and you need to change the solution. Well this solution would be a simple one to change. Perhaps even simpler than maintaining a custom datatype's PHP.


So my latest recommendation in short is this: Avoid custom datatyeps! Create custom classes and content objects instead, it's a much better solution to most users needs long term.


I hope this helps ...




Tuesday 03 January 2012 9:47:02 am

Hi Heath,

Thanks a lot for tanking your time and patience to help me. Your can't imagine how your ideia saved my day.

While I was analyzing my timetable problem (before posting my question here), your idea was the fist I had, but has my experience in development is not so high, I thought that this was a stupid idea because I would have to create a lot of date objects, so I decided that It was better to create a special datatype.

About taking ez trainig, I'm really considering that, I'll search what are the training options.


Tuesday 03 January 2012 10:23:17 pm

Hello Fátima,


Your very welcome. I'm happy to help. That's why we are all here happy.gif Emoticon


Honestly using content objects here avoids unessisary datatype development.


* The real issue becomes really clear once you get into this subject matter, 'Content Storage'


Where do you want to store your content. Because in this use case it's fairly clear ... it doesn't matter.


One method (custom datatype) requires extensive PHP + eZ custom development.

The other requires no custom software development only content creation using existing tools.


Your frustrated and confused so I am trying to understand your perspective but .. storing this content as content objects is -smart- not -stupid-.

Infact we at BC actually go as far as to prefer to store content like this as content objects specifically. We generally discourage users who wish create custom datatypes merely to store content within a datatype with no real specific reasons why to store using this methodology explicitly.


IE: Storing content in a custom datatype without a real requirement which requires this is strongly discouraged. In reality your merely complicating the use case requirements needlessly by insisting that a datatype is used here when it's not required.


Best wishes to you with you eZ Education. 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