How to override the EZ automatic validation process ?

Next topic

Author	Message
Hakim Bouras	Wednesday 19 August 2009 1:27:52 am Hi, Ez Publish provides an automatic validation system when editing an abject based on the class description. Would it be possible to "override" this automatic validation using a workflow extension ? Something that will happen just after the automatic validation process is done, and that will provide us a way to change the output of the automatic validation (either by adding extra validation problem to the $validation template variable or by removing validation problems added by the automatic process). If this is possible, what are: - the event to plug in (before content publish ?) - the variable storing the result of the validation - how to change the result of the automatic validation (validation OK or problem) so that the normal EZ editing process can continue ? Thanks for your help, Hakim
Bruce Morrison	Wednesday 19 August 2009 2:26:52 am Hi Hakim My gut feeling is that the answer is that it's not possible. The validation is done in the datatype and I believe the content object will have to pass validation before it is published (so before the before publish workflow has a change to kick in). Cheers Bruce My Blog: http://www.stuffandcontent.com/ Follow me on twitter: http://twitter.com/brucemorrison Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish
Heath	Wednesday 19 August 2009 3:40:42 am Hello Hakim, I have provided similar features per unique customer requests in the past. Most of the time depending on what your trying to do this gets complicated. Most will tell you it's not possible. That is not always the case. Often I have had great success with custom validation within copies of ezpublish datatypes to provide for more user friendly validation / storage / etc . I find that for the most part, the best results are found in focusing your changes to the datateypes themselves (making variations with modifications) - I have added ezimage datatype to ignore validation errors and always store the uploaded image regardless of other attribute validation errors. This helps editors greatly for example. - I have manipulated other various datatypes to ignore default php code and content class definition attribute / datatype defaults (such as validation settings stored within the class definitions in the admin). This let a customer work with an existing configuration / content in a unique way which avoided default validation and instead provided extended clientside (javascript) and serverside validation which functioned in a more user friendly way. This code was published as a number of projects, http://projects.ez.no/bcicfv I hope this helps. Cheers Heath Brookins Consulting \| http://brookinsconsulting.com/ Certified \| http://auth.ez.no/certification/verify/380350 Solutions \| http://projects.ez.no/users/community/brookins_consulting eZpedia community documentation project \| http://ezpedia.org
Hakim Bouras	Wednesday 19 August 2009 8:43:26 am Thanks for you answers. Since I am using version 4.1 of eZ Publish, do you know if the "Enhanced" content edit handler for validation rules in eZ Publish 4.1 might be a solution ? Did you get to use it ? It is not clear to me how it is possible, while using custom validation rules in some context (specific attributes, specific templates) to be able to call the "automatic" EZ validation process otherwise (as a default validation mechanism). Any idea ? in my custom edit handler : function validateInput( $http, &$module, ... ) { if (conditions for custom validation 1) { $result = manage_custom_validation1(); } elseif (conditions for custom validation 2) { $result = manage_custom_validation2(); } else { $result = HOW_TO_RELY_ON_EZ_AUTOMATIC_VALIDATION(); } return $result; } Hakim
Bruce Morrison	Wednesday 19 August 2009 5:05:06 pm Hi Hakim I've had a quick poke around the source and documentation and it would appear that a Custom edit handler validateInput method provides <b>additional</b> validation that is performed after the validation present in the datatype. You can see this in kernel/content/attribute_edit.php 246-270 So it would appear that this method would be unsuitable for what you want to achieve. Perhaps if you can provide some more context as to why you want to do this I may be able to provide an alternative solution. Details on the Custom edit handler and the enhancement: http://serwatka.net/blog/ez_publish_3_8_new_custom_edit_handler http://pubsvn.ez.no/nextgen/trunk/doc/features/4.1/enhanced_custom_edit_handler.txt Cheers Bruce My Blog: http://www.stuffandcontent.com/ Follow me on twitter: http://twitter.com/brucemorrison Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish
Hakim Bouras	Thursday 20 August 2009 2:07:54 am Hi Bruce, Your explanations makes the picture a lot clearer, and I can now understand better the limit of what I wanted to achieve. In fact, I am trying to move to version 4.1, and was having validation issues with custom edit templates which do not provide all the required fields existing in a class. This was working fine, untill the version 4.1. It looks like the easiest solutions will then be either for me to remove the "required" characteristic of the field, or to add the required fields back in the custom templates. <b>By any chance, do you know where in the code the events "before publish" and "after publish" are triggered ?</b> Thanks for your help, Hakim

