eZ Community » Forums » Suggestions » Integrity flag element in the class...
expandshrink

Integrity flag element in the class definition

Integrity flag element in the class definition

Wednesday 30 January 2008 12:20:08 pm - 17 replies

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?

Wednesday 30 January 2008 12:32:00 pm

are you talking about ezselection?
If so have a look at enhancedselection, it uses a identifier / value pair to solve the problem.
I think it also has a setting for locking identifiers as well.

Wednesday 30 January 2008 12:43:15 pm

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

If you look here:
http://ez.no/doc/ez_publish/techn...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/setu..._only_1_attribute_of_a_contentobject

Modified on Wednesday 30 January 2008 12:44:23 pm by Piotr Karaś

Wednesday 30 January 2008 12:56:40 pm

Yes, that's another issue.
So what you are suggestion is a 'required all required attributes' flag on the class, so you have to have all the required attributes OR the entire attribute set present when you try to create a new object from the API ?

Modified on Wednesday 30 January 2008 12:57:04 pm by André R

Wednesday 30 January 2008 1:05:55 pm

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

Modified on Thursday 31 January 2008 6:34:08 am by Piotr Karaś

Thursday 31 January 2008 10:13:55 am

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.

As I know of there are now several enhancement / suggestion request for classes:
* class & class attribute description ( for help / accessibility text when editing )
* class attribute grouping and categorization pr group ( for instance content / meta / information collectors )
* draft less publishing*
* 'required'='required' on classes
* class inheritance ( as in OOp )
* Class attribute for switching storage model pr class**

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

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

** 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).

Thursday 31 January 2008 9: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?

Thursday 31 January 2008 10:26:34 pm

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

the stuff under '*' also applies to this.

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

Also for use in edit templates and for presentation in full.tpl and line.tpl, so it is more useful with only some small css enhancements pr class / node id ( as html classes in the html).
http://ez.no/developer/forum/setu.../content_class_attribute_description

>> draft less publishing*
> 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?

The create new -> edit -> publish is not where web 2.0 friendly. It should be possible without hacks to have a form on a page for creating the class directly.
So yes, no pre-creating , no NewButton. It needs to create a draft for validation if there is a validation error though.

>> 'required'='required' on classes
> Apart from the first one about descriptions, seems easiest to implement.

yes, probably.

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

>> 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 happy.gif Emoticon

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

true

> Do you consider creating DB tables dynamically per content class?

It's not my idea, it has been a internal suggestion for years.

Modified on Thursday 31 January 2008 10:40:18 pm by André R

Friday 01 February 2008 7:09:10 am

>> 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 happy.gif Emoticon

Ok, we're home with this one blunk.gif Emoticon

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

Friday 01 February 2008 10:28:17 am

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

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.

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

Modified on Friday 01 February 2008 10:36:22 am by André R

Saturday 02 February 2008 9: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?

Modified on Saturday 02 February 2008 9:08:49 am by Piotr Karaś

Sunday 10 February 2008 8:10:58 pm

Hello again,

I've just experimented a bit and found out that all the attributes, present or not, end up validated by the represented datatype. If you've tried to tell me that, I haven't seen it until now and it changes the situation in a way that I do have control over it, which is great.

I described it a bit in my blog:
http://ez.ryba.eu/index.php/ez_pu...e_flag_on_the_object_attribute_level

Monday 11 February 2008 2:23:14 pm

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 happy.gif Emoticon

Bartek

Wednesday 13 February 2008 11:46:37 am

The possible issues described by Piotrek here are indirectly causing http://issues.ez.no/10655

Wednesday 13 February 2008 5:47:33 pm

<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 happy.gif Emoticon</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?

Thursday 14 February 2008 8:25:56 am

Hi Piotrek

I mean any datatypes which validation check can be bypassed by simply omitting their post variables.

By the way, for cross-validation between datatypes, you can use this hack: http://projects.ez.no/objectvalidation

Modified on Thursday 14 February 2008 8:27:17 am by Kristof Coomans

Thursday 14 February 2008 9: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?

Sunday 17 February 2008 7:18:45 pm

<i>> By the way, for cross-validation between datatypes, you can use this hack:
> http://projects.ez.no/objectvalidation</i>

Hello Kristof,

Why doesn't an interface for such solutions doesn't make it into the kernel, so that you do not have to touch the kernel to extend it? Just a closed door that can be opened when needed? It doesn't have to be anything more than an if-statement with custom inclusion... does it?

BTW. Great thing!

Modified on Sunday 17 February 2008 7:19:17 pm by Piotr Karaś

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from