Validation feature

[Peter Van Garderen]

First of all, excellent work Jes�s, Jack and Evelyn on the Validation feature.
This is looking fantastic.

Can we please get an update on which of the requirements are still be completed?
http://qubit-toolkit.org/wiki/index.php?title=Validation#Requirements

That way we can prioritize them. Roughly speaking, however, I would say that the
current order on the wiki page actually reflects the priority. Certainly the
ISAD validation requirements and then ISAAR. Followed by ISDIAH & ISDF. The RAD
and Generic requirements can be completed after Jan.4 if necessary.

Also, I was wondering what happened to including asteriks on the edit templates?
I agree with Evelyn that Asterisks in edit screen plus validation messages in
view screen are the preferred combination.
http://qubit-toolkit.org/wiki/index.php?title=Validation#Edit_pages

Also, love the fact that Validation messages only show for users with 'Update'
permission, nicely done.

Cheers,

--peter

[Jesús García Crespo]

Hi all,

On Wed, Dec 23, 2009 at 9:37 PM, Peter Van Garderen <pe...@artefactual.com> wrote:

First of all, excellent work Jesús, Jack and Evelyn on the Validation feature.

This is looking fantastic.

Can we please get an update on which of the requirements are still be completed?
http://qubit-toolkit.org/wiki/index.php?title=Validation#Requirements

Done. I marked all of them as "completed" or "in progress". 

 

That way we can prioritize them. Roughly speaking, however, I would say that the
current order on the wiki page actually reflects the priority. Certainly the
ISAD validation requirements and then ISAAR. Followed by ISDIAH & ISDF. The RAD
and Generic requirements can be completed after Jan.4 if necessary.

Okay. All of them have been already completed!

I would like to comment with you some doubts:

[ISAD - Level of description]

It is being discussed in its own qubit-dev thread

[RAD - Notes]

As Evelyn commented at the wiki page, this is not very clear. Notes is a big area of fields. What exactly should we validate here? Validator fails if *any* of the fields in this area were completed?

[RAD - Class of materials specific details]

This is really an area of five fields. For the time being, I made those five fields as mandatory ones. Should I keep this behavior or just to makes the validator fail when all of them were not completed?

[RAD]

For other metadata standards as ISAD we have a wiki page where we linked from validation error messages to show users why these fields are required or not validated. However, it seems we don't have a page for RAD at qubit-toolkit wiki, should I do create links to an external resource?

[RAD]

I would like you to double check the logic that I implemented to validate RAD fields (plugins/sfRadPlugin/modules/sfRadPlugin/modules/actions/showAction.class.php). I followed the requirements inserted by Evelyn in the wiki page, but there is a big dependency on the level of description value. Is this right? When level of description value was not defined, I just show that this field is a mandatory field.

Also, I was wondering what happened to including asteriks on the edit templates?
I agree with Evelyn that Asterisks in edit screen plus validation messages in
view screen are the preferred combination.
http://qubit-toolkit.org/wiki/index.php?title=Validation#Edit_pages

I was investigating this question. Asterisks are shown when the validator has the option 'required' set at true. However, if this option is required and the user leaves one of those fields empty, the edit page won't be saved and he will have to complete it to save the form. Because this is not our target, I think I have to look for a different way to show that asterisk.

There is only one week left!

Have a nice weekend, :-).

Regards,

--
Jesús García Crespo

[Peter Van Garderen]

> [RAD - Class of materials specific details]
> This is really an area of five fields. For the time being, I made those
> five fields as mandatory ones. Should I keep this behavior or just to
> makes the validator fail when all of them were not completed?

This is one is more complicated. They are only applicable if a matching General
Material Designation is chosen. i.e. if 'Architectural drawing' is chosen then
'Statement of scale (architectural)' is required:

Architectural drawing: Statement of scale (architectural)

Cartographic material: Statement of scale (cartographic), Statement of
coordinates (cartographic), Statement of scale (architectural)

Philatelic material: Issuing jurisdiction and denomination (philatelic)

I captured the ^ above feedback in the RAD section on the Validation wiki page.
http://qubit-toolkit.org/wiki/index.php?title=Validation#RAD

As for the other RAD validation issues, please put these on hold. We need some
further communication with LAC and the CCAD committee responsible for RAD as
there are a number of incongruences. I will take care of that in early January
as part of our response to the LAC review of RAD in ICA-AtoM 1.0.8.

[Peter Van Garderen]

... so for now, please just disable the RAD validators for the 'class of
material specific details area'. These are a lower priority then finishing the
remaining ISAD validation requirements.

Also, please just disable the RAD validators at the Item level for now as these
also need an additional check. As Evelyn points out, these required fields are
only valid if the item type is a publication. Therefore, this validation rule
should only be enforced if the item-level QubitInformationObject is linked to a
QubitEvent where typeId == QubitTerm::PUBLICATION_ID.

--peter

> --
>
> You received this message because you are subscribed to the Google Groups "Qubit Toolkit Developers" group.
> To post to this group, send email to qubi...@googlegroups.com.
> To unsubscribe from this group, send email to qubit-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/qubit-dev?hl=en.
>
>
>

[Peter Van Garderen]

> Also, I was wondering what happened to including asteriks on the
> edit templates?
> I agree with Evelyn that Asterisks in edit screen plus validation
> messages in
> view screen are the preferred combination.
> http://qubit-toolkit.org/wiki/index.php?title=Validation#Edit_pages
>
> I was investigating this question. Asterisks are shown when the
> validator has the option 'required' set at true. However, if this option
> is required and the user leaves one of those fields empty, the edit page
> won't be saved and he will have to complete it to save the form. Because
> this is not our target, I think I have to look for a different way to
> show that asterisk.

Agreed. This will have to move in stages.

1st: simply replicate the validation report that is on Show template in the Edit
template (as an interim step to simply get validation working on the edit template)
2nd: add a CSS div or class to the field label and/or control for which a
validation rule applies. Then we will let the active Theme take over and style
accordingly, (i.e. turn field label text to red, put a red asterik in as the div
background, give the input control a red border, etc)
3rd: provide the validation rule as tooltip text when doing a mouseover on the
field label and/or control

--peter

[Peter Van Garderen]

Actually, thinking about this issue some more. If all we want for the edit
template is to have an indication at each field in the template where a
validation rule applies, what is the difference between entering these in one
place (i.e. action class or a validation class) and then programmatically
outputting them in the template vs just putting them directly into the template
file. It would seem to me the latter is much simpler and quicker? Maybe the
(former) programmatic approach is overkill in this case?

--peter

[Peter Van Garderen]

I discussed this further with Jack and we decided that this is a good first step
in implementing validation in the edit templates (i.e. simply marking up the
template to indicate fields that have validation rules).

However, now that much of our form fields are getting rendered the next question
is where to do this.

We could pass an additional $option to
qubit/apps/qubit/lib/helper/QubitHelper.php function render_field

e.g. <?php echo render_field($form->title->help(__('Provide either a formal
title or a concise supplied title in accordance with the rules of multilevel
description and national conventions.')), $informationObject, array('class' =>
'validation')) ?>

However, that would limit validation styling to just the input control. My
preference is to apply a 'validation' class to the whole, enclosing <div
class="form-item"> so that we can apply styles to its sub-classes as desired per
theme, e.g. .validation.label, .validation.input, etc.

This could be done by passing an additional (non $options) $validation parameter
to the render_field function. If this parameter is true then the function will
add a class="validation" to the enclosing div.

The parameter value can also include the validation text which can then be
hidden or displayed in any number of ways. I propose we hide it at first
until we figure out the initial steps.

To start simple we can simple change the field label colour to red if validation
is true for that field.

Thoughts?