Additionally, the mak:submit can help rendering submit buttons and links for submitting a form.
Page sections that can be shown, hidden or reloaded via events#
Let us consider the following example:
<mak:section name="employees" reloadOn="employeesChanged"> <mak:list from="company.Employee e"> <mak:value expr="e.name"/> <mak:value expr="e.surname"/><br /> </mak:list> </mak:section> <br /> <button onClick="mak.event('employeesChanged')">Reload list of employees</button>
In this example, the mak:section contains a list of employees. If for some reason, we would like to reload this list, but without reloading the whole page, this can be achieved by triggering the employeesChanged event.
This can be achieved by using the mak.event(eventName) method.
A <mak:event> tag will be available later on in order to trigger events in an easier fashion, using pre-defined widgets such as links and buttons.
Sections can only be inside of a mak:list, in which case it might be intended to address only a specific iteration of the list when an event is triggered, instead of all the sections rendered by the iterations.
In this case, one specific section inside of a mak:list can be uniquely identified using a MQL expression:
<mak:list from="company.Employee e"> <mak:section name="nameSurname" reloadOn="employeeRenamed" iterationExpr="e"> <mak:value expr="e.name"/> <mak:value expr="e.surname"/><br /> </mak:section> <button onClick="mak.event('employeeRenamed', '<mak:value expr="e" />')">Reload this employee</button> </mak:list>
The iterationExpr attribute of the mak:section tag should contain a MQL expression that can uniquely identify one sections of the tag (in the example above, the primary key of the Employee is used). This expression should be used in order to address the particular iteration in the mak.event(eventName, expressionValue) method call.
If an iteration expression does not lead to unique results, all the sections matched by it will be addressed.
If no iteration expression is provided, all the sections rendered by the iterations will be addressed.
When a section is reloaded, a wheel is displayed until the data is rendered. This behavior can be altered by changing the class of the .sectionReload CSS style.
In the future, it should be possible to specify different kind of effects in which a section should hide, show, or reload itself.
Partial post-back of forms#
It is possible to submit makumba forms via partial post-back, by giving a value to the triggerEvent attribute:
<mak:newForm type="company.Employee" triggerEvent="employeeCreated"> Name: <mak:input field="name" /><br/> Surname: <mak:input field="surname" /><br/> <br/> <mak:submit>Create employee</mak:submit> </mak:newForm> <mak:section name="employees" reloadOn="employeeCreated"> <mak:list from="company.Employee e"> <mak:value expr="e.nameSurname()" /><br/> </mak:list> </mak:section>
In this example, when the newForm has been submitted successfully, the "employeeCreated" event is fired. The employees section is reloaded as a result, since it has a reloadOn attribute set on this event.
It is not necessary to use <mak:submit>. Indeed, a simple <input type="submit" value="Create employee"> achieves the same result here, as makumba listens and intercepts form submission.
If an error occurs when the form is submitted via partial post-back, the same kind of mechanism that takes place for normal form submission happens:
- by default, any form submission message is displayed above the form
- if form annotation is activated via the annotation attribute, error messages will be displayed next to the field leading to an error, or on top of the form if the error spans over more than one field
- if client side validation is enabled, the form will not submit until all errors are corrected
The form messages are in HTML DIV elements that have the CSS classes makumbaResponder and makumbaSuccess/makumbaError.