Re: [include file=filename.inc&strip=t]

This WebDNA talk-list message is from

2002


It keeps the original formatting.
numero = 43635
interpreted = N
texte = I also have been doing this with includes for years...The first big difference is the syntax, which will make code easier to read and maintain. For example, you could replace this:[include file=^clientname/include/myfunction.incl&predator=frog&victim=fly]with this:[myFunction predator=frog&victim=fly]If you reuse code frequently, this is a significant improvement. And you don't need to remember to use the file= before the include file name if you are passing parameters to it. There are many places where I would use more callable functions were the syntax of include files less cumbersome.Second, the availability of local-scope variables is huge - your include files / functions can now safely use a variable called temp without worrying about stomping on a variable in the calling code that is also called temp.One of my big concerns as a WebDNA developer is always maintaining vigilance in my naming conventions. How often have nested contexts and their date index value name tags caused you to need to scour your code for name conflicts? It is possible to have many concurrently defined identifiers with the same name - say you pass a formvariable named date to a page with an order file context, and you also search a DB with a date field, and define math and text variables named date - nastiness will ensue. I know I've wasted many of my hours and my clients dollars tracking down such problems, and have developed rigorous self-imposed naming conventions as a result. The availability of local-scope variables in functions will help considerably.Just thinking aloud here, some form of a dot-syntax would also be great. What if you could say [dna.date] to always reference the WebDNA tag. And you could and a name=xxx to your search, founditems or orderfile tag then reference items from those nested contexts as [xxx.date]. And you could access math, text, form and include variables as [math.date], [text.date], [form.date] and [include.date], while [date] would still work identically to how it does now... Now this would be a great addition to WebDNA and would go a long way toward resolving these naming conflicts.- brian At 3:19 PM 9/20/02, Kenneth Grome wrote: >I've been doing this for years simply by using include tags. What's >so much better about implementing it as functions? > >>The great benefit, Donovan, is that when you replace your library >>of frequently-used include files with a library of functions, they >>will be easier to use, and the code will be much easier to read and >>maintain. >> >>This will allow the development of extensive code libraries that >>can be included at the top of your pages for doing all the simple >>things you have to code over and over again. These will then be >>customizable extensions to the WebDNA language that are called in a >>syntactically consistent manner to the built-in WebDNA tags. >> >>For example, you could write a GMTTime function that you could call with: >> >>[GMTTime offset=2&unit=days] >> >>that would return a properly formatted GMT time stamp offset 2 days >>from the current time. >> >>Or an Email Validator called like: >> >>[showif [ValidEmail email=[theEmail]]=T] >> >>Or an AddToCart function that adds things your way, with whatever >>options you may need. >> >>The possibilities are endless. >> >>- brian > > > >Sincerely, >Kenneth Grome------------------------------------------------------------- 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:

    
  1. Re: [include file=filename.inc&strip=t] (Rob Marquardt 2002)
  2. Re: [include file=filename.inc&strip=t] (Brian Fries 2002)
  3. Re: [include file=filename.inc&strip=t] (Donovan 2002)
  4. Re: [include file=filename.inc&strip=t] (Louis A Perosi 2002)
  5. Re: [include file=filename.inc&strip=t] (Brian Fries 2002)
  6. Re: [include file=filename.inc&strip=t] (Donovan 2002)
  7. Re: [include file=filename.inc&strip=t] (Brian Fries 2002)
  8. Re: [include file=filename.inc&strip=t] (Kenneth Grome 2002)
  9. Re: [include file=filename.inc&strip=t] (Scott Anderson 2002)
  10. Re: [include file=filename.inc&strip=t] (Brian Fries 2002)
  11. Re: [include file=filename.inc&strip=t] (Scott Anderson 2002)
  12. Re: [include file=filename.inc&strip=t] (Scott Anderson 2002)
  13. Re: [include file=filename.inc&strip=t] (Brian Fries 2002)
  14. Re: [include file=filename.inc&strip=t] (Brian Fries 2002)
  15. Re: [include file=filename.inc&strip=t] (Donovan 2002)
  16. Re: [include file=filename.inc&strip=t] (Scott Anderson 2002)
  17. Re: [include file=filename.inc&strip=t] (Scott Anderson 2002)
  18. Re: [include file=filename.inc&strip=t] (Andrew Simpson 2002)
  19. Re: [include file=filename.inc&strip=t] (Larry Goodhew 2002)
  20. Re: [include file=filename.inc&strip=t] (John Peacock 2002)
  21. Re: [include file=filename.inc&strip=t] (Alain Russell 2002)
  22. Re: [include file=filename.inc&strip=t] (Scott Anderson 2002)
  23. Re: RFE: [include file=filename.inc&strip=t] (Brian Fries 2002)
  24. Re: RFE: [include file=filename.inc&strip=t] (Gary Krockover 2002)
  25. Re: RFE: [include file=filename.inc&strip=t] (Brian Fries 2002)
  26. Re: [include file=filename.inc&strip=t] (Scott Anderson 2002)
  27. RFE: [include file=filename.inc&strip=t] (John Peacock 2002)
