[Question] Re: cforms plans, templating engines, etc.

[Tim Larson <ti...@keow.org>]

On Sun, Nov 07, 2004 at 09:29:40PM +0100, Sylvain Wallez wrote:
> Tim Larson wrote:
> >On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote:
> >>Tim Larson wrote:
> 
> >concerns before.  I will try to take some time this weekend
> >to see how to resolve this.  I really do not want to revert
> >the code if we can just improve it instead.  I just feel
> >pressured by the short time before we plan to release.
> 
> So let's discuss your concerns. I started looking at Swan, and it seems 
> to me that what's needed is simply and additional "output" state.
> 
> Do you want me also to explain more clearly how states are implemented 
> and behave (lacked the time to write some docs)?

I finaly got to look at the widget states implementation,
and even port parts of Swan to use it (working on porting
the rest now).  I see some things we can improve, but it
looks good overall because of the separation between how
we set states and how we query them.  This will allow
us to add more fine-grained state setting logic without
disturbing existing state querying logic (if we find we
need these changes in the future.)  I will comment on
the possible improvements later when I have collected
my thoughts more, since they should not affect back-
compatibility anyways.

[Question:]
http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=109994348811745&w=2
Is this change acceptable for keeping in the trunk and
including in the stable branch?  (The part about changing
from isAcceptingInputs() to isValidatingValues() in
the widgets' validate() methods?)  Currently both methods
will return the same value, but this will allow us to
split the logic later if needed.

> Well, you've got a point here: yes, you should probably explain more 
> what you want to do. The group's feedback will strengthen the ideas and 
> turn them into a collective creation rather than a one-man show.

Agreed.  I will update my wiki page to explain my current
plans, so they can be discussed, changed, and improved :)

> Well, I only saw changes to the template transformer, and no 
> corresponding change in the form model, hence my impression you were 
> writing a new template language. I also do not consider the 
> WoodyScratchpad page a formal specification: we discussed for a while 
> there, wrote down some ideas, and let them apart for quite a long time 
> with still a lot of open questions and things to formalize.

> Great, I'm glad we solved some misunderstandings :-)

Me too :)

--Tim Larson

Re: [Question] Re: cforms plans, templating engines, etc.

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

Tim Larson wrote:

>On Wed, Nov 10, 2004 at 08:54:33PM +0100, Sylvain Wallez wrote:
>  
>
>>Tim Larson wrote:
>>    
>>

<snip/>

>>>I finaly got to look at the widget states implementation,
>>>and even port parts of Swan to use it (working on porting
>>>the rest now).  I see some things we can improve, but it
>>>looks good overall because of the separation between how
>>>we set states and how we query them.
>>>      
>>>
>>Do you mean the distinction between getState() and getCombinedState()? I 
>>implemented it that way because I felt that we may need to now the 
>>actual state of a widget and not always the combination with it's parent 
>>state according to the state priority rules.
>>    
>>
>
>Yes, I like the the getState()/getCombinedState() split,
>and also the split between how we set a state (currently
>all attributes at once: readable, writeable, styling hint)
>versus how we query the state with isXXX (quering the
>attributes individually.)  This will permit us to later
>allow setting the different attributes independently
>(if the need develops.)
>
>  
>
>>>This will allow
>>>us to add more fine-grained state setting logic without
>>>disturbing existing state querying logic (if we find we
>>>need these changes in the future.)  I will comment on
>>>the possible improvements later when I have collected
>>>my thoughts more, since they should not affect back-
>>>compatibility anyways.
>>>      
>>>
>>Ok, waiting :-)
>>    
>>
>
>The most visible problem is that getCombinedState() is
>called several times per widget, and (iiuc) it climbs
>up to the root of the widget tree on each call.  This
>would be rather inefficient for a deeply nested form,
>such as an xml editor.  Perhaps we should reverse and
>cache the updates, having a parent notify its children
>when its state changes?  This would cut the number of
>tree passes considerably, at the cost of some memory
>use for caching the combined states.
>  
>

I thought about this problem when implementing states, and wanted to add 
a "parentStateChanged()" method to the Widget interface, so that a 
container could notify its children that some state change happened in 
the upper levels, for them to recompute their combined states.

I decided however not to add it as it seemed to me like letting the 
internal state computing machinery appear on the general widget 
interface. The state combination is very lightweight (comparing two 
integers) and my feeling was that it should only become visible in very 
large and very deep structures.

This is something we can add now or later with no other impact than this 
new parentStateChanged method.

BTW, for something really inefficient, have a look at getParameterName() 
before updating SVN: the string concatenation occurs at each call when 
we know that, contrarily to states, a widget path never changes! I just 
changed it so that computation occurs only once.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: [Question] Re: cforms plans, templating engines, etc.

[Tim Larson <ti...@keow.org>]

