This would massively reduce code base on a number of apps

Alternatively we could have "application validations" if such a thing is not suitable for a page 0 implementation.

It's basically an application process which fires at the validation stage that we are after.

It's so we can have a common validation process based on managed config data which reports such validation errors alongside those that are defined explicitly in the pages, rather than having 2-stages of validation error notifications on screen,

What exactly is being validated? Could this be something handled by a page sentry function? Could the logic be consolidated to a parameterized package and referenced as needed?

Hi Tyson, 

  The validations would be similar to validations done in the Page Validations, if an item is not null, if the value of the item has certain format, etc. This generic-function would know what app-page it is being submitted so it would only validate configured items from those pages.

  The solution we are implementing for now, is a page-function where we will have only 1 validation per page, and configurations will make sure the functions validates what is needed. 

  The advantage of having this in only one place (page 0 or app-process) is that the maintenance becomes much easier.

Thanks,
Alejandro

OK that makes sense. So rather than configuring validation in the application instead validation would be configured and managed in the database. 

One way this could be achieved today would be to build a item plugin which renders a hidden item to the page and invokes your validations. This would allow you to manage your validations in the database, have a single point of definition, and supply the message back in a way APEX is expecting. If in the future a better solution is provided by the APEX team then it would be easy to remove the hidden item from page 0 and use the new method.

I hope this helps!  

function my_custom_validation(
    p_app_id  number,
    p_page_id number
) return varchar2
is
begin
  return apex_string.format('Validaton error in application %0 page %1',p_app_id, p_page_id);
end;

procedure item_render (
    p_item   in            apex_plugin.t_item,
    p_plugin in            apex_plugin.t_plugin,
    p_param  in            apex_plugin.t_item_render_param,
    p_result in out nocopy apex_plugin.t_item_render_result )
is
    -- constants
    -- c_escaped_value constant varchar2(32767) := apex_escape.html(p_param.value);
    c_escaped_name  constant varchar2(32767) := apex_escape.html(p_item.name);
begin
      htp.p('<input
            type="hidden"'||
            apex_plugin_util.get_element_attributes(
              p_item => p_item,
              p_name => c_escaped_name,
              p_default_class => '',
              p_add_id => true, -- required so validations fire
              p_add_labelledby => false, 
              p_aria_describedby_id => '' 
            )|| '>');
end item_render;

procedure item_validation (
    p_item   in            apex_plugin.t_item,
    p_plugin in            apex_plugin.t_plugin,
    p_param  in            apex_plugin.t_item_validation_param,
    p_result in out nocopy apex_plugin.t_item_validation_result )
is
begin
  p_result.display_location := apex_error.c_inline_in_notification;
  p_result.message := my_custom_validation( p_app_id => :APP_ID, p_page_id => :APP_PAGE_ID );
end item_validation;

Hi @alejandro.suarez , the APEX team discussed this idea today. The idea of adding more logical components (validations, processes) to page zero is unlikely to happen, however something that would make more sense from a declarative perspective is to have shared validations in shared components. Then page items could be associated to a shared validation. 

We decided to close this idea since the implementation proposal is too different.