decouple form layout from operation

[cristi@…]

forms can become a bit less coupled to their operation

<mak:form type="best.Student" operation="new" >

behave exactly like a newForm

the operation of a form may be variable (operation="$op")

that would finally let us use the same code for new and edit forms

also, if more than the CRUD operations are defined for the type (in MDD or thru JSP operations), separating operation also makes a lot of sense

[manuel@…]

as I went through the forms code, here are more thoughts on this:

- decoupling makes sense for new, edit and perhaps add operations (if e.g. wanting to edit set entries of the same kind as the ones added), but probably not for delete (which does not take input fields) and search (which does take a totally different set of tags/fields as input, i.e. there's not much potential of code reusage with this kind of forms)

- one common and very useful application would be

<mak:form type="best.Student" operation="$op">

common fields

</mak:form>

to be called with op being either new or edit. however, the problem here is that edit forms need to be enclosed in a query (list or object). yet this query would not render any results in case of new (because no object exists as yet).

one possible design would be

<mak:form type="some.Type" operation="$op" object="$pointer">

if op is edit, $pointer would be used in combination with type in order to infer the record. however that means that mak:form will have to make the query.

this may be achieved by enhancing the FormDataProvider? which provides data for the forms and already registers queries in particular contexts such as the new form.

the obvious drawback is that queries would be really simple, i.e. $pointer would always have to be of type some.Type. that is, I would argue that this would always be the case in this kind of setting, or we can just say this is the usage constraint.

- addForm re-usage experiment:

<mak:form name="parent" operation="$parentOp" type="some.Type" object="$object">

<mak:form operation="$op" object="parent" field="innerSet">
...
</mak:form>

...
</mak:form>

so here, submitting the page with parentOp = new and op = add would yield to a addForm inside of a newForm, and parentOp = edit, op = edit to an editForm on object.innerSet inside of an editForm - only that given that innerSet is indeed a set it would mean that in that kindof setting, a list would be generated around the inner mak:form, which may be rather confusing.

==> it doesn't look to me that the above design is very suitable to code re-usage with addForms.

---

in order to de-couple form operation and form layout someone could think of

<mak:formLayout name="some" type="some.Other">

... input fields ...

</mak:formLayout>

<mak:form operation="edit" layout="some" ...>
...
</mak:form>

this brings us again very close to templating as we could also say that formLayouts can be in their own JSP file if the same layout is re-used across many JSPs. then of course, it might be questionalble whether

<mak:form operation="edit">

<jsp:inlcude = "myLayout.jsp />

</mak:form>

would not make more sense.