Re: [include file=filename.inc&strip=t]
This WebDNA talk-list message is from 2002
It keeps the original formatting.
numero = 43617
interpreted = N
texte = I was only using 'trim' as an example. I was getting a bit off the subject when talking about the function context. I just couldn't resists mentioning it, especially after John described how he would like the [include] to work.> -----Original Message----- > From: WebCatalog Talk > [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf > Of Brian Fries > Sent: Thursday, September 19, 2002 4:22 PM > To: WebCatalog Talk > Subject: Re: [include file=filename.inc&strip=t] > > > That sounds cool... though it sounds like we'll still need to do some > sort of [trim] within the function to avoid stray white space showing > up in our resulting pages. > > Eager with anticipation, > Brian > > At 3:39 PM 9/19/02, Scott Anderson wrote: > >I do not think it is necessary, as the function code does > have the ability > >to access and create template level variables. So, you can > simulate a 'pass > >by reference'. Or just make it a part of your definition.... > > > >[function name=MyFnction] > >... > >[text scope=global][return]=blah[/text] > >[/function] > > > >[!] Call MyFunction. Result will be stored in the MyResult > text variable > >[/!] > >[Myfunction return=MyResult] > > > >I think I am giving away to much, I better stop now. > > > > > > > > > >> -----Original Message----- > >> From: WebCatalog Talk > >> [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf > >> Of Brian Fries > >> Sent: Thursday, September 19, 2002 3:09 PM > >> To: WebCatalog Talk > >> Subject: Re: [include file=filename.inc&strip=t] > >> > >> > >> Awesome! Then I can stop writing my latest treatise on > the benefits > >> of such a context! It's always a pleasure to see examples > of vendors > >> listening to their customers. > >> > >> Do these functions also have something like a return > context so you > >> can specify exactly what to return, as opposed to the current > >> discussion which is centered around what NOT to return? > >> > >> i.e.: > >> > >> [function myFunction] > >> code > >> more code > >> [return [myReturnVar]] > >> [/function] > >> > >> ...and what's the latest on the expected 5.0 release schedule? > >> > >> - brian > >> > >> > >> At 2:27 PM 9/19/02, Scott Anderson wrote: > >> >I see your point. I think it would be good to do both, > >> create a global > >> >method and a new context, for removing extraneous white space. > >> > > >> >You will appreciate the new [function name=MyFunction...] > >> context I just > >> >finished implementing for 5.0. Instances of the 'user > >> defined' functions > >> >have their own parameter and variable name space. It has > >> come in very handy > >> >for our 5.0 template development. > >> > > >> >> -----Original Message----- > >> >> From: WebCatalog Talk > >> >> [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf > >> >> Of John Peacock > >> >> Sent: Thursday, September 19, 2002 1:58 PM > >> >> To: WebCatalog Talk > >> >> Subject: Re: [include file=filename.inc&strip=t] > >> >> > >> >> > >> >> Scott Anderson wrote: > >> >> > One idea that comes to mind is the introduction of a > >> >> post-parse action. > >> >> > This action could take the form of a WebDNA code block, > >> >> which could be > >> >> > persisted in the admin prefs. This code block would then > >> >> be applied to all > >> >> > parsed results, just before being returned to the > >> >> webserver. It would then > >> >> > be simple matter to define a WebDNA post-parse block of > >> >> code to strip out > > > >> > EOL's (or whatever), and this would be applied to every > > > >> template processed. > > > >> > Any feedback? > > > >> > > > >> No, that would also be nice but would not help me here. My > > > >> issue is that the > >> >> [include] context contains all of the EOL's from inside the > >> >> context in addition > >> >> to any text that I explicitely show. I want to have > >> >> > >> >> [include file=^somefile.inc¶m1] > >> >> > >> >> appears exactly like a new user-defined function > >> >> > >> >> [somefile param1] > >> >> > >> >> with no text (including EOL's) except that which I chose to > >> >> display. If the > >> >> post-parse action could apply to each enclosing context, that > >> >> would be fine. If > >> >> you look at what I am trying to accomplish, stripping EOL > >> >> before sending would > >> >> not be sufficient, since the [include] context is inside > >> >> other contexts and the > >> >> EOL's could wind up causing a syntax error... > >> >> > >> >> John > >> >> > >> >> -- > >> >> John Peacock > >> >> Director of Information Research and Technology > >> >> Rowman & Littlefield Publishing Group > >> >> 4720 Boston Way > >> >> Lanham, MD 20706 > >> >> 301-459-3366 x.5010 > > > > > fax 301-429-5747 > > ------------------------------------------------------------- > 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/ ------------------------------------------------------------- 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 was only using 'trim' as an example. I was getting a bit off the subject when talking about the function context. I just couldn't resists mentioning it, especially after John described how he would like the [include] to work.> -----Original Message----- > From: WebCatalog Talk > [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf > Of Brian Fries > Sent: Thursday, September 19, 2002 4:22 PM > To: WebCatalog Talk > Subject: Re: [include file=filename.inc&strip=t] > > > That sounds cool... though it sounds like we'll still need to do some > sort of [trim] within the function to avoid stray white space showing > up in our resulting pages. > > Eager with anticipation, > Brian > > At 3:39 PM 9/19/02, Scott Anderson wrote: > >I do not think it is necessary, as the function code does > have the ability > >to access and create template level variables. So, you can > simulate a 'pass > >by reference'. Or just make it a part of your definition.... > > > >[function name=MyFnction] > >... > >[text scope=global][return]=blah[/text] > >[/function] > > > >[!] Call MyFunction. Result will be stored in the MyResult > text variable > >[/!] > >[Myfunction return=MyResult] > > > >I think I am giving away to much, I better stop now. > > > > > > > > > >> -----Original Message----- > >> From: WebCatalog Talk > >> [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf > >> Of Brian Fries > >> Sent: Thursday, September 19, 2002 3:09 PM > >> To: WebCatalog Talk > >> Subject: Re: [include file=filename.inc&strip=t] > >> > >> > >> Awesome! Then I can stop writing my latest treatise on > the benefits > >> of such a context! It's always a pleasure to see examples > of vendors > >> listening to their customers. > >> > >> Do these functions also have something like a return > context so you > >> can specify exactly what to return, as opposed to the current > >> discussion which is centered around what NOT to return? > >> > >> i.e.: > >> > >> [function myFunction] > >> code > >> more code > >> [return [myReturnVar]] > >> [/function] > >> > >> ...and what's the latest on the expected 5.0 release schedule? > >> > >> - brian > >> > >> > >> At 2:27 PM 9/19/02, Scott Anderson wrote: > >> >I see your point. I think it would be good to do both, > >> create a global > >> >method and a new context, for removing extraneous white space. > >> > > >> >You will appreciate the new [function name=MyFunction...] > >> context I just > >> >finished implementing for 5.0. Instances of the 'user > >> defined' functions > >> >have their own parameter and variable name space. It has > >> come in very handy > >> >for our 5.0 template development. > >> > > >> >> -----Original Message----- > >> >> From: WebCatalog Talk > >> >> [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf > >> >> Of John Peacock > >> >> Sent: Thursday, September 19, 2002 1:58 PM > >> >> To: WebCatalog Talk > >> >> Subject: Re: [include file=filename.inc&strip=t] > >> >> > >> >> > >> >> Scott Anderson wrote: > >> >> > One idea that comes to mind is the introduction of a > >> >> post-parse action. > >> >> > This action could take the form of a WebDNA code block, > >> >> which could be > >> >> > persisted in the admin prefs. This code block would then > >> >> be applied to all > >> >> > parsed results, just before being returned to the > >> >> webserver. It would then > >> >> > be simple matter to define a WebDNA post-parse block of > >> >> code to strip out > > > >> > EOL's (or whatever), and this would be applied to every > > > >> template processed. > > > >> > Any feedback? > > > >> > > > >> No, that would also be nice but would not help me here. My > > > >> issue is that the > >> >> [include] context contains all of the EOL's from inside the > >> >> context in addition > >> >> to any text that I explicitely show. I want to have > >> >> > >> >> [include file=^somefile.inc¶m1] > >> >> > >> >> appears exactly like a new user-defined function > >> >> > >> >> [somefile param1] > >> >> > >> >> with no text (including EOL's) except that which I chose to > >> >> display. If the > >> >> post-parse action could apply to each enclosing context, that > >> >> would be fine. If > >> >> you look at what I am trying to accomplish, stripping EOL > >> >> before sending would > >> >> not be sufficient, since the [include] context is inside > >> >> other contexts and the > >> >> EOL's could wind up causing a syntax error... > >> >> > >> >> John > >> >> > >> >> -- > >> >> John Peacock > >> >> Director of Information Research and Technology > >> >> Rowman & Littlefield Publishing Group > >> >> 4720 Boston Way > >> >> Lanham, MD 20706 > >> >> 301-459-3366 x.5010 > > > > > fax 301-429-5747 > > ------------------------------------------------------------- > 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/ ------------------------------------------------------------- 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/
Scott Anderson
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:
For those of you not on the WebCatalog Beta... (1997)
TRAINING videos - Prove IT. (1998)
Hiding HTML and breaking the page (1997)
[WebDNA] Need some PHP help (2009)
[SearchString] problem with [search] context (1997)
Cart Transfer from Un-Secure to Secure (2000)
Missing from Docs [folderName] (1997)
no global [username] or [password] displayed ... (1997)
[defined]ish (1997)
customer.db and forms (1999)
Thanks Will and Christer (was: need help with [sendmail] and[showif]s) (1998)
A quickie question (1997)
href name= link from dynamic URL possible? (1998)
Variables containing ! breaking HIDEIF's (1999)
Sort Order on a page search (1997)
file uploads with webcat...binary? (1998)
Replace/Commit not Replacing/Commiting (2000)
2 field showif/hideif's (2002)
Database changes (1998)
back button problem (1999)