Vadim Gritsenko wrote:
Marc Portier wrote:
- in fact it also struck me that the @readonly concept only allows us to choose between two modes of operation : 1/ do load AND save 2/ do only load. Maybe we should provide a generic attribute on all bindings that looks like @direction and can hold load|save|both (probably even implement this at the level of the abstract base class?)
I'm curious... What is the usecase for "writeonly" binding?
hm, I have to admit it was more an academic observation in terms of it being two equivalent methods that really do (should) not impose any assumed orchestration between both?
in any case this is not about the complete binding action of the WHOLE form where you can just choose not to call the load and save actions from your controller (flowscript)
it really is about having the possibility on the level of each sub-binding to enable or disable any direction in the event of load or save being called on the complete form.
so use cases coming to mind : 1/ not to be disclosed back-end info, e.g. password or visa
But I have to admit that my advise would be to make sure that the backend is not disclosing this in the first place, so if the back-end sets it to null then you _could_ safely LOAD that data anyway
so, the addition here would only slightly improve performance :-P
but I did find a better case to save my ass here :-)
(and I think it is useful)
2/ you want to preserve the original data and ADD the new stuf to the backend model
so at some level you would have a context binding for /root/something
with two nested bindings that alternatively work during load or save, so you can
load from ./original save to ./updated
resulting into a backend-model with distinct root something original updated
Good examples. But I'm not sure I like "direction" attribute. Can we just add "writeonly" attribute, in addition to "readonly"?
Vadim