On Wed, Nov 10, 2004 at 08:54:33PM +0100, Sylvain Wallez wrote:
> Tim Larson wrote:
> >On Sun, Nov 07, 2004 at 09:29:40PM +0100, Sylvain Wallez wrote:
> >>Tim Larson wrote:
> >>>On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote:
> >>>>Tim Larson wrote:
> >>>>
> >>>concerns before.  I will try to take some time this weekend
> >>>to see how to resolve this.  I really do not want to revert
> >>>the code if we can just improve it instead.  I just feel
> >>>pressured by the short time before we plan to release.
> >>>
> >>So let's discuss your concerns. I started looking at Swan, and it seems 
> >>to me that what's needed is simply and additional "output" state.
> >>
> >>Do you want me also to explain more clearly how states are implemented 
> >>and behave (lacked the time to write some docs)?
> >
> >I finaly got to look at the widget states implementation,
> >and even port parts of Swan to use it (working on porting
> >the rest now).  I see some things we can improve, but it
> >looks good overall because of the separation between how
> >we set states and how we query them.
> 
> Do you mean the distinction between getState() and getCombinedState()? I 
> implemented it that way because I felt that we may need to now the 
> actual state of a widget and not always the combination with it's parent 
> state according to the state priority rules.

Yes, I like the the getState()/getCombinedState() split,
and also the split between how we set a state (currently
all attributes at once: readable, writeable, styling hint)
versus how we query the state with isXXX (quering the
attributes individually.)  This will permit us to later
allow setting the different attributes independently
(if the need develops.)

> >This will allow
> >us to add more fine-grained state setting logic without
> >disturbing existing state querying logic (if we find we
> >need these changes in the future.)  I will comment on
> >the possible improvements later when I have collected
> >my thoughts more, since they should not affect back-
> >compatibility anyways.
> 
> Ok, waiting :-)

The most visible problem is that getCombinedState() is
called several times per widget, and (iiuc) it climbs
up to the root of the widget tree on each call.  This
would be rather inefficient for a deeply nested form,
such as an xml editor.  Perhaps we should reverse and
cache the updates, having a parent notify its children
when its state changes?  This would cut the number of
tree passes considerably, at the cost of some memory
use for caching the combined states.

> >[Question:]
> >http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=109994348811745&w=2
> >Is this change acceptable for keeping in the trunk and
> >including in the stable branch?  (The part about changing
> >from isAcceptingInputs() to isValidatingValues() in
> >the widgets' validate() methods?)  Currently both methods
> >will return the same value, but this will allow us to
> >split the logic later if needed.
> 
> Good idea. The various isXXX methods on WidgetState are meant to avoid 
> direct reference to actual state constants within the code. That firstly 
> avoids inconsistencies and also allow later extension if needed (once 
> again, I think we'll need to add an "output" state).
> 
> So go on merging in the stable branch!

Ok :)

> >>Well, you've got a point here: yes, you should probably explain more 
> >>what you want to do. The group's feedback will strengthen the ideas and 
> >>turn them into a collective creation rather than a one-man show.
> >
> >Agreed.  I will update my wiki page to explain my current
> >plans, so they can be discussed, changed, and improved :)
> 
> Good idea, but rather than your page or WoodyScratchpad, what about a 
> new CFormsScratchpad or a [RT] so that we can all work collaboratively 
> towards well-defined evolutions?

Yes, that sounds like a better way.

--Tim Larson

Re: [Question] Re: cforms plans, templating engines, etc.

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

Tim Larson wrote:

>On Sun, Nov 07, 2004 at 09:29:40PM +0100, Sylvain Wallez wrote:
>  
>
>>Tim Larson wrote:
>>    
>>
>>>On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote:
>>>      
>>>
>>>>Tim Larson wrote:
>>>>        
>>>>
>>>concerns before.  I will try to take some time this weekend
>>>to see how to resolve this.  I really do not want to revert
>>>the code if we can just improve it instead.  I just feel
>>>pressured by the short time before we plan to release.
>>>      
>>>
>>So let's discuss your concerns. I started looking at Swan, and it seems 
>>to me that what's needed is simply and additional "output" state.
>>
>>Do you want me also to explain more clearly how states are implemented 
>>and behave (lacked the time to write some docs)?
>>    
>>
>
>I finaly got to look at the widget states implementation,
>and even port parts of Swan to use it (working on porting
>the rest now).  I see some things we can improve, but it
>looks good overall because of the separation between how
>we set states and how we query them.
>

Do you mean the distinction between getState() and getCombinedState()? I 
implemented it that way because I felt that we may need to now the 
actual state of a widget and not always the combination with it's parent 
state according to the state priority rules.

>This will allow
>us to add more fine-grained state setting logic without
>disturbing existing state querying logic (if we find we
>need these changes in the future.)  I will comment on
>the possible improvements later when I have collected
>my thoughts more, since they should not affect back-
>compatibility anyways.
>  
>

Ok, waiting :-)

>[Question:]
>http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=109994348811745&w=2
>Is this change acceptable for keeping in the trunk and
>including in the stable branch?  (The part about changing
>from isAcceptingInputs() to isValidatingValues() in
>the widgets' validate() methods?)  Currently both methods
>will return the same value, but this will allow us to
>split the logic later if needed.
>  
>

Good idea. The various isXXX methods on WidgetState are meant to avoid 
direct reference to actual state constants within the code. That firstly 
avoids inconsistencies and also allow later extension if needed (once 
again, I think we'll need to add an "output" state).

So go on merging in the stable branch!

>>Well, you've got a point here: yes, you should probably explain more 
>>what you want to do. The group's feedback will strengthen the ideas and 
>>turn them into a collective creation rather than a one-man show.
>>    
>>
>
>Agreed.  I will update my wiki page to explain my current
>plans, so they can be discussed, changed, and improved :)
>  
>


Good idea, but rather than your page or WoodyScratchpad, what about a 
new CFormsScratchpad or a [RT] so that we can all work collaboratively 
towards well-defined evolutions?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }