Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
In fact we can call it: isValidKey(...) <--- I prefer this one over the below name. isValidUniqueRowId(...) The other names are too specific to what the function do. Sometimes it is good to call the functions by what solve and not by how is the internal implementation (using List, Set or whatever). WDYT? Best Regards, Antonio Gallardo. Joerg Heinicke dijo: > On 04.03.2004 09:31, Sylvain Wallez wrote: > changed isNullAllListElements() => isAnyListElementNotNull(): the duplicate negation at usage time breaks my brain ;-) >>> >>> This depends of the POV you see it: >>> >>> isNullAllListElements() -> This is not a negation. It check if : >>> >>> All elements on the List are null. Where is the negation? >>> >>> isAnyListElementNotNull() -> Here is a negation "Not null" :-D > > Hmm, that's true. But what I meant was the usage of > !isNullAllListElements and ListElement != null inside the function. > > What you are really testing for is the availableness/usability of the > list for unique identification. So the function itself should not return > true if it only contains nulls. > >> Generally speaking, negative forms should be avoided, as their >> interpretation may be difficult depending on people's linguistic >> background. I used to work with Japanese people long time ago, and I'm >> sure this name, even with a single negation, would be very hard for them >> to understand. >> >> So what about "hasNonNullElements()"? > > Yes, this might be more obvious/understandable than "any" and "not" in > my version. > > Joerg >
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
On 04.03.2004 09:31, Sylvain Wallez wrote: changed isNullAllListElements() => isAnyListElementNotNull(): the duplicate negation at usage time breaks my brain ;-) This depends of the POV you see it: isNullAllListElements() -> This is not a negation. It check if : All elements on the List are null. Where is the negation? isAnyListElementNotNull() -> Here is a negation "Not null" :-D Hmm, that's true. But what I meant was the usage of !isNullAllListElements and ListElement != null inside the function. What you are really testing for is the availableness/usability of the list for unique identification. So the function itself should not return true if it only contains nulls. Generally speaking, negative forms should be avoided, as their interpretation may be difficult depending on people's linguistic background. I used to work with Japanese people long time ago, and I'm sure this name, even with a single negation, would be very hard for them to understand. So what about "hasNonNullElements()"? Yes, this might be more obvious/understandable than "any" and "not" in my version. Joerg
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
Sylvain Wallez dijo: > Antonio Gallardo wrote: > >>[EMAIL PROTECTED] dijo: >> >> >>>joerg 2004/03/03 11:47:35 >>> >>> Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding >>>RepeaterJXPathBinding.java >>> Log: >>> clean up: removed unused code (for reverting changes we have CVS, so >>>please remove old stuff always), JavaDoc added, comments fixed; >>> changed isNullAllListElements() => isAnyListElementNotNull(): the >>>duplicate negation at usage time breaks my brain ;-) >>> >>> >> >>This depends of the POV you see it: >> >>isNullAllListElements() -> This is not a negation. It check if : >> >>All elements on the List are null. Where is the negation? >> >>isAnyListElementNotNull() -> Here is a negation "Not null" :-D >> >> > > Generally speaking, negative forms should be avoided, as their > interpretation may be difficult depending on people's linguistic > background. I used to work with Japanese people long time ago, and I'm > sure this name, even with a single negation, would be very hard for them > to understand. I agree. > > So what about "hasNonNullElements()"? The problem again is the "hidden" Non. This is a kind of negative. Look as the "standard" isNull() function. Why it is not isNotNull()? Because there is a negation. Then, the original function name is better to me: isNullAllListElements() or areNullAllListElements() To me it clearly states what we had in mind. Goerg changed the function name (and behavior) to write: if (isAnyListElementNotNull(...)) instead of if (!isNullAllListElements(...)) As a rule I try to avoid negation inside the names. In the case hasNonNullElements(), we can write also: if (hasNonNullElements()) Interesting is that the method need to check for each element if the value is null. At the end, I think I am not the best to decide the best name of the function. :-D Best Regards, Antonio Gallardo.
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
Antonio Gallardo wrote:
[EMAIL PROTECTED] dijo:
joerg 2004/03/03 11:47:35
Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding
RepeaterJXPathBinding.java
Log:
clean up: removed unused code (for reverting changes we have CVS, so
please remove old stuff always), JavaDoc added, comments fixed;
changed isNullAllListElements() => isAnyListElementNotNull(): the
duplicate negation at usage time breaks my brain ;-)
This depends of the POV you see it:
isNullAllListElements() -> This is not a negation. It check if :
All elements on the List are null. Where is the negation?
isAnyListElementNotNull() -> Here is a negation "Not null" :-D
Generally speaking, negative forms should be avoided, as their
interpretation may be difficult depending on people's linguistic
background. I used to work with Japanese people long time ago, and I'm
sure this name, even with a single negation, would be very hard for them
to understand.
So what about "hasNonNullElements()"?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
[EMAIL PROTECTED] dijo: > joerg 2004/03/03 11:47:35 > > Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding > RepeaterJXPathBinding.java > Log: > clean up: removed unused code (for reverting changes we have CVS, so > please remove old stuff always), JavaDoc added, comments fixed; > changed isNullAllListElements() => isAnyListElementNotNull(): the > duplicate negation at usage time breaks my brain ;-) This depends of the POV you see it: isNullAllListElements() -> This is not a negation. It check if : All elements on the List are null. Where is the negation? isAnyListElementNotNull() -> Here is a negation "Not null" :-D Best Regards, Antonio Gallardo.
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
On 03.03.2004 20:47, [EMAIL PROTECTED] wrote: joerg 2004/03/03 11:47:35 Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java Log: clean up: removed unused code (for reverting changes we have CVS, so please remove old stuff always), JavaDoc added, comments fixed; changed isNullAllListElements() => isAnyListElementNotNull(): the duplicate negation at usage time breaks my brain ;-) For one case there is now another behaviour: if the list is empty now false will be returned (as before, but there the function tested the opposite). I don't know if this breaks anything, it was just for logical reasons: isNullAllListElements() returning false I expect to get one list element which is not null, which is not the case for empty list. Antonio, I guess you are the only one using it at the moment. Can you test it please? Joerg
cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java
mpo 2003/08/26 06:55:46
Modified:src/blocks/woody/java/org/apache/cocoon/woody/formmodel
Repeater.java
src/blocks/woody/java/org/apache/cocoon/woody/binding
RepeaterJXPathBinding.java
Log:
Making sure that repeater-rows are removed during load().
Added convenience method to Repeater widget for this.
Revision ChangesPath
1.8 +7 -0
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/formmodel/Repeater.java
Index: Repeater.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/formmodel/Repeater.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Repeater.java 12 Aug 2003 12:55:43 - 1.7
+++ Repeater.java 26 Aug 2003 13:55:46 - 1.8
@@ -103,6 +103,13 @@
}
/**
+ * Clears all rows from the repeater.
+ */
+public void removeRows() {
+rows.clear();
+}
+
+/**
* Gets a widget on a certain row.
* @param rowIndex startin from 0
* @param id a widget id
1.5 +1 -0
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding/RepeaterJXPathBinding.java
Index: RepeaterJXPathBinding.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding/RepeaterJXPathBinding.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- RepeaterJXPathBinding.java26 Aug 2003 13:10:12 - 1.4
+++ RepeaterJXPathBinding.java26 Aug 2003 13:55:46 - 1.5
@@ -106,6 +106,7 @@
public void loadFormFromModel(Widget frmModel, JXPathContext jxpc) {
// Find the repeater
Repeater repeater = (Repeater) frmModel.getWidget(this.repeaterId);
+repeater.removeRows();
// build a jxpath iterator for pointers
JXPathContext repeaterContext =
jxpc.getRelativeContext(jxpc.getPointer(this.repeaterPath));
