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
