How to remotely recover text from PHP messages in jquery.validate

Asked

Viewed 88 times

2

Friends, I would like to know how to remotely recover text from PHP messages in jquery.validate.

$('#ajax_form_inclusao').validate({
    rules : {
        numeroContrato : {
            required : true
        },
        dataInicial : {
            required : true,
            dateTimeBR : true
        },
        dataFinal : {
            required : true
        },
        valorPF : {
            required : true
        },
        qtdPFContratado : {
            required : true
        },
        status : {
            required : true
        }
    },
    messages : {
        numeroContrato : {
            required : errorMessages.E2
        },
        dataInicial : {
            required : 'Preencha o campo Data Inicial'
        },
        dataFinal : {
            required : 'Preencha o campo Data Final'
        },
        valorPF : {
            required : 'Preencha o campo ValorPF'
        },
        qtdPFContratado : {
            required : 'Preencha o campo Quantidade de PF Contratado'
        },
        status : {
            required : 'Selecione uma opção para o campo Status'
        }
    },
    submitHandler : function(form) {

I would just like to put all the system messages in a single central file and recover the text of the messages in the scripts.

  • I have a question so I can give you the best possible answer. What is the purpose of receiving the text of validate php? You want to make it easier to handle these errors in php?

  • @Erloncharles He wants to have the error messages centralized so he doesn’t have to rewrite it on the server-side.

  • The ideal would be to have centered on server and carry them on client, so it’s a much better way to maintain, otherwise it’s much less efficient and complicated to maintain.

1 answer

1

You nay need to do server-side validations. To simplify, there is no need to have it on the server side because it does not work with the presentation. If you do so, you will enter a conceptual hiatus.

The natural mechanism of jQuery Validation, first, does not support - natively - this type of operation. In short, you will not be able to pass from client to server such error message - good, because it doesn’t make any sense.

What you could do is: through submitHandler from jQuery Validation, send - with JSON - an error number to there on the server, search in a database the message corresponding to the requested number and then return to the view. If you do so, it will have the desired effect: a centralized repository of error messages.

Is centralizing these messages good? Theoretically yes. It is necessary? Not.

Dual-hand validation is required yes, but invoking an error in the message format towards the server is not convenient. Ah, but what if the client disables Javascript? It’s like I said, you just shouldn’t invoke messages, but continue to validate so that the requested action is not processed.

But William, I still don’t understand why I can’t pass on the client’s message to the server.

The message is for the customer. In this specific case of validation, it is born in the client and stays there. The server-side nay has to deal with the presentation part - only and should only be a catalyst that propagates information of routes, but he is mathematical - can not paint a picture or write a book; only deals with numbers, the bureaucratic part. Like I said, this is conceptual murder.

I think that I understood. But what if I still want to do?

jQuery Validation will not have a native tangible solution.

In the old days, when I wanted to do the same thing as you, I created a database to store multiple messages to their identifiers (ids) and when I wanted to rescue them [the error messages], I made a request - asynchronous, with AJAX - to search in my "repository" and as soon as found, indicated that my action passed the information obtained to view again.

Anyway, the above process I no longer think much more valid today. Your going from customer to serivdor is, in the mine opinion, even worse. Therefore, avoid.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.