<code-group> and section renaming

[olivercrask]

Would it be possible to have python code in a live section run when variables are edited?

E.g. I was trying to change the value of a variable string and have it update a column in my table. I was redefining a pandas dataframe using the live section and displaying this using a variable table. The table only updated when I edited a field inside of it, regardless of whether other variables were amended.

[SimonBiggs]

I think what you might be after is an output section. Output sections run whenever a variable that is defined on the form (anywhere) changes.

[SimonBiggs]

Live sections on the other hand only update when a variable inside of them changes.

If you can think of better names for these sections let me know. This stage of the project is the best time to make these names as obvious as possible.

[olivercrask]

What about something like 'global' and 'local' live? Still not the best name, but perhaps something along those lines

[SimonBiggs]

Maybe remove "output" and just have a "global" parameter flag on live?

On Wed., 11 Apr. 2018, 6:08 pm Oli Crask, notifications@github.com wrote:

What about something like 'global' and 'local' live? Still not the best name, but perhaps something along those lines

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-380365668, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVe6EnVWFquHRAs4kW2n2esP_CQPhpks5tnbn_gaJpZM4TJzqK .

[olivercrask]

That would be nice!

[SimonBiggs]

Actually more thoughts. Make a code-group component.

The code group component would fulfill the task of all current sections and could be customised to be a mix of them as needed.

It would have multiple "trigger" parameters.

• sessionStartTrigger
• pageLoadTrigger
• globalTrigger
• contentsTrigger
• customTrigger
• timeoutTrigger
• buttonTrigger
• filechangeTrigger

By including a "sessionStartTrigger" it has essentially just become a section-start. A contentsTrigger will be what is now live. globalTrigger what is now output. buttonTrigger what is now button.

A few new ones would be timeoutTrigger which allows a time to be defined in seconds which will repeatedly run.

customTrigger will allow a set of python variables to be defined and if any of those change then it will run.

Initially I could implement this component, and rewrite the other sections to just be aliases of this one with those corresponding flags set. In time if it seems like a much better way to go I'll deprecate the section methods. But I'll seek feedback before making that decision.

In the past I have had needs for something to run on both session start and be live. Or it might be nice to make a button and live. Or button and filechange. This idea will make that possible.

It will also make the creation of new triggers, should they be thought of, relatively simple.

What do you think?

On Wed., 11 Apr. 2018, 8:46 pm Oli Crask, notifications@github.com wrote:

That would be nice!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-380408999, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVexJ2ZDcn-TJaQi1flgwouWSN8Zqkks5tnd7ygaJpZM4TJzqK .

[SimonBiggs]

Also as an aside, have you had any further troubles with start sections, or variable handler issues since the latest dev release?

On Wed., 11 Apr. 2018, 8:56 pm Simon Biggs, mail@simonbiggs.net wrote:

Actually more thoughts. Make a code-group component.

The code group component would fulfill the task of all current sections and could be customised to be a mix of them as needed.

It would have multiple "trigger" parameters.

• sessionStartTrigger
• pageLoadTrigger
• globalTrigger
• contentsTrigger
• customTrigger
• timeoutTrigger
• buttonTrigger
• filechangeTrigger

By including a "sessionStartTrigger" it has essentially just become a section-start. A contentsTrigger will be what is now live. globalTrigger what is now output. buttonTrigger what is now button.

A few new ones would be timeoutTrigger which allows a time to be defined in seconds which will repeatedly run.

customTrigger will allow a set of python variables to be defined and if any of those change then it will run.

Initially I could implement this component, and rewrite the other sections to just be aliases of this one with those corresponding flags set. In time if it seems like a much better way to go I'll deprecate the section methods. But I'll seek feedback before making that decision.

In the past I have had needs for something to run on both session start and be live. Or it might be nice to make a button and live. Or button and filechange. This idea will make that possible.

It will also make the creation of new triggers, should they be thought of, relatively simple.

What do you think?

On Wed., 11 Apr. 2018, 8:46 pm Oli Crask, notifications@github.com wrote:

That would be nice!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-380408999, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVexJ2ZDcn-TJaQi1flgwouWSN8Zqkks5tnd7ygaJpZM4TJzqK .

[SimonBiggs]

Custom triggers could also be functions. The function might be a http API callback. Or some kind of database signal. So custom triggers could make it so that external services actually cause the section to trigger.

Could also specifically make an "apiTrigger" Robin would be keen on that. Which takes a string as an input defining the url that is called to trigger that code running.

On Wed., 11 Apr. 2018, 8:59 pm Simon Biggs, mail@simonbiggs.net wrote:

Also as an aside, have you had any further troubles with start sections, or variable handler issues since the latest dev release?

On Wed., 11 Apr. 2018, 8:56 pm Simon Biggs, mail@simonbiggs.net wrote:

Actually more thoughts. Make a code-group component.

The code group component would fulfill the task of all current sections and could be customised to be a mix of them as needed.

It would have multiple "trigger" parameters.

