CForms view model? (was Re: Externalizing JXTG tag configuration)

[Sylvain Wallez <sy...@apache.org>]

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" and why producing SAX 
events is a mixing of concerns? No flame intended, I'm really curious 
and interested.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director

Re: CForms view model? (was Re: Externalizing JXTG tag configuration)

[Sylvain Wallez <sy...@apache.org>]

Daniel Fagerstrom wrote:

> Sylvain Wallez wrote:
>
>> Vadim Gritsenko wrote:
>
>
> <snip/>
>
>>> 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.
>
>
> IMO these are different concerns. The fact that you could write 
> ${form.foo}, instead of <ft:widget id="foo"/> doesn't mean that we 
> have to take away <ft:widget id="foo"/> or any tools support.
>
> I think the advantages of using XMLizable are so big that we should go 
> that way.


+1.

Along with writing the Tree widget, I'm writing a proposal to refactor 
the CForms API, which unfortunately will bring some backwards 
incompatibility but will make it way more template-friendly.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director

Re: CForms view model? (was Re: Externalizing JXTG tag configuration)

[Daniel Fagerstrom <da...@nada.kth.se>]

Sylvain Wallez wrote:

> Vadim Gritsenko wrote:

<snip/>

>> 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.

IMO these are different concerns. The fact that you could write 
${form.foo}, instead of <ft:widget id="foo"/> doesn't mean that we have 
to take away <ft:widget id="foo"/> or any tools support.

I think the advantages of using XMLizable are so big that we should go 
that way.
/Daniel

Re: CForms view model? (was Re: Externalizing JXTG tag configuration)

[Sylvain Wallez <sy...@apache.org>]

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

Re: CForms view model? (was Re: Externalizing JXTG tag configuration)

[Vadim Gritsenko <va...@reverycodes.com>]

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}


> 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.

Vadim

Re: CForms view model? (was Re: Externalizing JXTG tag configuration)

[Daniel Fagerstrom <da...@nada.kth.se>]

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

Re: CForms view model? (was Re: Externalizing JXTG tag configuration)

[Sylvain Wallez <sy...@apache.org>]

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

Re: CForms view model? (was Re: Externalizing JXTG tag configuration)

[Daniel Fagerstrom <da...@nada.kth.se>]

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).

> 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.

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.

> No flame intended, I'm really curious and interested.

Glad that you take it that way :)

/Daniel