Re: variables in or out of includes
This WebDNA talk-list message is from 2001
It keeps the original formatting.
numero = 39244
interpreted = N
texte = I believe in webcat code - that there is only one point of execution - unlike asp for example where you can write traditional functions and sub routines - but i might be wrong - still new at this.an include file isn't a function outside the scope of the caller.it is a piece of code that is physically insert into the text at the point of the include statement.what confused me however was whether or not its was interpreted then inserted or the other way around.if the file is scanned for all include files then interpreted then all variables declared in an include would be available to the parent document below the include statement.if however the files are interpreted seperately then the results collated, the variables would be outside the scope of the caller.I think it may be the first one - (just a hunch)anyway - the confussion wasn't about the mess caused by a lazy naming convention, its was more a clarification of how loosely you are able to pass parameters and get away with it.Its sometimes been my experience that certain things work on a tuesday and not on a thursday if you get my drift...thanks guys.Andrewon 11/10/01 1:17 PM, Brian Fries at brainscan@mac.com wrote:> At 11:52 AM 10/10/2001, John Peacock wrote: >> Andrew Simpson wrote: >>> >>> I realise that i can do this: >>> >>> [include file=/somewhere/somefile.html¶m1=123] >>> >>> But can i expect this to work?: >>> >>> [text]param1=123[/text] >>> [include file=/somewhere/somefile.html] >>> >> >> For future reference, contexts can be considered containers. Variables >> defined inside a context are available inside any contexts contained >> within the enclosing context. Variables contained within a context >> are only available within that context. >> >> In pseudocode: >> >> var1=1 >> [context] >> var1 is [var1] [!] will print 1[/!] >> var2=2 >> [/context] >> var2 is [var2] [!] will print nothing, not in the context anymore[/!] >> >> For this purpose, a page is an enclosing context and contains all of >> the form variables passed in. The include file is an enclosed context >> and has access to all of the page variable as well as its own. >> > > Further clarification, drawn from my experiences, and how I deal with > the confusion... > > If you set a text or math variable inside a context, including inside > an [include] file, that variable IS STILL DEFINED after leaving the > context or include file. > > So, in John's example above, the line: > > var2 is [var2] > > WILL display 2, the value assigned to [var2] within the preceding context. > > There are semi-exceptions to the rule... context specific tags and > variables, such as [numfound] from searches, or the fields stored in > a database accessed via a search, or fields from order files or line > items, will take precedence over any defined [text] or [math] > variables, as well as over any passed-in form or URL variables. > > The key to managing the confusion is in using consistent NAMING > CONVENTIONS. Here is a rundown of some of the conventions I use - > feel free to use these or come up with your own scheme: > > * All fields in all databases are defined with a three-character > prefix that identifies the database that the field comes from and is > unique among all databases for a particular site. For example, all > fields in an order.db database would begin with ord (ordID, > ordEmail, ordTotal), and all fields in a member.db would begin with > mem (memID, memEmail, memName). In this way I can nest searches > from both of these databases, and refer to similarly named fields > (xxID, xxxEmail) and know which database the field is coming from. > Additionally, I never need to be concerned about overriding WebCat > tags by naming fields with the tag name (eg. no fields named url or > date). > > * All fields passed in to a page are given a prefix of the letter > p. So, I can pass in a field like pordID without concern for > confusion with the database field ordID > > * All variables defined in a [text] context are given a prefix of the > letter t. Again, I could have tordID as a text variable without > confusing it with the database field ordID > > * Similarly, [math] variables begin with m > > * Parameters I pass in to [include] files begin with i (eg. > [include file=xxx.incl&iValue=yyy]). Continuing our example, I could > pass in a parameter named iordID > > * Within include files, if I define text or math variables that are > NOT INTENDED to be used after exiting the include file, I give prefix > the t or m with an i (eg. itordID or imordID). There is no way > to PREVENT these from being used after exiting the include file, but > this helps avoid confusion. > > > So, theoretically, I could have an include file called within a > search context on the order.db with predefined parameter, text and > math variables, and end up with all the following variables defined, > and I wouldn't be confused (not too badly anyway) about where they > came from: > > ordID - Came from the search results on the order.db database > pordID - Was passed in to the page > tordID - Was created in the main template as a text variable > mordID - Was created in the main template as a math variable > iordID - Was passed from the main template to the include in a parameter > itordID - Was defined in the include file as a text variable > imordID - Was defined in the include file as a math variable > > > The key is to establish a naming convention then use it consistently. > > - Brian ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list
. To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
Associated Messages, from the most recent to the oldest:
I believe in webcat code - that there is only one point of execution - unlike asp for example where you can write traditional functions and sub routines - but i might be wrong - still new at this.an include file isn't a function outside the scope of the caller.it is a piece of code that is physically insert into the text at the point of the include statement.what confused me however was whether or not its was interpreted then inserted or the other way around.if the file is scanned for all include files then interpreted then all variables declared in an include would be available to the parent document below the include statement.if however the files are interpreted seperately then the results collated, the variables would be outside the scope of the caller.I think it may be the first one - (just a hunch)anyway - the confussion wasn't about the mess caused by a lazy naming convention, its was more a clarification of how loosely you are able to pass parameters and get away with it.Its sometimes been my experience that certain things work on a tuesday and not on a thursday if you get my drift...thanks guys.Andrewon 11/10/01 1:17 PM, Brian Fries at brainscan@mac.com wrote:> At 11:52 AM 10/10/2001, John Peacock wrote: >> Andrew Simpson wrote: >>> >>> I realise that i can do this: >>> >>> [include file=/somewhere/somefile.html¶m1=123] >>> >>> But can i expect this to work?: >>> >>> [text]param1=123[/text] >>> [include file=/somewhere/somefile.html] >>> >> >> For future reference, contexts can be considered containers. Variables >> defined inside a context are available inside any contexts contained >> within the enclosing context. Variables contained within a context >> are only available within that context. >> >> In pseudocode: >> >> var1=1 >> [context] >> var1 is [var1] [!] will print 1[/!] >> var2=2 >> [/context] >> var2 is [var2] [!] will print nothing, not in the context anymore[/!] >> >> For this purpose, a page is an enclosing context and contains all of >> the form variables passed in. The include file is an enclosed context >> and has access to all of the page variable as well as its own. >> > > Further clarification, drawn from my experiences, and how I deal with > the confusion... > > If you set a text or math variable inside a context, including inside > an [include] file, that variable IS STILL DEFINED after leaving the > context or include file. > > So, in John's example above, the line: > > var2 is [var2] > > WILL display 2, the value assigned to [var2] within the preceding context. > > There are semi-exceptions to the rule... context specific tags and > variables, such as [numfound] from searches, or the fields stored in > a database accessed via a search, or fields from order files or line > items, will take precedence over any defined [text] or [math] > variables, as well as over any passed-in form or URL variables. > > The key to managing the confusion is in using consistent NAMING > CONVENTIONS. Here is a rundown of some of the conventions I use - > feel free to use these or come up with your own scheme: > > * All fields in all databases are defined with a three-character > prefix that identifies the database that the field comes from and is > unique among all databases for a particular site. For example, all > fields in an order.db database would begin with ord (ordID, > ordEmail, ordTotal), and all fields in a member.db would begin with > mem (memID, memEmail, memName). In this way I can nest searches > from both of these databases, and refer to similarly named fields > (xxID, xxxEmail) and know which database the field is coming from. > Additionally, I never need to be concerned about overriding WebCat > tags by naming fields with the tag name (eg. no fields named url or > date). > > * All fields passed in to a page are given a prefix of the letter > p. So, I can pass in a field like pordID without concern for > confusion with the database field ordID > > * All variables defined in a [text] context are given a prefix of the > letter t. Again, I could have tordID as a text variable without > confusing it with the database field ordID > > * Similarly, [math] variables begin with m > > * Parameters I pass in to [include] files begin with i (eg. > [include file=xxx.incl&iValue=yyy]). Continuing our example, I could > pass in a parameter named iordID > > * Within include files, if I define text or math variables that are > NOT INTENDED to be used after exiting the include file, I give prefix > the t or m with an i (eg. itordID or imordID). There is no way > to PREVENT these from being used after exiting the include file, but > this helps avoid confusion. > > > So, theoretically, I could have an include file called within a > search context on the order.db with predefined parameter, text and > math variables, and end up with all the following variables defined, > and I wouldn't be confused (not too badly anyway) about where they > came from: > > ordID - Came from the search results on the order.db database > pordID - Was passed in to the page > tordID - Was created in the main template as a text variable > mordID - Was created in the main template as a math variable > iordID - Was passed from the main template to the include in a parameter > itordID - Was defined in the include file as a text variable > imordID - Was defined in the include file as a math variable > > > The key is to establish a naming convention then use it consistently. > > - Brian ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
Andrew Simpson
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
NT vs Mac (1997)
Spawn not working (1999)
Web Browser %Numbers - A must read for web developers (2003)
(2000)
Need help (1998)
Frames (1997)
WebTen Type 2 Crash on start (2000)
2nd WebCatalog2 Feature Request (1996)
Putting a page between checkout and invoice (1999)
rename a file (1997)
Orderfile Encryption (2007)
RE: Languages (1997)
Image maps/Webcat (1997)
URL for Discussion Archive (1997)
matching shipto and others (1998)
[WebDNA] WebDNA and MAMP/Apache (Mac) (2018)
whole word search bringing irrelevant results.. (2000)
Plugin or CGI or both (1997)
Upload to LINUX always breaks my sites - why? (2004)
.tmp files (2000)