• sessionStartTrigger
• pageLoadTrigger
• globalTrigger
• contentsTrigger
• customTrigger
• timeoutTrigger
• buttonTrigger
• filechangeTrigger

By including a "sessionStartTrigger" it has essentially just become a section-start. A contentsTrigger will be what is now live. globalTrigger what is now output. buttonTrigger what is now button.

A few new ones would be timeoutTrigger which allows a time to be defined in seconds which will repeatedly run.

customTrigger will allow a set of python variables to be defined and if any of those change then it will run.

Initially I could implement this component, and rewrite the other sections to just be aliases of this one with those corresponding flags set. In time if it seems like a much better way to go I'll deprecate the section methods. But I'll seek feedback before making that decision.

In the past I have had needs for something to run on both session start and be live. Or it might be nice to make a button and live. Or button and filechange. This idea will make that possible.

It will also make the creation of new triggers, should they be thought of, relatively simple.

What do you think?

On Wed., 11 Apr. 2018, 8:46 pm Oli Crask, notifications@github.com wrote:

That would be nice!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-380408999, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVexJ2ZDcn-TJaQi1flgwouWSN8Zqkks5tnd7ygaJpZM4TJzqK .

[olivercrask]

I think that would be a much better implementation. Would also be useful to have a pageCloseTrigger for running code when a form is closed? (To clean-up connections etc..)

Aside: Haven't been able to try out the latest dev release yet

[SimonBiggs]

A "pageCloseTrigger" ... I don't know how that would be possible... actually it might... It would have to send the code to a "holding bay" on the server. And there would need to some kind of constant "are you still there, yes I'm still there, are you still there, yes..." and then only when the "are you still there" gets no response then that code gets run.

Hmm... Okay I'll think further about that.

So I guess also "sessionEndTrigger" would also be important... That one I think would be much harder. Maybe not possible.

On Wed., 11 Apr. 2018, 11:31 pm Oli Crask, notifications@github.com wrote:

I think that would be a much better implementation. Would also be useful to have a pageCloseTrigger for running code when a form is closed? (To clean-up connections etc..)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-380452612, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVe7wzwdY1JGRxn1dhyyMmqDmZi-JJks5tngW6gaJpZM4TJzqK .

[SimonBiggs]

One flaw with the "on page close". What if multiple people open the same page in different browsers?

Should the in page close run each time a user leaves? Won't that clean up stuff it up for others who still have the page open?

On Thu., 12 Apr. 2018, 5:48 am Simon Biggs, mail@simonbiggs.net wrote:

A "pageCloseTrigger" ... I don't know how that would be possible... actually it might... It would have to send the code to a "holding bay" on the server. And there would need to some kind of constant "are you still there, yes I'm still there, are you still there, yes..." and then only when the "are you still there" gets no response then that code gets run.

Hmm... Okay I'll think further about that.

So I guess also "sessionEndTrigger" would also be important... That one I think would be much harder. Maybe not possible.

On Wed., 11 Apr. 2018, 11:31 pm Oli Crask, notifications@github.com wrote:

I think that would be a much better implementation. Would also be useful to have a pageCloseTrigger for running code when a form is closed? (To clean-up connections etc..)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-380452612, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVe7wzwdY1JGRxn1dhyyMmqDmZi-JJks5tngW6gaJpZM4TJzqK .

[SimonBiggs]

So given that I think both the page load and page close need to be split up into the following:

• pageLoadFirstUserTrigger
• pageLoadAllUsersTrigger
• pageCloseLastUserTrigger
• pageCloseAllUsersTrigger

That way the clean up things only need to be called on pageCloseLastUserTrigger and it will only trigger therefore when the last user closes their page.

On Thu., 12 Apr. 2018, 5:58 am Simon Biggs, mail@simonbiggs.net wrote:

One flaw with the "on page close". What if multiple people open the same page in different browsers?

Should the in page close run each time a user leaves? Won't that clean up stuff it up for others who still have the page open?

On Thu., 12 Apr. 2018, 5:48 am Simon Biggs, mail@simonbiggs.net wrote:

A "pageCloseTrigger" ... I don't know how that would be possible... actually it might... It would have to send the code to a "holding bay" on the server. And there would need to some kind of constant "are you still there, yes I'm still there, are you still there, yes..." and then only when the "are you still there" gets no response then that code gets run.

Hmm... Okay I'll think further about that.

So I guess also "sessionEndTrigger" would also be important... That one I think would be much harder. Maybe not possible.

On Wed., 11 Apr. 2018, 11:31 pm Oli Crask, notifications@github.com wrote:

I think that would be a much better implementation. Would also be useful to have a pageCloseTrigger for running code when a form is closed? (To clean-up connections etc..)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-380452612, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVe7wzwdY1JGRxn1dhyyMmqDmZi-JJks5tngW6gaJpZM4TJzqK .

[SimonBiggs]

Or maybe it is better called

• pageLoadSingleUserTrigger
• pageCloseSingleUserTrigger

... hmm... Further thought required on the names.

On Thu., 12 Apr. 2018, 6:33 am Simon Biggs, mail@simonbiggs.net wrote:

