Is there any way to set a flag on an entire document?

Legacy ActionsDev
1

I’ve tried adding a global flag to a document, such that the part of my code I’m guarding will only run once. Something like this:

if(!fwDocument.setup){
	fwDocument['setup'] = true;
	alert('setup');
	// do some stuff here to initialize a site-wide manifest file
}

Then later I want to append to that file, not overwrite it, but the setup runs again on each page in the document (this is a folder Action), which wipes out whatever I’ve saved. Is there any place that I can stash a flag like this so a method will only run once? Otherwise, I’m going to have to either calculate the last page in the document and only run this write once, or parse it as data and merge and overwrite each time.

Thoughts?

Walter

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

2

Here’s where I’ve netted out, just writing everything into a data structure, parsing it each time the Action runs, and writing the merged data back into the newly-erased file. I wish there was some global site-wide data structure I could use instead.

Walter

On May 20, 2014, at 1:59 PM, Walter Lee Davis wrote:

I’ve tried adding a global flag to a document, such that the part of my code I’m guarding will only run once. Something like this:

if(!fwDocument.setup){
fwDocument[‘setup’] = true;
alert(‘setup’);
// do some stuff here to initialize a site-wide manifest file
}

Then later I want to append to that file, not overwrite it, but the setup runs again on each page in the document (this is a folder Action), which wipes out whatever I’ve saved. Is there any place that I can stash a flag like this so a method will only run once? Otherwise, I’m going to have to either calculate the last page in the document and only run this write once, or parse it as data and merge and overwrite each time.

Thoughts?

Walter

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

3

On 20/05/2014 18:59, Walter Lee Davis wrote:

Is there any place that I can stash a flag like this so a method will only run once? Otherwise, I’m going to have to either calculate the last page in the document and only run this write once, or parse it as data and merge and overwrite each time.

For 5.5+ and folder Actions only, there are the fwBeforePublish() and fwAfterPublish() callbacks. These might be a possibility if you only want the code to run once per publish cycle.

Stewart

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

4

How would this work in the context of collecting the data? Can I add an expando variable to fwDocument in fwBeforeEndBody as I noted, and then read that once in the fwBeforePublish callback at the end? If so, I’ll give that a try, certainly a lot simpler than opening/reading/rewriting the same external file over and over.

Walter

On May 21, 2014, at 3:51 AM, Stewart Fellows wrote:

On 20/05/2014 18:59, Walter Lee Davis wrote:

Is there any place that I can stash a flag like this so a method will only run once? Otherwise, I’m going to have to either calculate the last page in the document and only run this write once, or parse it as data and merge and overwrite each time.

For 5.5+ and folder Actions only, there are the fwBeforePublish() and fwAfterPublish() callbacks. These might be a possibility if you only want the code to run once per publish cycle.

Stewart

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

5

On 21/05/2014 12:01, Walter Lee Davis wrote:

How would this work in the context of collecting the data? Can I add an expando variable to fwDocument in fwBeforeEndBody as I noted, and then read that once in the fwBeforePublish callback at the end? If so, I’ll give that a try, certainly a lot simpler than opening/reading/rewriting the same external file over and over.

I guess it rather depends on where you’re collecting data from.

I think what I’ve recommended in the past internally is to set stuff up something like this:

  1. Add a hidden string parameter to the Action for storing data/state
  2. In fwBeforePublish(), initialise the string parameter with some text (JSON?) indicating the publish cycle has begun
  3. In the normal publishing callbacks, do whatever needs to be done and assemble the data/state information in the hidden parameter
  4. In fwAfterPublish(), process the final data/state from the parameter (and then clear it out?)

Stewart

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

6

Okay. My understanding of folder Actions was that they were just a page Action that ran on all pages, so they didn’t carry anything over data-wise from page to page. That’s why I made a fwDocument[‘manifest’] "expando variable on the one-and-only fwDocument, and tried to use that as my “session” between pages. Is the fwDocument built up each time the Action runs (on a page) or does it maintain state over the life of the publish cycle, as I was hoping?

Walter

On May 21, 2014, at 7:16 AM, Stewart Fellows wrote:

On 21/05/2014 12:01, Walter Lee Davis wrote:

How would this work in the context of collecting the data? Can I add an expando variable to fwDocument in fwBeforeEndBody as I noted, and then read that once in the fwBeforePublish callback at the end? If so, I’ll give that a try, certainly a lot simpler than opening/reading/rewriting the same external file over and over.

