Welcome to the JavaRanch, Preethi!
That's not really how
JSF is intended to work.
JSF is a lot like the old mainframe "green screen" applications in that you fill out a form and submit the form as a
unit. JSF will validate the data on the form and either accept or reject the data as a unit. If it accepts it, the backing bean(s) are updated and the action method is invoked. If, on the other hand, even one item on the form is rejected, the entire form is rejected, error message(s) are posted to the JSF messages object (where they can be displayed) and the form is re-displayed. Only when the data is 100% valid will processing occur.
You can alter this behavior with AJAX, but AJAX does basically the same thing, except that it effectively creates a subset form with only a few values in it instead of all of them and conversely updates only selected parts of the display instead of completely rewriting it.
Having said that, I doubt that this will work:
For one thing, because it's attempting to put server-side constructs on the client side (View Template) and there's no accessibility.
You might try referencing a backing bean property that returns the empty/non-empty status of the message list, but there's one problem. The backing bean isn't touched if there are validation errors.
Truthfully, I think that you're better off leaving the commandButton unconditionally enabled and let JSF do what it was designed to do.
The cases where a commandButton's enablement is controlled client-side tend to be things like ensuring that required fields have values in them and certain limited constraints in data format are met, Stuff that's done in JavaScript, not in JSF. And even then it can be tricky, since JSF really doesn't like it when the visibility or enablement of JSF controls is done via client-side logic.