So given that I think both the page load and page close need to be split up into the following:

• pageLoadFirstUserTrigger
• pageLoadAllUsersTrigger
• pageCloseLastUserTrigger
• pageCloseAllUsersTrigger

That way the clean up things only need to be called on pageCloseLastUserTrigger and it will only trigger therefore when the last user closes their page.

On Thu., 12 Apr. 2018, 5:58 am Simon Biggs, mail@simonbiggs.net wrote:

One flaw with the "on page close". What if multiple people open the same page in different browsers?

Should the in page close run each time a user leaves? Won't that clean up stuff it up for others who still have the page open?

On Thu., 12 Apr. 2018, 5:48 am Simon Biggs, mail@simonbiggs.net wrote:

A "pageCloseTrigger" ... I don't know how that would be possible... actually it might... It would have to send the code to a "holding bay" on the server. And there would need to some kind of constant "are you still there, yes I'm still there, are you still there, yes..." and then only when the "are you still there" gets no response then that code gets run.

Hmm... Okay I'll think further about that.

So I guess also "sessionEndTrigger" would also be important... That one I think would be much harder. Maybe not possible.

On Wed., 11 Apr. 2018, 11:31 pm Oli Crask, notifications@github.com wrote:

I think that would be a much better implementation. Would also be useful to have a pageCloseTrigger for running code when a form is closed? (To clean-up connections etc..)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-380452612, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVe7wzwdY1JGRxn1dhyyMmqDmZi-JJks5tngW6gaJpZM4TJzqK .

[SimonBiggs]

Here's an odd idea...

How about there just be a trigger parameter... And it accepts a python list of strings. That way, if the need arises, trigger conditions can be varied with a python variable.

Further thought on the page triggers makes me think something like the following (now in python naming convention, since it might be under python):

• page_load_one_user
• page_load_any_user
• page_close_one_user
• page_close_any_user

On Thu., 12 Apr. 2018, 6:34 am Simon Biggs, mail@simonbiggs.net wrote:

Or maybe it is better called

• pageLoadSingleUserTrigger
• pageCloseSingleUserTrigger

... hmm... Further thought required on the names.

On Thu., 12 Apr. 2018, 6:33 am Simon Biggs, mail@simonbiggs.net wrote:

So given that I think both the page load and page close need to be split up into the following:

• pageLoadFirstUserTrigger
• pageLoadAllUsersTrigger
• pageCloseLastUserTrigger
• pageCloseAllUsersTrigger

That way the clean up things only need to be called on pageCloseLastUserTrigger and it will only trigger therefore when the last user closes their page.

On Thu., 12 Apr. 2018, 5:58 am Simon Biggs, mail@simonbiggs.net wrote:

One flaw with the "on page close". What if multiple people open the same page in different browsers?

Should the in page close run each time a user leaves? Won't that clean up stuff it up for others who still have the page open?

On Thu., 12 Apr. 2018, 5:48 am Simon Biggs, mail@simonbiggs.net wrote:

A "pageCloseTrigger" ... I don't know how that would be possible... actually it might... It would have to send the code to a "holding bay" on the server. And there would need to some kind of constant "are you still there, yes I'm still there, are you still there, yes..." and then only when the "are you still there" gets no response then that code gets run.

Hmm... Okay I'll think further about that.

So I guess also "sessionEndTrigger" would also be important... That one I think would be much harder. Maybe not possible.

On Wed., 11 Apr. 2018, 11:31 pm Oli Crask, notifications@github.com wrote:

I think that would be a much better implementation. Would also be useful to have a pageCloseTrigger for running code when a form is closed? (To clean-up connections etc..)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-380452612, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVe7wzwdY1JGRxn1dhyyMmqDmZi-JJks5tngW6gaJpZM4TJzqK .

[SimonBiggs]

If any item in the list of triggers isn't a valid trigger an error should rise to alert the template creator that they may have made a typo on one of their triggers.

On Thu., 12 Apr. 2018, 6:43 am Simon Biggs, mail@simonbiggs.net wrote:

Here's an odd idea...

How about there just be a trigger parameter... And it accepts a python list of strings. That way, if the need arises, trigger conditions can be varied with a python variable.

Further thought on the page triggers makes me think something like the following (now in python naming convention, since it might be under python):

• page_load_one_user
• page_load_any_user
• page_close_one_user
• page_close_any_user

On Thu., 12 Apr. 2018, 6:34 am Simon Biggs, mail@simonbiggs.net wrote:

Or maybe it is better called

• pageLoadSingleUserTrigger
• pageCloseSingleUserTrigger

... hmm... Further thought required on the names.

On Thu., 12 Apr. 2018, 6:33 am Simon Biggs, mail@simonbiggs.net wrote:

So given that I think both the page load and page close need to be split up into the following:

• pageLoadFirstUserTrigger
• pageLoadAllUsersTrigger
• pageCloseLastUserTrigger
• pageCloseAllUsersTrigger

