Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
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.
Depending on how it's done, it can be a good thing. IMHO,
public XMLizable getLabel();
seems like a right approach to me; and templating language should be more than happy to work with XMLizable objects, so to render a label you don't need anything more than:
#{widget/label}
Interesting idea, but which questions the actual need for a form template language, as <ft:widget id="foo"/> could be equally written ${form.foo}.
IMO we shouldn't go that far. A problem of flowscript is that its programmatic power forbids writing graphical tools to visually layout the page flow. By removing the form template language, we would similarily forbid the use of visual tools (e.g. dreamweaver or htmlarea extensions) to define a form template.
The mix of Java data structure and SAX production makes it harder to use from e.g. a template language.
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.
IMHO, if done right (see above), cforms can generate sax events.
Agree, although we have to be careful not going to far on this route.
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
