Re: variables in or out of includes

This WebDNA talk-list message is from

2001

It keeps the original formatting. numero = 39243
interpreted = N
texte = 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 databasepordID - Was passed in to the pagetordID - Was created in the main template as a text variablemordID - Was created in the main template as a math variableiordID - Was passed from the main template to the include in a parameteritordID - Was defined in the include file as a text variableimordID - Was defined in the include file as a math variableThe key is to establish a naming convention then use it consistently.- Brian-- <= Brian C. Fries, BrainScan Software http://www.brainscansoftware.com =>-------------------------------------------------------------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:

Re: variables in or out of includes (Michael Davis 2001)
Re: variables in or out of includes (Michael Davis 2001)
Re: variables in or out of includes (Andrew Simpson 2001)
Re: variables in or out of includes (Brian Fries 2001)
Re: variables in or out of includes (John Peacock 2001)
Re: variables in or out of includes (Alain Russell 2001)
Re: variables in or out of includes (Michael Davis 2001)
variables in or out of includes (Andrew Simpson 2001)

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 databasepordID - Was passed in to the pagetordID - Was created in the main template as a text variablemordID - Was created in the main template as a math variableiordID - Was passed from the main template to the include in a parameteritordID - Was defined in the include file as a text variableimordID - Was defined in the include file as a math variableThe key is to establish a naming convention then use it consistently.- Brian-- <= Brian C. Fries, BrainScan Software http://www.brainscansoftware.com =>-------------------------------------------------------------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/ Brian Fries

DOWNLOAD WEBDNA NOW!

Re: variables in or out of includes

2001

Top Articles:

Related Readings: