Trigger for JavaScript on field change?

[Tony G]

I just want to make sure I'm not missing anything.
Is there yet a trigger to execute JavaScipt when a field changes?
I just voted for this suggestion in UserVoice.
I'm really surprised this common feature hasn't been implemented yet, among all of the other JS-related enhancements.
I think this would be a real game changer for this software.
Thanks!

[Bill Crews]

I don't understand the question. Triggers give control to a script at certain junctures within Memento processing. The script can then make any determination it wants and then do whatever it wants. The events and phases identify these junctures and how the script should be run.

So, what you're wanting is to identify a library and one of its fields and run a script whenever it is updated? That sounds interesting. Of course, you can do that with an Updating an entry trigger, but if the need is that simple, it would simplify things.

But what if a simple change to a single field is insufficient? When an entry is deleted or created? I guess in those cases, you'd still use the current trigger mechanism.

So, I agree in that sense. If any change to a single identified field occurs, run this script. To simplify further, maybe lock down that the script would run in the Before saving the entry phase.

Could you provide a link to it at Memento.UserVoice.com? Maybe we'd want to vote for it.

[Tony G]

Nothing near that. :)
I just want a fieldChanged event in my own library when I change a field.
Look at the referenced UV suggestion where I provided examples.
I could be wrong but I think the best we have now is the event that gets fired when the record is saved.
Regards,
T

[Bill Crews]

Assuming I understand correctly what is proceed...

It would be WAY helpful to simply state that what is desired/proposed is a scripted event, perhaps called something other than "trigger", that fires WITHIN THE PROCESSING OF AN ENTRY EDIT CARD PRIOR TO THE USER PRESSING THE CHECKMARK, SUCH AS WHEN FOCUS IS MOVED FROM A FIELD THAT HAS CHANGED SINCE FOCUS WENT TO THAT FIELD.

Why not be clear about what is proposed?

Yes, I agree with this proposal. Perhaps, along with it, each field that has changed since opening the card could have an Entry object property, perhaps called "changed", as well. It would help any fired script to detect multi-field changes. Also, assuming these intra-card events would have phases, then Losing focus, Saving entry, and Canceling entry might be reasonable phases for these events.

If my assumption after reading the UserVoice proposal is incorrect, then please forgive me once again, and since reasonable don't get it, please clarify the submitted proposal.

--
You received this message because you are subscribed to the Google Groups "mementodatabase" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mementodatabase+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tony G]

Bill Crews wrote:

It would be WAY helpful to simply state that what is desired/proposed is a scripted event, ..., SUCH AS WHEN FOCUS IS MOVED FROM A FIELD THAT HAS CHANGED...Why not be clear about what is proposed?

Well, the subject of the thread is "Trigger for JavaScript on field change?", so I thought that was clear from the start. :)

I think what happened in this discussion is that you're thinking about the term "trigger" which has been defined for Memento as only applying to an Entry object. I'm seeing Trigger and Event as being synonymous, and applying to Fields and Entries.

All other UI design tools support events like:

OnFocusChanged for the form

OnFocus and OnLostFocus for specific controls

OnChanged for controls

Note that Focus is different than Changed. And there is a difference between when focus is moved To a control and when it is moved Away from a control. It's common to have to process multiple events in sequence: Changed, then LostFocus from the current control, then OnFocus to the next control.

Sure, I'd like to see focus events too, but this specific request is only about a Field Changed event.

That brings up a request, sooner or later, for cascading change events. For example, is a "change" only a UI change, or is it actually the change in value of a field within an entity. I'd prefer the latter. The difference is that a UI change event would only fire if a user typed a number as a quantity, for example, and then transitioned away from that control. But if that field has an associated change event, it could trigger the recalculation of a running total, which is not manually changed, but which could have its own field changed event which takes some action.

I believe "intra-card" and "phase", while helping to be explicit here, are an unnecessary introduction of new terms, where industry standards include "field event" and "control event", compared to "form event" or "record-level event".

Overall I believe we're on the same page now. I just wish we could move as quickly toward enhancements to support the concepts. :)

Regards and Thanks.

T

[Tony G]

Bill, maybe we're trying to conceptualize something that's already in there.

This is from the notes on Zapier integration:

Supported triggers:

- Entry Created - Trigger is run when an entry is created.

- Field Value Changed - Trigger is run when an entry's field value changes.