eZ debug

Timing:	Jan 18 2025 18:32:54
Script start
Timing:	Jan 18 2025 18:32:54
Module start 'layout'
Timing:	Jan 18 2025 18:32:54
Module start 'content'
Timing:	Jan 18 2025 18:32:55
Module end 'content'
Timing:	Jan 18 2025 18:32:55
Script end

Main resources:

Total runtime	0.6084 sec
Peak memory usage	4,096.0000 KB
Database Queries	68

Timing points:

Checkpoint	Start (sec)	Duration (sec)	Memory at start (KB)	Memory used (KB)
Script start	0.0000	0.0045	588.0625	152.6406
Module start 'layout'	0.0045	0.0021	740.7031	39.4766
Module start 'content'	0.0066	0.6003	780.1797	637.0000
Module end 'content'	0.6069	0.0015	1,417.1797	20.1250
Script end	0.6084		1,437.3047

Time accumulators:

Accumulator	Duration (sec)	Duration (%)	Count	Average (sec)
Ini load
Load cache	0.0029	0.4781	16	0.0002
Check MTime	0.0012	0.1995	16	0.0001
Mysql Total
Database connection	0.0006	0.1007	1	0.0006
Mysqli_queries	0.5359	88.0794	68	0.0079
Looping result	0.0007	0.1208	66	0.0000
Template Total	0.5797	95.3	2	0.2898
Template load	0.0020	0.3332	2	0.0010
Template processing	0.5776	94.9343	2	0.2888
Template load and register function	0.0001	0.0153	1	0.0001
states
state_id_array	0.0010	0.1660	1	0.0010
state_identifier_array	0.0013	0.2217	2	0.0007
Override
Cache load	0.0018	0.3022	60	0.0000
Sytem overhead
Fetch class attribute can translate value	0.0007	0.1103	3	0.0002
Fetch class attribute name	0.0014	0.2335	9	0.0002
XML
Image XML parsing	0.0014	0.2283	3	0.0005
class_abstraction
Instantiating content class attribute	0.0000	0.0044	12	0.0000
General
dbfile	0.0011	0.1736	29	0.0000
String conversion	0.0000	0.0011	4	0.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

Usage	Requested template	Template	Template loaded
1	node/view/full.tpl	full/forum_topic.tpl	extension/sevenx/design/simple/override/templates/full/forum_topic.tpl
6	content/datatype/view/ezimage.tpl	<No override>	extension/sevenx/design/simple/templates/content/datatype/view/ezimage.tpl
6	content/datatype/view/ezxmltext.tpl	<No override>	extension/community_design/design/suncana/templates/content/datatype/view/ezxmltext.tpl
14	content/datatype/view/ezxmltags/paragraph.tpl	<No override>	extension/ezwebin/design/ezwebin/templates/content/datatype/view/ezxmltags/paragraph.tpl
7	content/datatype/view/ezxmltags/line.tpl	<No override>	design/standard/templates/content/datatype/view/ezxmltags/line.tpl
1	content/datatype/view/ezxmltags/literal.tpl	<No override>	extension/community/design/standard/templates/content/datatype/view/ezxmltags/literal.tpl
1	print_pagelayout.tpl	<No override>	extension/community/design/community/templates/print_pagelayout.tpl
Number of times templates used: 36 Number of unique templates used: 7

Time used to render debug report: 0.0001 secs