Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
<snip/>
Can you elaborate? What should be the "view model"
The view model should IMO be a (minimal) read only subset of o.a.c.forms.formmodel.Widget and ContainerWidget, preferably POJO friendly. From such a view point the widget hierarchy is a simple tree of beans with some properties in each widget. Such a structure would be quite easy to render from a simple template language even without special purpose macros (although they would make it more convenient).
Aren't today's widgets enough for this? You have getValue(), getValidationError(), etc. Maybe an additionnal "Map getChildren()" to allow for "widget.children.foo" is needed, but what else?
I think it is quite ok as is, although the amount of utility code in JXMacrosHelper says that there we could do some more work either on the form or template side.
Sometimes I have felt that we should split the widget interface in some sub interfaces, where a "view" interface containing the read only subset described above would be one part. The point with this would be that it would make the forms framework more pluggable. We had some discussions about this half a year ago, when Jonas Ekelund had some ideas about a more lightweight backend. But blocks and templating is higher on my priority list so I'm not going to pursue this.
and why producing SAX events is a mixing of concerns?
It would not nececarilly be a mix of concern, but in CForms it IMO is because the Widget mainly is about content in the form of Java data structures, but it also make some presentation details (the label) available through SAX. The mix of Java data structure and SAX production makes it harder to use from e.g. a template language.
Hmm... I don't agree here. Besides label (which BTW is optional), the SAX production of widgets is mostly (if not always) used for leaf widgets, whose rendering isn't managed by the template, but by the XSLs that come after in the pipeline.
I think that CForms would be simpler if we removed the SAX generation from the widgets and made SAX generation the responsibility of e.g. the template language.
Aha! Responsibility of template _language_ is good, as I was afraid it would be the template _writer_'s responsibility. Now what's the difference from the user's POV?
No difference at all from the user's POV, its mainly to make it easier to maintain CForms template language and make it easier to plug in another one (XForms).
The ugliness of jx-macros.xml is related to the lack of some templating structure (see the "cformsDummy"),
Most (all?) uses of cformsDummy seem to be related to SAX generation, that could be solved with using XMLizable in the CForms api as Vadim suggests.
Are there more (general purpose) constructions that you would need?
but other than that, this set of macro just does some traversal of the widget tree along with producing a few SAX events for container widgets or delegating their production to leaf widgets. Is it this delegation that you consider a problem?
Yes, it is the delegation I don't like. The problem becomes smaller with Vadim's suggestion, but I'm not to happy in having a model that mixes tree traversal with SAX generation. I would prefer to have a pure tree model followed by a SAX serialization step.
But this is not that important for me ATM. The reason that I started the discussion was that if we should fix the non broken jx-macros.xml at all, I think there are better ways than rewrite it in pure Java.
/Daniel
