Re: variables in or out of includes

This WebDNA talk-list message is from

2001

It keeps the original formatting. numero = 39246
interpreted = N
texte = On Wednesday, October 10, 2001, at 05:17 PM, Brian Fries 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> -- <= 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 digest@talk.smithmicro.com>> Web Archive of this list is at: http://search.smithmicro.com/>>The only further clarification I would add is that certain e-commerce based names used by Webcat will break the naming convention in a database used for products that are added to a shopping cart. SKU,Price,Taxable etc. Other than that, Brian is right on. Naming conventions are key to reducing debugging nightmares, as well as making it easier for someone else to modify your code later (or for you to modify code you wrote so long ago you can't remember what the heck you were thinking when you wrote it).Mike-------------------------------------------------------------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)

On Wednesday, October 10, 2001, at 05:17 PM, Brian Fries 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> -- <= 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 digest@talk.smithmicro.com>> Web Archive of this list is at: http://search.smithmicro.com/>>The only further clarification I would add is that certain e-commerce based names used by Webcat will break the naming convention in a database used for products that are added to a shopping cart. SKU,Price,Taxable etc. Other than that, Brian is right on. Naming conventions are key to reducing debugging nightmares, as well as making it easier for someone else to modify your code later (or for you to modify code you wrote so long ago you can't remember what the heck you were thinking when you wrote it).Mike-------------------------------------------------------------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/ Michael Davis

DOWNLOAD WEBDNA NOW!

Re: variables in or out of includes

2001

Top Articles:

Related Readings: