[Laszlo-dev] For Review: Change 20090423-maxcarlson-5 Summary: Add warnings for non-string LzDataElement attributes

[Max Carlson]

André Bargull wrote:
> On 4/26/2009 9:58 PM, Max Carlson wrote:
>> P T Withington wrote:
>>> Ok, I am officially confused. (The data stuff always does that to me!)
>>>
>>> If you can't reliably make an xpath query against a non-string 
>>> element in a dataset, I have to ask, "how is webtop's usage working?"
>>
>> They are making queries against attribute names, not values.  A 
>> specific case is a combo box of mail folders where the attribute name 
>> is the label, and the value is a reference to the actual mail folder.  
>> There are many other examples that haven't been tracked down yet
> 
> Maybe we could implement the DOM Level3 UserData interface for this case.

Great idea!  It should be fairly simple:

   public Object  setUserData(String key, Object data, UserDataHandler 
handler);
   public Object  getUserData(String key);

   // OperationType
   public static final short NODE_CLONED   = 1;
   public static final short NODE_IMPORTED = 2;
   public static final short NODE_DELETED  = 3;
   public static final short NODE_RENAMED  = 4;
   public static final short NODE_ADOPTED  = 5;

   public void handle(short operation, String key, Object data, Node 
src, Node dst);


>>
>>> On 2009-04-26, at 06:47EDT, André Bargull wrote:
>>>> If it's considered to risky to change (which means to fix) the 
>>>> behaviour in one release without further notification, I like to 
>>>> propose to back out the warnings and the coercion, and instead make 
>>>> a release note for the next release (4.4?) explaining the upcoming 
>>>> change for the release after that one (4.5?).
>>>> Thoughts?
>>
>> I agree about the release note, but I think we should leave the 
>> warnings in...  Perhaps they should use Debug.info() instead of 
>> Debug.warn() - is there a setting in the debugger to restrict the 
>> level to cut down the noise?
> 
> Yes, you can adjust the "messageLevel" property of LzDebugService to 
> suppress certain types of messages.

So, to summarize - I'll back out the String coercion, update the error 
message to an info message that's more descriptive - and also take care 
of the nits from your review.

I'll also file an improvement in JIRA to implement UserData.

Sound good?

-- 
Regards,
Max Carlson
OpenLaszlo.org