[WebDNA] [store] and [recall]: default db location
This WebDNA talk-list message is from 2015
It keeps the original formatting.
numero = 112065
interpreted = N
texte = > from to > var1 Joe > var2 Biden > > In fact, [store]var1=Joe[/store] will do the same as [replace > db=reserved.db&eqFROMdata=var1&append=T]var1=Joe[/replace] I think you actually mean this: [replace db=reserved.db&eqFROMdata=var1&append=T]to=Joe[/replace] > reserved.db > If such a database does not exist, it will be automatically > created at the same level the creating code file is located. I think this is a mistake. Instead I believe the default behavior should be to create and access the default reserved.db in the location defined in the preferences. Then whenever we use this simple tag in any template or include file in our entire website: [recall var1] We will know that its value came from our default reserved.db, and therefore we will know what its value is going to be at all times, in all templates server-wide (or at least site-wide). But if we decide that we want var1 to mean something else in a specific location we can use this more complex recall tag structure instead: [recall name=var1&db=reserved.db] [recall name=var1&db=../databases/reserved.db] [recall name=var1&db=a/deeper/folder/reserved.db] Personally I think this is a better approach than forcing the default reserved.db to be in the same folder as the current template -- especially when "some of us" keep our dbs separate from our templates and include files! So PLEASE make the default behavior use the reserved.db file in the location defined in the prefs. Then when we use use [recall var1] it will give us the same value no matter which template it appears in ... and we won't have to worry about: 1- copying the same reserved.db to all our template folders so we can make sure [recall var1] produces the same value in all of them OR ... 2- using a more complex tags like this in all our templates simply to recall our "global" permanent variables: [recall name=var1&db=/databases/reserved.db] From my point of view, having the default db location the same as the template is a mistake for these reasons too: 1- When I move a template I might forget to move or copy the corresponding reserved.db with it. This would break the [recall var1] tag in the new location because its reserved.db is missing. 2- What if I cannot move or copy the corresponding reserved.db file to the template's new location because there's already another reserved.db file in that location? This would mean I might have to merge the two reserved.db files, and even assuming that this is possible it does not make the use of this new feature convenient by any stretch of the imagination. 3- What if I cannot have any dbs stored in my template folders because of server configuration restrictions designed to insure better security? This would force me to always use the more complex [recall name=var1&db=../dbs/reserved.db] tag format to designate a db in another folder. The old "globals" folder was a place where we could store a db for use by any template in any domain on the entire server. I think of [store] and [recall] to be used much the same way. They should (by default) store and recall values and/or code snippets that can be used in many different templates ... shouldn't they? Lots of other stuff to think about in your post too, Chris. Maybe I'll have time to think about those other new features later. But this one bothered me enough to comment on it immediately. Please correct me if my understanding is wrong about any of this. Thank you. :) Regards, Kenneth Grome WebDNA Solutions http://www.webdnasolutions.com Web Database Systems and Linux Server Management
Associated Messages, from the most recent to the oldest:
> from to > var1 Joe > var2 Biden > > In fact,
[store]var1=Joe[/store] will do the same as [replace > db=reserved.db&eqFROMdata=var1&append=T]var1=Joe[/replace] I think you actually mean this: [replace db=reserved.db&eqFROMdata=var1&append=T]to=Joe[/replace] > reserved.db > If such a database does not exist, it will be automatically > created at the same level the creating code file is located. I think this is a mistake. Instead I believe the default behavior should be to create and access the default reserved.db in the location defined in the preferences. Then whenever we use this simple tag in any template or include file in our entire website: [recall var1] We will know that its value came from our default reserved.db, and therefore we will know what its value is going to be at all times, in all templates server-wide (or at least site-wide). But if we decide that we want var1 to mean something else in a specific location we can use this more complex recall tag structure instead: [recall name=var1&db=reserved.db] [recall name=var1&db=../databases/reserved.db] [recall name=var1&db=a/deeper/folder/reserved.db] Personally I think this is a better approach than forcing the default reserved.db to be in the same folder as the current template -- especially when "some of us" keep our dbs separate from our templates and include files! So PLEASE make the default behavior use the reserved.db file in the location defined in the prefs. Then when we use use [recall var1] it will give us the same value no matter which template it appears in ... and we won't have to worry about: 1- copying the same reserved.db to all our template folders so we can make sure [recall var1] produces the same value in all of them OR ... 2- using a more complex tags like this in all our templates simply to recall our "global" permanent variables: [recall name=var1&db=/databases/reserved.db] From my point of view, having the default db location the same as the template is a mistake for these reasons too: 1- When I move a template I might forget to move or copy the corresponding reserved.db with it. This would break the [recall var1] tag in the new location because its reserved.db is missing. 2- What if I cannot move or copy the corresponding reserved.db file to the template's new location because there's already another reserved.db file in that location? This would mean I might have to merge the two reserved.db files, and even assuming that this is possible it does not make the use of this new feature convenient by any stretch of the imagination. 3- What if I cannot have any dbs stored in my template folders because of server configuration restrictions designed to insure better security? This would force me to always use the more complex [recall name=var1&db=../dbs/reserved.db] tag format to designate a db in another folder. The old "globals" folder was a place where we could store a db for use by any template in any domain on the entire server. I think of
[store] and [recall] to be used much the same way. They should (by default) store and recall values and/or code snippets that can be used in many different templates ... shouldn't they? Lots of other stuff to think about in your post too, Chris. Maybe I'll have time to think about those other new features later. But this one bothered me enough to comment on it immediately. Please correct me if my understanding is wrong about any of this. Thank you. :) Regards, Kenneth Grome WebDNA Solutions http://www.webdnasolutions.com Web Database Systems and Linux Server Management
Kenneth Grome
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:
How far do [showif]s go? (1997)
notification solutions (1997)
minimalist shopping cart. (1997)
Contribution (2000)
WebSTAR 2.1 freezes my Mac (1997)
Authorize.net and AIM (2003)
WebMerchant and Mac Auth Hub Help Please (1999)
The Guru Speaks-very long reply (1998)
The max=0 issue is a bug ... CALL TO ACTION (2000)
Checking two required fields (1998)
New Guestbook Source (1997)
TCP Connect over SSL? (2000)
WebDNA implementation of MD5 algorithm? (2003)
enhanced ErrorMessages.db (2002)
all records returned. (1997)
What's going on???? (2000)
Smith Micro supports our users in so many ways... We are here to (1999)
Unsibscribe Was: UPS uber integration (2007)
Sort Order on a page search (1997)
Multiple serial numbers (1997)