That way the clean up things only need to be called on pageCloseLastUserTrigger and it will only trigger therefore when the last user closes their page.

On Thu., 12 Apr. 2018, 5:58 am Simon Biggs, mail@simonbiggs.net wrote:

One flaw with the "on page close". What if multiple people open the same page in different browsers?

Should the in page close run each time a user leaves? Won't that clean up stuff it up for others who still have the page open?

On Thu., 12 Apr. 2018, 5:48 am Simon Biggs, mail@simonbiggs.net wrote:

A "pageCloseTrigger" ... I don't know how that would be possible... actually it might... It would have to send the code to a "holding bay" on the server. And there would need to some kind of constant "are you still there, yes I'm still there, are you still there, yes..." and then only when the "are you still there" gets no response then that code gets run.

Hmm... Okay I'll think further about that.

So I guess also "sessionEndTrigger" would also be important... That one I think would be much harder. Maybe not possible.

On Wed., 11 Apr. 2018, 11:31 pm Oli Crask, notifications@github.com wrote:

I think that would be a much better implementation. Would also be useful to have a pageCloseTrigger for running code when a form is closed? (To clean-up connections etc..)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-380452612, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVe7wzwdY1JGRxn1dhyyMmqDmZi-JJks5tngW6gaJpZM4TJzqK .

[SimonBiggs]

...and given the level of complication involved in these triggers, it might be worth leaving the current sections as they are as well as having the code-group option.

I'm not sure.

Then again, is replacing <section-start> with <code-group triggers="['start']"> so bad?

I mean, to use scriptedforms properly one is going to have to get used to that weird string in list notation... Maybe it wouldn't hurt introducing that early. The code-group version does seem more explanatory of what is going on which is probably better for someone new to it...

On Thu., 12 Apr. 2018, 6:44 am Simon Biggs, mail@simonbiggs.net wrote:

If any item in the list of triggers isn't a valid trigger an error should rise to alert the template creator that they may have made a typo on one of their triggers.

On Thu., 12 Apr. 2018, 6:43 am Simon Biggs, mail@simonbiggs.net wrote:

Here's an odd idea...

How about there just be a trigger parameter... And it accepts a python list of strings. That way, if the need arises, trigger conditions can be varied with a python variable.

Further thought on the page triggers makes me think something like the following (now in python naming convention, since it might be under python):

• page_load_one_user
• page_load_any_user
• page_close_one_user
• page_close_any_user

On Thu., 12 Apr. 2018, 6:34 am Simon Biggs, mail@simonbiggs.net wrote:

Or maybe it is better called

• pageLoadSingleUserTrigger
• pageCloseSingleUserTrigger

... hmm... Further thought required on the names.

On Thu., 12 Apr. 2018, 6:33 am Simon Biggs, mail@simonbiggs.net wrote:

So given that I think both the page load and page close need to be split up into the following:

• pageLoadFirstUserTrigger
• pageLoadAllUsersTrigger
• pageCloseLastUserTrigger
• pageCloseAllUsersTrigger

That way the clean up things only need to be called on pageCloseLastUserTrigger and it will only trigger therefore when the last user closes their page.

On Thu., 12 Apr. 2018, 5:58 am Simon Biggs, mail@simonbiggs.net wrote:

One flaw with the "on page close". What if multiple people open the same page in different browsers?

Should the in page close run each time a user leaves? Won't that clean up stuff it up for others who still have the page open?

On Thu., 12 Apr. 2018, 5:48 am Simon Biggs, mail@simonbiggs.net wrote:

A "pageCloseTrigger" ... I don't know how that would be possible... actually it might... It would have to send the code to a "holding bay" on the server. And there would need to some kind of constant "are you still there, yes I'm still there, are you still there, yes..." and then only when the "are you still there" gets no response then that code gets run.

Hmm... Okay I'll think further about that.

So I guess also "sessionEndTrigger" would also be important... That one I think would be much harder. Maybe not possible.

On Wed., 11 Apr. 2018, 11:31 pm Oli Crask, notifications@github.com wrote:

I think that would be a much better implementation. Would also be useful to have a pageCloseTrigger for running code when a form is closed? (To clean-up connections etc..)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-380452612, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVe7wzwdY1JGRxn1dhyyMmqDmZi-JJks5tngW6gaJpZM4TJzqK .

[SimonBiggs]

As a last thought on this before I move on. What if all customisations (such as button value, or conditional, or api tag) were all defined within a Python dictionary passed to a parameter "customisations" or something of the like.

A button with a value might look like:

Is that starting to get to overkill? Or does the benefit of being able to vary section parameters within Python make this notation worth it?

On Thu., 12 Apr. 2018, 6:58 am Simon Biggs, mail@simonbiggs.net wrote:

...and given the level of complication involved in these triggers, it might be worth leaving the current sections as they are as well as having the code-group option.

I'm not sure.

Then again, is replacing <section-start> with <code-group triggers="['start']"> so bad?

I mean, to use scriptedforms properly one is going to have to get used to that weird string in list notation... Maybe it wouldn't hurt introducing that early. The code-group version does seem more explanatory of what is going on which is probably better for someone new to it...

