cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <...@keow.org>
Subject Re: CForms: merge of 2.1 and 2.2 branches
Date Mon, 08 Nov 2004 15:51:27 GMT
On Thu, Nov 04, 2004 at 11:33:53AM +0100, Sylvain Wallez wrote:
> Done, I've committed the two-way merge of CForms.
> 
> However, there are some items that I have not synchronized:
> - form.fireEvents in Form.js: why is it needed? The form object buffers 
> events only during the readFromRequest phase, and otherwise always 
> broadcasts them immediately

This one is puzzling me.  I had a case where events generated
before sending a page were not fired until after a POST was
received.  Looking at the code again, I do not see how this
could happen, so I will have to keep searching...

Btw, we seem to have a bug in our value-changed event generation.
For example, in Field.java we do not generate a value-changed
event when the value goes from non-null to null, because our
event generation code is wrapped in the same "if" construct as
we use to determine if the value should be validated.

> - field.removeSelectionList: there's a big problem behind it, as it 
> calls definition.setSelectionList(null). It's important that widget 
> definitions be *immutable* as they a reused for different instances of a 
> form.

We could implment this correctly via:
  this.selectionList = new EmptySelectionList(null);
Then the definition would rightly be treated as immutable.
Should we do this and keep the new removeSelectionList method,
or should we just make the calling code explicitly use:
  setSelectionList(new EmptySelectionList(null);
and remove the new method?

> - getProcessMyRequests: we have to see how this relates to widget states.

Discussion going on in other threads.

> - ft:choose: we've talked about it already, and I removed it until we 
> know more about Tim's experiments.

Discussion going on in other threads.

> A few questions, also:
> - no generation of fi:union and fi:struct: does it have to be removed at 
> template execution level, or should it be filtered by the XSLs? In other 
> words, can the stylesheets do something useful with it? If we consider 
> that fi:struct can be renamed to fi:group, we obtain at the form 
> definition level the "instance-only" fi:group we have today to build 
> tabbed forms and automatic layout.

I found no use for these elements, did anybody else?  The fi:group
idea is interesting, but I wonder if it would cause more trouble
than it is worth?  Specifically, how would you handle when grouping
in the model does not match the view-designer's idea of grouping in
the template?

> - what's the difference between "nestedHandler" and "skipHandler"?

"nestedHandler" is not used anymore and really should be removed.
The difference is that the skipHandler suppreses output of the
current start and end element events, while the nestedHandler does
copy them to the output.  In other words, the nestedHandler wrongly
let elements in the "ft" namespace slip through to the output.

> - <ft:widget id=""> now considers not only child widgets, but also paths 
> using lookupWidget(). That's a good idea, but now the "id" is no more an 
> identifier in the strict meaning of the word. Should we rename it to 
> <ft:widget ref=""> (with the additional meaning that it _references_ a 
> widget in the form definition), or leave it as is?

While the behaviour has been changed, the id never was a strict
identifier, because we have been using relative id's, thus they
never were guaranteed to be globally unique within the template
file.  "ref" _might_ be a better attribute name (I just don't
know) but this switch to lookupWidget() did not change the
situation but rather only made it more apparent, iiuc.

--Tim Larson

Mime
View raw message