Control-less native datatypes of eZ Publish

Thursday 29 May 2008 11:49:31 am

Hello everyone,

I have recently realized that a substantial number of datatypes that we have developed for eZ Publish and our clients could be categorized under "datatypes that hadn't had enough control over".

An example would be more than words here.

1) Keywords datatype - no control over it at all, this is why we've developed a public variety, so that we can control a min/max number and length of the keywords.

2) Text line or text block - would be that difficult to have a limit for text block just the way we have one for text line? And what about a minimum limit?

There could be more, but the point is - it seems like the datatypes have been developed merely for editorial scenario, where all the players have been trained and have a common goal. Well, what about Intranets? Community portals? What about situations, where users simply join to contribute OR... not?... ;)

If there is a reason for the native eZ Publish datatypes to be so simple and controlless - what is it? What do you think about it?

The situation is far from hopeless. I mean, creating a datatype is both possible and fun. It's just that we could concentrate on putting together something more interesting than a limit on a string ;) But then, maybe it's just my problem... ;)

Cheers,
Piotrek

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Monday 02 June 2008 12:18:27 am

Hello Maxime,

I believe I meant a slightly different problem. What you're discussing seems to fall into the category of cross-datatype/attribute validation, which is also on my list of things that would revolutionize eZ Publish options and also stands an interesting challenge.

But what I was referring to is much simpler and with focus on one datatype at a time. eZ Publish native datatypes seem to have been designed to run in enterprise/editorial reality, where freedom of editing is restrained by responsibility. However, as we put eZ Publish into wide community access use, we see that this doesn't work out that well.

One of the best things that could happen would be a restricted XMLBlock with several configuration combinations available per eZ Publish installation. So that for some classes I can restrict (mainly at the server level, the OE level is just a nice option, which should be integrated BTW) some of the tags/operations being performed, and some not.

The examples I gave before also should depict nicely of what's in my mind. In most cases, I'm thinking of missing "min", "max", "allow override" -like attributes at the class attribute edit level.

What do you think of that?

Cheers,
Piotrek

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Monday 02 June 2008 4:32:11 am

Kristof,

Thanks for the info - that's a good news! You've already suggested this hack to me a number of times, and worked as long as I did not have to avoid kernel modifications ;)

Cheers,
Piotrek

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Monday 02 June 2008 3:40:23 pm

Hi Kristof as you are here,

I was wondering if a class heritage system is possible and if yes, will it be developped by eZSystems ?

http://www.wascou.org/wascou/Blogs/Maxime-THOMAS/About-a-class-heritage-system-120

Maxime Thomas
[email protected] | www.wascou.org | http://twitter.com/wascou

Company Blog : http://www.wascou.org/eng/Company/Blog
Technical Blog : http://share.ez.no/blogs/maxime-thomas