On Thu., 12 Apr. 2018, 6:44 am Simon Biggs, mail@simonbiggs.net wrote:

If any item in the list of triggers isn't a valid trigger an error should rise to alert the template creator that they may have made a typo on one of their triggers.

On Thu., 12 Apr. 2018, 6:43 am Simon Biggs, mail@simonbiggs.net wrote:

Here's an odd idea...

How about there just be a trigger parameter... And it accepts a python list of strings. That way, if the need arises, trigger conditions can be varied with a python variable.

Further thought on the page triggers makes me think something like the following (now in python naming convention, since it might be under python):

• page_load_one_user
• page_load_any_user
• page_close_one_user
• page_close_any_user

On Thu., 12 Apr. 2018, 6:34 am Simon Biggs, mail@simonbiggs.net wrote:

Or maybe it is better called

• pageLoadSingleUserTrigger
• pageCloseSingleUserTrigger

... hmm... Further thought required on the names.

On Thu., 12 Apr. 2018, 6:33 am Simon Biggs, mail@simonbiggs.net wrote:

So given that I think both the page load and page close need to be split up into the following:

• pageLoadFirstUserTrigger
• pageLoadAllUsersTrigger
• pageCloseLastUserTrigger
• pageCloseAllUsersTrigger

That way the clean up things only need to be called on pageCloseLastUserTrigger and it will only trigger therefore when the last user closes their page.

On Thu., 12 Apr. 2018, 5:58 am Simon Biggs, mail@simonbiggs.net wrote:

One flaw with the "on page close". What if multiple people open the same page in different browsers?

Should the in page close run each time a user leaves? Won't that clean up stuff it up for others who still have the page open?

On Thu., 12 Apr. 2018, 5:48 am Simon Biggs, mail@simonbiggs.net wrote:

A "pageCloseTrigger" ... I don't know how that would be possible... actually it might... It would have to send the code to a "holding bay" on the server. And there would need to some kind of constant "are you still there, yes I'm still there, are you still there, yes..." and then only when the "are you still there" gets no response then that code gets run.

Hmm... Okay I'll think further about that.

So I guess also "sessionEndTrigger" would also be important... That one I think would be much harder. Maybe not possible.

On Wed., 11 Apr. 2018, 11:31 pm Oli Crask, notifications@github.com wrote:

I think that would be a much better implementation. Would also be useful to have a pageCloseTrigger for running code when a form is closed? (To clean-up connections etc..)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-380452612, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVe7wzwdY1JGRxn1dhyyMmqDmZi-JJks5tngW6gaJpZM4TJzqK .

[SimonBiggs]

Maybe just "options" instead of "customisations".

On Thu., 12 Apr. 2018, 7:04 am Simon Biggs, mail@simonbiggs.net wrote:

As a last thought on this before I move on. What if all customisations (such as button value, or conditional, or api tag) were all defined within a Python dictionary passed to a parameter "customisations" or something of the like.

A button with a value might look like:

Is that starting to get to overkill? Or does the benefit of being able to vary section parameters within Python make this notation worth it?

On Thu., 12 Apr. 2018, 6:58 am Simon Biggs, mail@simonbiggs.net wrote:

...and given the level of complication involved in these triggers, it might be worth leaving the current sections as they are as well as having the code-group option.

I'm not sure.

Then again, is replacing <section-start> with <code-group triggers="['start']"> so bad?

I mean, to use scriptedforms properly one is going to have to get used to that weird string in list notation... Maybe it wouldn't hurt introducing that early. The code-group version does seem more explanatory of what is going on which is probably better for someone new to it...

On Thu., 12 Apr. 2018, 6:44 am Simon Biggs, mail@simonbiggs.net wrote:

If any item in the list of triggers isn't a valid trigger an error should rise to alert the template creator that they may have made a typo on one of their triggers.

On Thu., 12 Apr. 2018, 6:43 am Simon Biggs, mail@simonbiggs.net wrote:

Here's an odd idea...

How about there just be a trigger parameter... And it accepts a python list of strings. That way, if the need arises, trigger conditions can be varied with a python variable.

Further thought on the page triggers makes me think something like the following (now in python naming convention, since it might be under python):

• page_load_one_user
• page_load_any_user
• page_close_one_user
• page_close_any_user

On Thu., 12 Apr. 2018, 6:34 am Simon Biggs, mail@simonbiggs.net wrote:

Or maybe it is better called

• pageLoadSingleUserTrigger
• pageCloseSingleUserTrigger

... hmm... Further thought required on the names.

On Thu., 12 Apr. 2018, 6:33 am Simon Biggs, mail@simonbiggs.net wrote:

So given that I think both the page load and page close need to be split up into the following:

• pageLoadFirstUserTrigger
• pageLoadAllUsersTrigger
• pageCloseLastUserTrigger
• pageCloseAllUsersTrigger

That way the clean up things only need to be called on pageCloseLastUserTrigger and it will only trigger therefore when the last user closes their page.

On Thu., 12 Apr. 2018, 5:58 am Simon Biggs, mail@simonbiggs.net wrote:

One flaw with the "on page close". What if multiple people open the same page in different browsers?

Should the in page close run each time a user leaves? Won't that clean up stuff it up for others who still have the page open?

On Thu., 12 Apr. 2018, 5:48 am Simon Biggs, mail@simonbiggs.net wrote:

A "pageCloseTrigger" ... I don't know how that would be possible... actually it might... It would have to send the code to a "holding bay" on the server. And there would need to some kind of constant "are you still there, yes I'm still there, are you still there, yes..." and then only when the "are you still there" gets no response then that code gets run.

Hmm... Okay I'll think further about that.

So I guess also "sessionEndTrigger" would also be important... That one I think would be much harder. Maybe not possible.

On Wed., 11 Apr. 2018, 11:31 pm Oli Crask, < notifications@github.com> wrote:

I think that would be a much better implementation. Would also be useful to have a pageCloseTrigger for running code when a form is closed? (To clean-up connections etc..)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-380452612, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVe7wzwdY1JGRxn1dhyyMmqDmZi-JJks5tngW6gaJpZM4TJzqK .

[olivercrask]

I like the new styling, and yes those list quotes are not very intuitive. That has its pros and cons.. users will have to use them more often, but as you said they will get used to them more quickly. It also means that users won't have to remember the various section names.

options is definitely better than customisations and how about code-element rather than code-group?

I think there is definitely a risk with going overkill with this kind of stuff but the new version is still pretty readable. A bit less than the original names but personally not too difficult.

[SimonBiggs]

Cheers, thanks for the feedback.

For now I'll implement them but leave the old sections as is. They can run in parallel for a while and can integrate the new style.

On Fri., 13 Apr. 2018, 10:40 pm Oli Crask, notifications@github.com wrote:

I like the new styling, and yes those list quotes are not very intuitive. That has its pros and cons.. users will have to use them more often but as you said will get used to them more quickly. It also means that users won't have to remember the various section names.

options is definitely better than customisations and how about rather than ?

I think there is definitely a risk with going overkill with this kind of stuff but the new version is still pretty readable. A bit less than the original names but not too difficult

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-381122800, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVewg5QWEumDOIly6Oqp30MYlrdw8lks5toJzQgaJpZM4TJzqK .

[SimonBiggs]

I meant "iterate" on the new style.

On Sat., 14 Apr. 2018, 6:33 am Simon Biggs, mail@simonbiggs.net wrote:

Cheers, thanks for the feedback.

For now I'll implement them but leave the old sections as is. They can run in parallel for a while and can integrate the new style.

On Fri., 13 Apr. 2018, 10:40 pm Oli Crask, notifications@github.com wrote:

I like the new styling, and yes those list quotes are not very intuitive. That has its pros and cons.. users will have to use them more often but as you said will get used to them more quickly. It also means that users won't have to remember the various section names.

options is definitely better than customisations and how about rather than ?

I think there is definitely a risk with going overkill with this kind of stuff but the new version is still pretty readable. A bit less than the original names but not too difficult

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-381122800, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVewg5QWEumDOIly6Oqp30MYlrdw8lks5toJzQgaJpZM4TJzqK .

[olivercrask]

and how about code-element rather than code-group?

realised I originally wrote this in HTML tags so it wasn't visible :)

[SimonBiggs]

Can you explain your reasoning for the naming?

On Sat., 14 Apr. 2018, 6:54 am Oli Crask, notifications@github.com wrote:

and how about code-element rather than code-group?

realised I originally wrote this in HTML tags so it wasn't visible :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-381258042, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVe83TWDLznJV5Su-gkIDyVLCabiz3ks5toRB7gaJpZM4TJzqK .

[olivercrask]

It was just an idea. I was thinking that with HTML webpages tags are used in a similar way to in ScriptedForms. The tags surround the content, then both tags and the content make up an element.

[SimonBiggs]

Yup makes sense. Given there are already <code> tags which produce a code element I think that name might be a bit confusing.

On Sat., 14 Apr. 2018, 7:15 am Oli Crask, notifications@github.com wrote:

It was just an idea. I was thinking that with HTML webpages tags are used in a similar way to in ScriptedForms. The tags contain the content, then both tags and the content make up an element.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-381262521, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVe02d_-d_4yQA4jdJYZkuCibnHo2iks5toRV-gaJpZM4TJzqK .

[SimonBiggs]

(within HTML that is)

On Sat., 14 Apr. 2018, 7:17 am Simon Biggs, mail@simonbiggs.net wrote:

Yup makes sense. Given there are already <code> tags which produce a code element I think that name might be a bit confusing.

On Sat., 14 Apr. 2018, 7:15 am Oli Crask, notifications@github.com wrote:

It was just an idea. I was thinking that with HTML webpages tags are used in a similar way to in ScriptedForms. The tags contain the content, then both tags and the content make up an element.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-381262521, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVe02d_-d_4yQA4jdJYZkuCibnHo2iks5toRV-gaJpZM4TJzqK .