I also have been doing this with includes for years...The first big difference is the syntax, which will make code easier to read and maintain. For example, you could replace this:[include file=^clientname/include/myfunction.incl&predator=frog&victim=fly]with this:[myFunction predator=frog&victim=fly]If you reuse code frequently, this is a significant improvement. And you don't need to remember to use the file= before the include file name if you are passing parameters to it. There are many places where I would use more callable functions were the syntax of include files less cumbersome.Second, the availability of local-scope variables is huge - your include files / functions can now safely use a variable called temp without worrying about stomping on a variable in the calling code that is also called temp.One of my big concerns as a WebDNA developer is always maintaining vigilance in my naming conventions. How often have nested contexts and their date index value name tags caused you to need to scour your code for name conflicts? It is possible to have many concurrently defined identifiers with the same name - say you pass a formvariable named date to a page with an order file context, and you also search a DB with a date field, and define math and text variables named date - nastiness will ensue. I know I've wasted many of my hours and my clients dollars tracking down such problems, and have developed rigorous self-imposed naming conventions as a result. The availability of local-scope variables in functions will help considerably.Just thinking aloud here, some form of a dot-syntax would also be great. What if you could say [dna.date] to always reference the WebDNA tag. And you could and a name=xxx to your search, founditems or orderfile tag then reference items from those nested contexts as [xxx.date]. And you could access math, text, form and include variables as [math.date], [text.date], [form.date] and [include.date], while [date] would still work identically to how it does now... Now this would be a great addition to WebDNA and would go a long way toward resolving these naming conflicts.- brian At 3:19 PM 9/20/02, Kenneth Grome wrote: >I've been doing this for years simply by using include tags. What's >so much better about implementing it as functions? > >>The great benefit, Donovan, is that when you replace your library >>of frequently-used include files with a library of functions, they >>will be easier to use, and the code will be much easier to read and >>maintain. >> >>This will allow the development of extensive code libraries that >>can be included at the top of your pages for doing all the simple >>things you have to code over and over again. These will then be >>customizable extensions to the WebDNA language that are called in a >>syntactically consistent manner to the built-in WebDNA tags. >> >>For example, you could write a GMTTime function that you could call with: >> >>[GMTTime offset=2&unit=days] >> >>that would return a properly formatted GMT time stamp offset 2 days >>from the current time. >> >>Or an Email Validator called like: >> >>[showif [ValidEmail email=[theEmail]]=T] >> >>Or an AddToCart function that adds things your way, with whatever >>options you may need. >> >>The possibilities are endless. >> >>- brian > > > >Sincerely, >Kenneth Grome------------------------------------------------------------- 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!

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:

Webcatalog on MacOs (2000) Multiple postings (2000) using showpage and showcart commands (1996) Searching for the end (1998) Not really WebCat (1997) WebCat2: Formulas.db question (1997) (2000) Trouble with carts (2000) ListFiles (2000) Search design (1997) WC Database Format (1997) [BoldWords] WebCat.acgib15Mac (1997) WebCat2b12plugin - [search] is broken ... not! (1997) Re:E-Mailer (WebCatb15acgiMac) (1997) catagories (1997) listfiles-looking for slick solution (1997) Explorer 3.0 (1997) [WriteFile] problems (1997) Help with update to 2.11 (1998) [WebDNA] math date issues? (2013)