This feature isn't really bound to Zapier but it unfortunately got wrapped into the Zapier release notes.
In other words, if there is a trigger for when a field value is changed, why should that have to be bound to Zapier integration if I just want to use that event locally?
Can we get some confirmation from Vasya on this stuff?

Thanks
T

[Bill Crews]

> Well, the subject of the thread is "Trigger for JavaScript on field change?", so I thought that was clear from the start. :)

You understand that I was referring to the guy (not you) who created the UserVoice proposal, right?

Here's the deal. You and I are examples of people who have had a lot of experience and are aware of standards and norms and best practices and all other good things. HOWEVER, when I am in any one tool and I am talking to other users of that tool, IMHO, we all need to use the nomenclature of that tool. It doesn't matter how eloquent either of us might be in giving a lecture on tools of this type, the marketplace, the state of the art, and so on. In this wiki and in this forum, when I say Trigger, I mean PRECISELY THE trigger that this developer, rightly or wrongly, defined and implemented in the tool.

I think what happened in this discussion is that you're thinking about the term "trigger" which has been defined for Memento as only applying to an Entry object. I'm seeing Trigger and Event as being synonymous, and applying to Fields and Entries.

I don't know how this all sounds in email; I don't mean ANY of this in a mean-spirited way. But here it is... "I'm seeing" is all well and good in an abstract discussion of technology or computer science, but when you speak of Memento 4.4.0, and if you speak to ME or to Vasya's other users, then you will please mean/see what Memento 4.4.0 means.

I used to be very religious about how things are capitalized in the wiki, and I still am. But I used to capitalize the same way in the forum, but no one else does, and lately I've gotten lax about it, too. But one thing we COULD do (you and I, at least) is use Trigger for Vasya's trigger, then if either of us says trigger, we know we might very well mean triggers as a general concept. Still, even if you & I agree to this, we can't carry the users in the forum along with us; they're likely to come at us from every which way; at least, that's been my experience.

All other UI design tools support events like:

OnFocusChanged for the form

OnFocus and OnLostFocus for specific controls

OnChanged for controls

"All other UI design tools"? FAR to broad script statement! And if it is a complaint, it is for Vasya, not me. While I really like Memento a lot, if I had developed it myself, it would be different in various ways, and it would be better. But we can be at least a little forgiving, can't we?

Note that Focus is different than Changed. And there is a difference between when focus is moved To a control and when it is moved Away from a control. It's common to have to process multiple events in sequence: Changed, then LostFocus from the current control, then OnFocus to the next control.

Sure, I'd like to see focus events too, but this specific request is only about a Field Changed event.

That brings up a request, sooner or later, for cascading change events. For example, is a "change" only a UI change, or is it actually the change in value of a field within an entity. I'd prefer the latter. The difference is that a UI change event would only fire if a user typed a number as a quantity, for example, and then transitioned away from that control. But if that field has an associated change event, it could trigger the recalculation of a running total, which is not manually changed, but which could have its own field changed event which takes some action.

I was not at all campaigning for a full GUI for Memento users; it would not be appropriate. Memento users must maintain attention on the database and of pragmatic use of it. Your discussion points out done of the problems in introducing intra-card events to Memento. Maybe it's as simple as recalculating all dependent aggregations and Manafort field references before firing the event, but there would still be multiple field value changes that such users might care about.

Who knows? Maybe Vasya is considering some or all of this. I'm not bothering him about it. Maybe you can get away with discussing it with him. As I said previously, though I have my way of dealing with him, you can do anything you like.

I believe "intra-card" and "phase", while helping to be explicit here, are an unnecessary introduction of new terms, where industry standards include "field event" and "control event", compared to "form event" or "record-level event".

Again, if what you want is to discuss industry stuff in industry terms, then call Vasya and get it on. But don't tell me "phase" is an unnecessary introduction of a new term. It is used IN THE PRODUCT ITSELF; it is represented in the wiki as such. And whether Vasya should have done it that way or not is COMPLETELY IRRELEVANT to me.

Overall I believe we're on the same page now. I just wish we could move as quickly toward enhancements to support the concepts. :)

I'm not saying we can never have general conversations about database theory or whatever. I used to do that for a living. But my attention in the wiki and mostly in the forum as well is on the latest release of Memento and not on all that other stuff.

[Tony G]

The intergalactic translator summarized that as...
"No."
I'm good with that. Thanks.
T

[Bill Crews]

I have not responded to this post previously, and I don't know the answer. If you'd like to ask the developer, please do so.