Still problem with autoguessing config settings

Hi,

I'm still at the point that settings which were guessed by the configure-method are not saved before my node dialog opens.

From my developer training manual (which is from 2011), I thought NodeModel#saveSettingsTo is called before the dialog opens but it does not seem to be the case (I put a breakpoint there which is not reached before opening the dialog)? How does settings guessed by the configure-method reach the dialog? After opening the dialog (after configure did its autoguessing) NodeDialog#loadSettingsFrom still reflects the 'old' settings.

Which is the missing link?

I would really appreciate if someone could help.

 

Hi, I can confirm that the method NodeModel#saveSettingsTo() is called before the dialog is opened through the configure-call. Can you please check that the NodeModel and NodeDialogPane classes are connected correctly via the NodeFactory...

Everything looks fine in my NodeFactory as far as I can see.

 

I realized that KNIME nodes seem to work like this:

1) New node - it tries to autoguess settings (and calls saveSettingsTo before opening the dialog)

2) Existing node gets new input table - simply stays red if the existing settings do not match the input table structure. (does not call saveSettingsTo before opening the dialog)

That is, how it should be? I thought autoguessing should take place if the input table structure changes but I guess I am wrong. I tried to change existing settings in the configure method if they do not fit anymore to the input specs.
 

You must never automatically change existing user settings! You are allowed to guess settings only for new nodes.

Okay clear now.

It was a misunderstanding, as I asumed autoguessing would be nice if a new input is connected to an existing node (of course not if the input specs change due to data changes in the existing workflow). That logic would have made sense to me...

Anyhow, thank you for your help!

True, but a node cannot distinguish between a new spec from an existing connection and a completely new connection. But even if, it's unclear what the user intended in the latter case. And in the former even if the immediate predecessor stays the same node, everything before it could have changed completely.

Sounds somehow logical so far.

Anyhow, from my personal users perspective, autoguessing seems to be very useful but I cannot profit from it so much (e.g. if I copy/paste a node; which is usually the fastest way).

True, but a node cannot distinguish between a new spec from an existing connection and a completely new connection. But even if, it's unclear what the user intended in the latter case. And in the former even if the immediate predecessor stays the same node, everything before it could have changed completely.

If a node could distinguish these cases, to me it would mean:

new connection: this is interactive and the user pushes new data to that node. he might want to use existing settings but the table structure might have changed. in the case settings do not fit, there would be autoguessing and a warning would pay his attention to it.

existing connection, something changed somewhere before: as it is not interactive in respective to the node it should just stay red and complain that settings do not fit to the incoming table spec.

But - to be clear - I just wanted to share my thoughts and assumptions and not to critisize how KNIME solved it :-)

Happy Easter!