Here’s a weird one: parameter.watch(...) and data binding

General
1

It occurred to me that I could use parameter.watch for data binding.

Then it occurred to me that it would create a ridiculous jam-up of nonsense in the parameter panel.

Is there a way to use the functionality of parameter.watch without having to show it in the parameter panel?

2

@UberGoober - not sure what you mean by a jam-up as the parameter is displayed with it’s label in the top window of the tool panel. Doesn’t spawn loadsa text as the bottom window does.

If you mean to use it as a pointer to a table then it should still be ok. Identifying data in large text files could be a mess.

3

I mean if you’re doing a lot of data binding, that’s a lot of parameter.watch data unnecessarily displayed in the tool panel–especially if you actually need to use that panel for something.

4

@UberGoober - you could write the data to a tab for retrospective viewing.

5

But you’d have to have a function that triggered when the data changed, which is the thing, AFAIK, that parameter.watch and only parameter.watch does.

6

@UberGoober - AFAIK parameter.watch doesn’t monitor for data change it just prints the current value out changed or not.

Can you show us an example of what you would like to display?

7

You’re right, I’m wrong!

I must have been hallucinating something, I could swear parameter.watch had a callback function, but that’s only parameter.action.

8

I’m talking about doing data binding in ways similar to the MVVM design pattern.

I think there are ways Codea is purposefully, and to its benefit, antithetical to MVVM, but it would be interesting to try and put some of the principles into play…

9

@UberGoober I still don’t know what you mean by data binding or MVVM. You could always use parameter.action to call a function that will print whatever you want or do whatever data binding is.

10

I’m sorry to be confusing. I don’t claim any expertise in it myself, it’s just something I’ve been forced to be at least conversant with on my current project.

MVVM stands for Model-View-ViewModel, which is a method for separating UI code from non-UI code so that each of them is more re-usable. I think it also had a bunch of other benefits that evangelists will be super glad to spell out but I can’t really.

Data binding isn’t solely a part of MVVM, but it helps separate UI from non-UI code, so it’s often used in it. The basic principle is that if non-UI code keeps a variable that affects UI, instead of having the non-UI code send some kind of message out when the variable changes, the UI “binds” to the data, automatically updating itself without the non-UI code having to know anything about it.

I might not be saying all that with the right terminology so forgive me if I’m getting it wrong.

Like I said it seems like Codea by design—and to its benefit, for its purposes—isn’t conducive to MVVM, but it might be interesting to try…