Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
<snip/>
to implement cforms instructions instead of jx-macros.xml file which looks quite ugly because of hacks that had to be made to implement it.
This will also speed up forms processing.
I'm afraid that I'm not going to be helpfull at all ;) First, to me it seem like you suggesting something that part of the community was strongly against. If you want to implement it you have to ask if people have changd their minds or explain how your proposal is different from what people where against and ask if it is ok.
Second, the ugliness in jx-macros should IMO be handled by making CForms more template friendly (and maybe we lack some functionality in JXTG). From my POV a form package should contain a view model. And the view model should be easy to traverse and render for a simple template language. The fact that CForms isn't easy to traverse and render means IMO that there are more work to do in CForms. As an example it is IMO a mix of concern to let CForms generate SAX.
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?
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? The ugliness of jx-macros.xml is related to the lack of some templating structure (see the "cformsDummy"), 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?
No flame intended, I'm really curious and interested.
Glad that you take it that way :)
I added this little note to be sure I wouldn't be misunderstood :-)
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