[olivercrask]

Was going to suggest form-element but apparently they also exist

[SimonBiggs]

Please keep the suggestions/brainstorming coming.

My reasoning for <code-group> is I guess that it indicates that multiple code sections can go within it. And that "group" should act in a certain way as defined by the triggers...

... Definitely not locked into the name. Much better to get a good name from the beginning.

On Sat., 14 Apr. 2018, 7:21 am Oli Crask, notifications@github.com wrote:

Was going to suggest form-element but apparently they also exist

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-381263633, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVe3iF_uJwhTxunR0VmYs5yL3Wm8QSks5toRbTgaJpZM4TJzqK .

[SimonBiggs]

@psychemedia given your interest in ScriptedForms your opinion on the generic code group idea mentioned above would be greatly valued. In particular the trigger parameter accepting a python list, and the options parameter accepting a python dictionary.

My original design of ScriptedForms is that I wanted a working form to be able to be created with no parameters. I wanted the initial learning curve to be shallow to get something working quickly.

By making this code-group idea replace sections and making it require a trigger parameter I am undoing that design decision. I'm not sure if I should do that.

Would it be so bad to have to write <code-group triggers="['contents']"> instead of <section-live> to create the hello world example? On one hand it seems more self explicit. In that the syntax is more self explanatory of what it is doing. On the other hand it is more complicated. It massively increases felxibility and modularity however.

Anyway, I value your input.

[SimonBiggs]

I should say of course that any changes like this should they be implemented will have the old and new methods work along side each other for multiple 0.* versions. Any use of a deprecated method will print a warning notice providing the new code to be used.

So if this is implemented it won't break things.

[psychemedia]

@SimonBiggs I think the <section-live> style works at the level of being friendly-ish to someone who knows a bit of simple HTML, though things like <variable-string name = "image_text" > or <variable-string name = "image_text" value="test1" > might feel even more familiar?

I'm not sure I fully understand the suggested use case of <code-group> (I've yet to try anything other than the simplest of UIs!) and eg how it would compare to a UI written in the original style?

Things like <code-group triggers="['button']" customisations="{'value': 'button_name_here'}"> seem to be mixing metaphors to me. e.g. it could be confusing trying to work out when you need to use python syntax and whether it is interpreted inline or just syntactically similar...

Seems to me need to distinguish between:

• configuration (which can happen anywhere, or at least, anywhere prior to use);
• locating where items appear in UI (linear flow is easiest to understand, as it is now?)
• how UI elements name variables that can be accessed via references in the code.

YAML, XML and JSON are all widely used for setting config info I think. In the above case <code-group triggers="['button']" customisations="{'value': 'button_name_here'}"> is confusing to me, though I can see how it could perhaps map onto s/thing like:

<code-group>
  <triggers>
    <button name='button_name_here' />
  </triggers>
</code-group>

or

<code-group>
  <triggers>
    <button>
      <name>button_name_here</name>
    </button>
  </triggers>
</code-group>

or:

code_group = { 'triggers':[ {'type':'button', 'name':'button_name_here'} ]}

or:

code_group:
  triggers:
    - button:
      name: button_name_here

But maybe I'm misunderstanding what you're trying to do? (Also need to think about differences in commonsense interpretation of name, id, class, value and maybe group or section (section_name? section_id?) for different UI controls? Best to be consistent with conventions used elsewhere if possible?)

Using {varname} and $varname to move between different contexts is maybe something else to consider as widely used conventions? ( {varname} has more of the <tag></tag> feel about it but raises confusion with python dict syntax? )

I also wonder about generality: is scriptedforms necessarily a Jupyter pykernel thing, or could the same approach be used against an R kernel, just identifying R rather than python when defining the code block?

[SimonBiggs]

Thank you. That is definitely helpful.

Have a look at the following two files:

https://raw.githubusercontent.com/SimonBiggs/scriptedforms/master/scriptedforms/e2e/src/variable-table.md

https://github.com/SimonBiggs/scriptedforms/blob/master/scriptedforms/e2e/src/variable-table.py

The variable-table makes heavy use of the fact that the parameters are actually themselves python dictionaries.

In the case of code group/section or whatever it should be called the triggers parameter is actually truly a python list. Meaning a variable name of a python list could be written there. If the list items change value then the triggers of that section change to match the new lost contents. Likewise "options" (instead of customisations) is truly a python dictionary, syntax copied on purpose because it is actually a python variable being looked up. As in it could be replaced by a python variable name and then the button value could be varied by changing that item within that python dictionary.

Within https://raw.githubusercontent.com/SimonBiggs/scriptedforms/master/example/example/detailed.md I use this idea to make one of the items in a dropdown match what is written in the string input.

Thanks :)

On Fri., 20 Apr. 2018, 1:30 am Tony Hirst, notifications@github.com wrote:

@SimonBiggs https://github.com/SimonBiggs I think the style works at the level of being friendly-ish to someone who knows a bit of simple HTML, though things like or might feel even more familiar?

