cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: CForms view model? (was Re: Externalizing JXTG tag configuration)
Date Wed, 11 May 2005 15:28:38 GMT
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


Mime
View raw message