Integrity flag element in the class definition

Wednesday 30 January 2008 3:20:08 am

One thought came to my mind regarding the issues with editing selected attributes of a content object. I was completely concentrated on the selected attributes, and lost the opposite perspective from sight: it could be quite useful if there was a flag during content class configuration (let's call it integrity flag) that would control whether it is actually possible to edit selected attributes, and not the entire set. If checked, the system would force additional validation that would make sure, that the submitted HTTP input contains all of the attributes.

What do you think about it?

--
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

Wednesday 30 January 2008 3:43:15 am

Hmm... I don't think that's the same thing.

If you look here:
http://ez.no/doc/ez_publish/technical_manual/4_0/concepts_and_basics/content_management/the_content_class

It says, that:
<b>A content class consists of the following elements</b>
- Name
- Identifier
- Object name pattern
- URL alias name pattern
- Container flag
- Default sorting of children
- Default object availability flag
- Attributes

I would suggest <b>another flag</b> which, if checked, would on the object edit level force additional validation that would make sure no single attribute was skipped (and thus gets validated against rules of the datatype it implements).

It is another side of this issue:
http://ez.no/developer/forum/setup_design/is_it_possible_to_edit_only_1_attribute_of_a_contentobject

--
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

Wednesday 30 January 2008 4:05:55 am

Yes, now I can see it's more complicated and I also didn't think of the 'required' setting. In that case, I believe 'required all required' is what I would be thinking of.

So what do you think of the idea as well as of chances of such functionality/flag being introduced to eZ Publish?

The positive sides I can see are:
- Optional more reliable data validation and integrity check.
- Ability to introduce all sorts of controlling attributes based on custom datatypes, which cannot be omitted.

Actually, a whole new meaning to 'required'. If I'm not mistaken, right now 'required'='required when present' (more about attribute's value than the attribute itselt). The new flag, if checked, would make 'required'='required'.

--
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

Thursday 31 January 2008 12:37:22 pm

Thanks for this detailed report, André!

I agree that this would be a good idea, but the api is not really meant to edit only a few attributes so needs some work to support this kind of functionality.

Could you please explain that in few words? I'm not sure I understand.

It is great that you brought up a list of related suggestions. It would probably take some time to get across them.

class & class attribute description ( for help / accessibility text when editing )

I agree, quite a handy thing, also for internal documentation.

class attribute grouping and categorization pr group ( for instance content / meta / information collectors )

Do you remember any details? Would in this suggestion be the grouping for organizational purposes only?

draft less publishing*
There are 2 issues that prevents this from happening today without 'hacking': 1. post name pr datatype is hardcoded in template and datatype, witch means you have to use the datatype/edit templates witch leads us to 2. post name includes attribute id of the specific attribute witch means it has to exist as a draft to work. Take a look at 'Power content' for a workaround.

This one I still have ahead of me, I have to learn more about workflow and object states. Yet, what do you mean by draftless? Without pre-creating an object (draft) when NewButton action is detected?

'required'='required' on classes

Apart from the first one about descriptions, seems easiest to implement.

class inheritance ( as in OOp )

Wow. This would be something, indeed. Any details on this idea?

Class attribute for switching storage model pr class**

Could that actually be forced from the attribute level? Shouldn't that be a class level declaration? I may be confusing something, sorry. Definitely a big thing, though.

So what I'm trying to say is that classes should get a overhaul at some point, but I don't think we have time for something like that in the next 2 versions. Maybe if several partners want this, we could do it in Open Funding where one of the partners to the actually implementation ( probably except the last two suggestions, since they would involve a lot of internal changes ).

Great idea. I believe that even the smaller of these suggestions could provide developers with tools so much more powerful.

** Today we only have 1 storage model ( ezcontentobject -> ezcontentobject_attribute) where there is one entry in ezcontentobject_attribute pr attribute, this is kind of overkill for classes that doesn't need versioning and that could exist in large numbers ( for instance 1 mill users with 20 attributes and 5 versions wouldn't work, since it would mean between 20 and 100 mill rows in ezcontentobject_attribute).

Do you consider creating DB tables dynamically per content class?

--
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

Thursday 31 January 2008 10:09:10 pm

>> Could you please explain that in few words? I'm not sure I understand.
> the stuff under '*' also applies to this.

I'm afraid I don't see that. If you could please explain this part: "the api is not really meant to edit only a few attributes", or just give a hint, I'd be grateful!

>>> class inheritance ( as in OOp )
>> Wow. This would be something, indeed. Any details on this idea?
> No, but it has so many use cases it should be looked in to.
> 1. a base class that defines common attributes like name and description.
> I'm not a big fan of different identifiers for attributes that does the same.
> If they had the same identifiers, it would make it more easy to do dynamic stuff.
> 2. If you need some small changes to a class but it is 1. locked by eZ network
> or 2. there is a another use for it you have in mind.

It would be a great improvement, indeed. But also, a bit more difficult to learn to use safely, not that it is an argument against, just a drawback.

>>> Class attribute for switching storage model pr class**
>> Could that actually be forced from the attribute level?
> Attribute on the class like identifier's or default sorting, not attribute on the attribute :)

Ok, we're home with this one ;)

