"Require flag" on the object attribute level

Sunday, 10 February 2008, 20:02
Categories: Lab
Tags: datatype, require flag, content object attribute, attribute, content class, validation, content model

Lately we've been having this discussion with André about different suggestions regarding ways to improve eZ content model:
http://ez.no/developer/forum/suggestions/in...

It was started by my own suggestion to introduce an additional flag that would sort of require objects attributes to be present (or, in other words, impossible to remove from the presentation/XHTML layer). And that actually resulted from my early eZ days questions on how does eZ Publish actually deal with missing attributes...

Back to the additional "require attribute flag"
  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. 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 required to be present 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.
Discovery

Well, I finally found some time to look at it again, especially into the eZ Publish kernel. I followed the path that an attribute takes from the edit view all the way to the datatype itself. Actually, I found out that no matter what you do, no matter how you manipulate the presentation layer, the attributes of a content class always reach input validation function in their datatype. So it is up to the given datatype to take further steps, but it's already a good news: it is possible to force attributes without any kernel/lib modifications! Here's an example (ezstring datatype):

function validateObjectAttributeHTTPInput( $http, $base, $contentObjectAttribute )
{
if ( $http->hasPostVariable( $base . '_ezstring_data_text_' . $contentObjectAttribute->attribute( 'id' ) ) )
{
// THE REST OF THE CODE
}
$contentObjectAttribute->setValidationError( ezi18n( 'kernel/classes/datatypes', 'Attribute missing in the presentation layer!' ) );
return eZInputValidator::STATE_INVALID;
}

A quick update on my four points above: I still believe the new flag would be a useful solution. I still believe there's space for both "required flags". I'm still not sure why checking an attributes presence is not default behavior in most (or all) out-of-the-box datatypes. But at least now I have it under control! ;)

And here's how the new flag could work:

function validateObjectAttributeHTTPInput( $http, $base, $contentObjectAttribute )
{
if ( $http->hasPostVariable( $base . '_ezstring_data_text_' . $contentObjectAttribute->attribute( 'id' ) ) )
{
// THE REST OF THE CODE
// Including use of: $contentObjectAttribute->validateIsRequired()...
}
elseif( $contentObjectAttribute->attributeIsRequired() )
{
$contentObjectAttribute->setValidationError( ezi18n( 'kernel/classes/datatypes', 'Attribute missing in the presentation layer!' ) );
return eZInputValidator::STATE_INVALID;
}
}

What do you think?

Comments

No comments yet
Log in or register to add a comment