I'm not sure I fully understand the suggested use case of (I've yet to try anything other than the simplest of UIs!) and eg how it would compare to a UI written in the original style?

Things like seem to be mixing metaphors to me. e.g. it could be confusing trying to work out when you need to use python syntax and whether it is interpreted inline or just syntactically similar...

Seems to me need to distinguish between:

• configuration (which can happen anywhere, or at least, anywhere prior to use);
• locating where items appear in UI (linear flow is easiest to understand, as it is now?)
• how UI elements name variables that can be accessed via references in the code.

YAML, XML and JSON are all widely used for setting config info I think. In the above case <code-group triggers="['button']" customisations="{'value': 'button_name_here'}"> is confusing to me, though I can see how it could perhaps map onto s/thing like:

or

button_name_here

or:

code_group = { 'triggers':[ {'type':'button', 'name':'button_name_here'} ]}

or:

code_group: triggers:

• button: name: button_name_here

But maybe I'm misunderstanding what you're trying to do? (Also need to think about differences in commonsense interpretation of name, id, class, value and maybe group or section (section_name? section_id?) for different UI controls? Best to be consistent with conventions used elsewhere if possible?)

Using {varname} and $varname to move between different contexts is maybe something else to consider as widely used conventions? ( {varname} has more of the feel about it but raises confusion with python dict syntax? )

I also wonder about generality: is scriptedforms necessarily a Jupyter pykernel thing, or could the same approach be used against an R kernel, just identifying R rather than python when defining the code block?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-382779674, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVe-7eGX6vGApJLRPFazBYNRmy4EHaks5tqK2agaJpZM4TJzqK .

[SimonBiggs]

For those table files to make sense, best to copy all the variable-table files onto your own machine and see what they're doing:

https://github.com/SimonBiggs/scriptedforms/tree/master/scriptedforms/e2e/src

• variable-table.py
• variable-table.csv
• variable-table.md

On Fri., 20 Apr. 2018, 6:35 am Simon Biggs, mail@simonbiggs.net wrote:

Thank you. That is definitely helpful.

Have a look at the following two files:

https://raw.githubusercontent.com/SimonBiggs/scriptedforms/master/scriptedforms/e2e/src/variable-table.md

https://github.com/SimonBiggs/scriptedforms/blob/master/scriptedforms/e2e/src/variable-table.py

The variable-table makes heavy use of the fact that the parameters are actually themselves python dictionaries.

In the case of code group/section or whatever it should be called the triggers parameter is actually truly a python list. Meaning a variable name of a python list could be written there. If the list items change value then the triggers of that section change to match the new lost contents. Likewise "options" (instead of customisations) is truly a python dictionary, syntax copied on purpose because it is actually a python variable being looked up. As in it could be replaced by a python variable name and then the button value could be varied by changing that item within that python dictionary.

Within https://raw.githubusercontent.com/SimonBiggs/scriptedforms/master/example/example/detailed.md I use this idea to make one of the items in a dropdown match what is written in the string input.

Thanks :)

On Fri., 20 Apr. 2018, 1:30 am Tony Hirst, notifications@github.com wrote:

@SimonBiggs https://github.com/SimonBiggs I think the style works at the level of being friendly-ish to someone who knows a bit of simple HTML, though things like or might feel even more familiar?

I'm not sure I fully understand the suggested use case of (I've yet to try anything other than the simplest of UIs!) and eg how it would compare to a UI written in the original style?

Things like seem to be mixing metaphors to me. e.g. it could be confusing trying to work out when you need to use python syntax and whether it is interpreted inline or just syntactically similar...

Seems to me need to distinguish between:

• configuration (which can happen anywhere, or at least, anywhere prior to use);
• locating where items appear in UI (linear flow is easiest to understand, as it is now?)
• how UI elements name variables that can be accessed via references in the code.

YAML, XML and JSON are all widely used for setting config info I think. In the above case <code-group triggers="['button']" customisations="{'value': 'button_name_here'}"> is confusing to me, though I can see how it could perhaps map onto s/thing like:

or

button_name_here

or:

code_group = { 'triggers':[ {'type':'button', 'name':'button_name_here'} ]}

or:

code_group: triggers:

• button: name: button_name_here

But maybe I'm misunderstanding what you're trying to do? (Also need to think about differences in commonsense interpretation of name, id, class, value and maybe group or section (section_name? section_id?) for different UI controls? Best to be consistent with conventions used elsewhere if possible?)

Using {varname} and $varname to move between different contexts is maybe something else to consider as widely used conventions? ( {varname} has more of the feel about it but raises confusion with python dict syntax? )

I also wonder about generality: is scriptedforms necessarily a Jupyter pykernel thing, or could the same approach be used against an R kernel, just identifying R rather than python when defining the code block?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/SimonBiggs/scriptedforms/issues/223#issuecomment-382779674, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQVe-7eGX6vGApJLRPFazBYNRmy4EHaks5tqK2agaJpZM4TJzqK .

[SimonBiggs]

Moving discussion from here over to #247