I guess it rather depends on where you’re collecting data from.

I think what I’ve recommended in the past internally is to set stuff up something like this:

  1. Add a hidden string parameter to the Action for storing data/state
  2. In fwBeforePublish(), initialise the string parameter with some text (JSON?) indicating the publish cycle has begun
  3. In the normal publishing callbacks, do whatever needs to be done and assemble the data/state information in the hidden parameter
  4. In fwAfterPublish(), process the final data/state from the parameter (and then clear it out?)

Stewart

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

7

On 21/05/2014 12:21, Walter Lee Davis wrote:

Is the fwDocument built up each time the Action runs (on a page) or does it maintain state over the life of the publish cycle, as I was hoping?

fwDocument is created at the start of a new page, and destroyed at the end of it. Parameters for folder Actions are persistent across the entire publish, for example:

Stewart

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

8

I get it, that makes sense. So the fwDocument (which represents the entire document, all pages) is there within the context of the single page while the Action is running, allowing you to look at other pages, but it doesn’t persist after that page is completed and torn down.

This gist looks fascinating. I didn’t know you could build up a fwParameters element like that, without declaring it as an in the preamble of the Action.

Now for future API goodness, we need to be able to go the other way, and dynamically create an interface element as needed, so we won’t need -60 versions of Actions for people whose sites “go to 21”. I’ve simulated this before: look at my Protaculous 2 action, which seems to let you add a variable number of external libraries, but is really just un-hiding the next one the moment you add one. That has an upward limit, based on how bored I got adding initially-hidden groups of elements.

Thanks very much,

Walter

On May 21, 2014, at 7:53 AM, Stewart Fellows wrote:

On 21/05/2014 12:21, Walter Lee Davis wrote:

Is the fwDocument built up each time the Action runs (on a page) or does it maintain state over the life of the publish cycle, as I was hoping?

fwDocument is created at the start of a new page, and destroyed at the end of it. Parameters for folder Actions are persistent across the entire publish, for example:

https://gist.github.com/stewartf/df7b3ec370a0c87f2369

Stewart

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

9

On 21/05/2014 13:07, Walter Lee Davis wrote:

I get it, that makes sense. So the fwDocument (which represents the entire document, all pages) is there within the context of the single page while the Action is running, allowing you to look at other pages, but it doesn’t persist after that page is completed and torn down.

Yeah, the whole Javascript context is built up and torn down like this.

This gist looks fascinating. I didn’t know you could build up a fwParameters element like that, without declaring it as an in the preamble of the Action.

Well, the PageList parameter is declared in the Action header, it just doesn’t have any content until the callbacks start doing stuff with it. It was declared as an action-number and an action-string (??!) before I eventually got it right as an action-text :slight_smile:

Now for future API goodness, we need to be able to go the other way, and dynamically create an interface element as needed, so we won’t need -60 versions of Actions for people whose sites “go to 21”. I’ve simulated this before: look at my Protaculous 2 action, which seems to let you add a variable number of external libraries, but is really just un-hiding the next one the moment you add one. That has an upward limit, based on how bored I got adding initially-hidden groups of elements.

Yeah, this is a long-standing problem internally as well. I believe the Exhibeo Action has several hundred initially hidden parameters :slight_smile: I would like to be able to say that this is something that is easy to implement, and be done soon, but unfortunately it’s somewhat foundational in the Action machinery. I’ve had a look at doing this before, but there’s a vast amount of code reliant on Actions having fixed numbers of parameters.

Stewart

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

10

Am I right in thinking that a text control like this can only hold up to 32K of data? If so it could be an issue for an Action like Simple Site Search which collects a lot of document data.
I seem to recall having a conversation with, I think, Alan about storing data in the fwDocument object (which used to work) and he said it was just fortunate that it did at the time. Somewhere along the way things got changed and the fwDocument object gets wiped throughout the publish cycle.
Regards,
Tim.

On 21 May 2014, at 12:16, Stewart Fellows wrote:

  1. Add a hidden string parameter to the Action for storing data/state

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

11

On 21/05/2014 14:56, Tim Plumb wrote:

Am I right in thinking that a text control like this can only hold up to 32K of data? If so it could be an issue for an Action like Simple Site Search which collects a lot of document data.

Not as far as I know. Seems to be OK:

Stewart

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options