>> Do you consider creating DB tables dynamically per content class?
> It's not my idea, it has been a internal suggestion for years.

By you I meant you or eZ in general. But is that it? Is it about class/table relationship?

Thanks!

--
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

Saturday 02 February 2008 12:07:59 am

> As in the validation of attributes are made for use in the content / edit view,
> and by that I mean the datatypes expect a post variable with a specific
> post variable name with the attribute id in it to be able to validate the input.

Ok, if that's it, I understand that.

But we've given it some thought again and have even more doubts about the 'required' issues. I may be repeating myself a bit in parts, but wanted to put thoughts together:

1) "Required" flag, that we have today, suggests by semantics that the attribute is required, however, that is not so. I hope I was the only user not to go in depth with this issue, however I expect otherwise. Today's "required" should in my opinion be called "Value required" or "Require value", because that's what the checked flag actually causes.

2) If I take what you wrote (and already explained) as I understand it: <i>"I agree that this would be a good idea, but the api is not really meant to edit only a few attributes so needs some work to support this kind of functionality."</i>, my question is: why isn't the default behavior of attribute validation such that all attributes are required to be present?

3) Doesn't lack of all/any of the solution ideas mentioned above (or other) make the editing process vulnerable to any manipulation of the presentation layer? Isn't that comparatively easy to simply omit all uncomfortable attributes, for example datatype-based CAPTCHA, limits, identifiers, etc.?

4) "Require all required" as a class attribute/flag actually doesn't make much sense with current "Required" meaning. What would it mean? Require all required values? This is why I suggest that there should be a separation of "required flags". We could leave today's required as "Require value" flag, as I suggested above. Then, there should be an additional flag that would decide whether the attribute itself is <b>required to be present</b> in the editing process. This would be much more flexible than earlier "require all required" and at the same time seems to make that idea useless.

Let's draw an attribute:

[x] Require attribute (new flag)
[x] Require value (today's flag)
[x] Searchable
[x] Information collector
[x] Disable translation

>>>> Do you consider creating DB tables dynamically per content class?
>>> It's not my idea, it has been a internal suggestion for years.
>> By you I meant you or eZ in general. But is that it? Is it about class/table relationship?
> Yes, one of the suggestions was to have one table pr class in the 'simple storage' model,
> possible also turn of versioning on these classes.But this suggestion involves a lot of work > both in feches, attribute filters, extended attribute filters, sort by's, class create / modify /
> delete, object create / modify / delete and so on..

Any other suggestions?
Isn't that, though, a major problem to solve if we want eZ Publish to be able to serve the really big projects? Is that just a technical request or is eZ team taking this as a strategic feature?

--
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 11 February 2008 5:23:14 am

Hi guys,

Interesting discussion. I would like to add from my side another feature: cross datatype validation. Sometimes client requries that "one of two fields must have some content", for example: File or URL.
Of course javascript function with alert is not the solution :)

Bartek

Baobaz
http://www.baobaz.com

Wednesday 13 February 2008 8:47:33 am

<i>> Interesting discussion. I would like to add from my side another feature:
> cross datatype validation. Sometimes client requries that "one of two fields
> must have some content", for example: File or URL.
> Of course javascript function with alert is not the solution :)</i>

<b>Bartek</b>, I agree, that would be a great improvement. Currently it is possible to cope with that limitation using complex custom datatypes, but that's only a temporary solution, and cannot really be of much help when the content held with these datatypes is actual valuable data that you want to operate on and not just setting-like meta-data.

I am planning to look into cross attribute object validation from within a datatype, maybe within a dedicated datatype. Let you know if that led me anywhere.

<i>> The possible issues described by Piotrek here
> are indirectly causing http://issues.ez.no/10655
> Possible solutions: - fix the datatypes (issues.ez.no)</i>

<b>Kristof</b>, which datatypes do you mean in particular?

--
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

Thursday 14 February 2008 12:39:24 am

Any idea of how you will deal with the fact that possibly numerous working eZ Publish installations rely on attribute omitting as a built-in solution for editing selected attributes of an object?

And if the above is true, than will that in any way speed up the development and introduction of some proper selected-attributes-editing solutions?

I know, tough questions, but it's a tough issue, isn't it?

Here's how I provided my newly developed datatypes with backward compatibility:

function validateObjectAttributeHTTPInput( $http, $base, $contentObjectAttribute )
{
	if ( $http->hasPostVariable( $base . '_data_text_' . $contentObjectAttribute->attribute( 'id' ) ) )
	{
		$variablePost = $http->postVariable( $base . '_data_text_' . $contentObjectAttribute->attribute( 'id' ) );
		// Further validation...
	}
	else
	{
		$ini = eZINI::instance( 'mydatatypesettings.ini' );
		if( $ini->hasVariable( 'GeneralSettings', 'IsAttributeRequired' ) )
		{
			if( $ini->variable( 'GeneralSettings', 'IsAttributeRequired' ) == 'true' )
			{
				$contentObjectAttribute->setValidationError( ezi18n( 'extension/mydatatype', 'The attribute is missing in the presentation/XHTML layer!' ) );
				return eZInputValidator::STATE_INVALID;
			}
		}
	}
	return eZInputValidator::STATE_ACCEPTED;
}

What do you think?

--
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