Another new datatype suggestion: country

Friday 20 June 2003 12:48:41 am

I currently have a user with a enum 'country' attribute and quickly realised entering country data would be a complete pain given that there are hundreds to be put in. Last night I wrote a simple sql script to insert all countries into the ezenumvalue table, using the country list from the ez shop and some emacs macros... I could add this as a contribution if anyone is interested.

However, i now realise the best way to handle this would be as a datatype - a specialised enum. I would write this myself but i believe the text should change to handle different languages and im not confident on the php for that.

Would such a datatype be useful?

paul

Friday 20 June 2003 6:44:17 am

There are defintely lots that could go into this datatype. A .ini file may be useful for setting site parameters. A design is essential.

Ez, have you considered something like this?

Looking forward to 3.2 when i can 'port' my country enum around more easlily :)

paul

Friday 20 June 2003 9:59:38 am

I've tried out my sql script and have hit a snag relating to system speed.

Once imported the database access to ezenumvalue becomes extremely slow and with ez default settings i hit the error:

Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/sites/site/2767/kernel/classes/datatypes/ezenum/ezenumvalue.php on line 58
Fatal error: eZ publish did not finish it's request

I've about 238 countries in my enum and this seems to kill the system, which suggests the datatype idea is kind of dead. Once cached this might help but it seems to be the wrong approach.

The other way around this is code the data into a tpl file.

I need to think more about this.

Ez, how did you do it with your shop?

Paul

Sunday 22 June 2003 2:46:40 am

I was thinking of working on that shortly as well, but if you are already working on it go ahead, im looking forward to see it. Any ideas when you will finish by? ;)

Yes, the enum approach was wrong. I guess I had to try that approach to really find out the issues. Lesson learnt ;)

paul

Sunday 22 June 2003 5:52:49 am

wonderful, esben!

tomorrow i'll try using this and give feedback.

thanks

paul

Sunday 22 June 2003 6:36:43 am

Bård - as I see it in ezpub3, the philosophy has been to recognize basic patterns and then implement those. I mean what is the profound difference between a user and an article from a programming perspective ? In ezpub3 the answer is simple: There are no profound diffencies - they are both just collections of data.

In fact when I started out doing a betting site - I wanted to do something similar - but quickly realised that there were NO WAY I could implement it within the given timeframe - so I went and used ezpub 2.x.x instead :)

The country datatype that I've provided here is very simple - but in fact it holds all the patterns of an even more generic datatype (the one I call 'list')

The (hypothetical) 'list' datatype is basically providing the same functionality as the (implemented) 'enum' datatype. But it doesn't hit the database - instead it holds it's list-items in text files. Thus it performs much better.

When I get some more time - I'll take a stab at the 'list' datatype - but I need to get aquainted with the translation libs of ezpub3. The thing that worries me is with long lists (like a country list) you want as little processing as possible. So maybe you'd have to circumvent the i18 (or is i10? ) libs and simply have the lists in the locale folder. Circumventing the translation libs would introduce a new element in the ezpub3 architechture - hmmm lost sight of my point :)

Just trying to say that something like this would be very valuable and worth some consideration.

Hehehe - did I ask a question or did I just think aloud ?

When I get some time I'll look into this (hopefully)