Ticket #58 (new defect)
kauri forms model should be injected from an external file
| Reported by: | mpo | Owned by: | mpo |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.5 |
| Component: | modules/kauri-forms | Version: | trunk |
| Keywords: | Cc: |
Description
possible strategies:
[1] use <script></script> tag
Note however that more then one form can be present on a page. This would suggest we have some agreed variable (e.g. at $.org.kauriproject.forms.pageforms) holding a (possibly growing) structure of {'id' : {/*formconfig*/} , ...}
The model and template of multiple forms on a page can then be matched up by id.
Extra add-to would be that we can even just auto-configure the forms base on this variable.
[2] use $ajax call
Other approach would be to only pass the reference to the form-model and let that be downloaded upon construction of the new Form(id, modeluri)
Async behaviour is somewhat tricky in this sense IMHO.
Change History
comment:2 Changed 4 years ago by mpo
Could you clarify what you mean with context?
IIRC The data-uri currently is already seen as a uri-template.
I am thinking we should have an easy way to provide some page-scope variables to point to
- current locale
- the public URI of 'main' and other public restservices ('data' at least)
maybe we should just hook them up under the $.kauri namespace? (see #200)
And then provide some way for that context to be available in the uri-template context so the uri's can be written as
"{kauri.pagecontext.uri.data}/person/{id}?lang={kauri.pagecontext.locale}"
or something along those lines (just thinking out loud)
The form model should indeed better be a static file, separate from the page, which would bring the following advantages:
One issue to tackle is that the fconf currently contains various URLs: the data submit URIs, but also selection control URIs. We should foresee the ability to inject context into that (is currently already the case?)