Re: [WebDNA] [store] and [recall]: default db location
This WebDNA talk-list message is from 2015
It keeps the original formatting.
numero = 112070
interpreted = N
texte = Hi Ken! I understand. A default "central" reserved.db is not a bad idea (could be stored = inside /WebDNA folder), but it would store all the information for the = website which could make it big and difficult to handle, while the = "local" one could behave like a "scope" storage. On another side, the = single "reserved.db" concept is more simple, which I like. Then we will anyway have [store = path=3D../../admin/reserved.db]var1=3DJoe[/store] and [recall = var1&path=3D../../admin/reserved.db] to add flexibility. Both solutions have pro and cons. It would be interesting to debate = about it. We are flexible=85. - chris > On 05 Feb 2015, at 17:57, Kenneth Grome
= wrote: >=20 >> from to >> var1 Joe >> var2 Biden >>=20 >> In fact, [store]var1=3DJoe[/store] will do the same as [replace=20 >> db=3Dreserved.db&eqFROMdata=3Dvar1&append=3DT]var1=3DJoe[/replace] >=20 > I think you actually mean this: > [replace db=3Dreserved.db&eqFROMdata=3Dvar1&append=3DT]to=3DJoe[/replace= ] >=20 >=20 >> reserved.db >> If such a database does not exist, it will be automatically >> created at the same level the creating code file is located. >=20 > 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: >=20 > [recall var1] >=20 > 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). >=20 > 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: >=20 > [recall name=3Dvar1&db=3Dreserved.db] > [recall name=3Dvar1&db=3D../databases/reserved.db] > [recall name=3Dvar1&db=3Da/deeper/folder/reserved.db] >=20 > 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! >=20 > 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: >=20 > 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 >=20 > OR ... >=20 > 2- using a more complex tags like this in all our templates simply > to recall our "global" permanent variables: >=20 > [recall name=3Dvar1&db=3D/databases/reserved.db] >=20 > =46rom my point of view, having the default db location the same as > the template is a mistake for these reasons too: >=20 > 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. >=20 > 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. >=20 > 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=3Dvar1&db=3D../dbs/reserved.db] tag format to > designate a db in another folder. >=20 > 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? >=20 >=20 > 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. >=20 > Please correct me if my understanding is wrong about any of this. > Thank you. >=20 > :) >=20 > Regards, > Kenneth Grome > WebDNA Solutions > http://www.webdnasolutions.com > Web Database Systems and Linux Server Management >=20 >=20 > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us
Associated Messages, from the most recent to the oldest:
Hi Ken! I understand. A default "central" reserved.db is not a bad idea (could be stored = inside /WebDNA folder), but it would store all the information for the = website which could make it big and difficult to handle, while the = "local" one could behave like a "scope" storage. On another side, the = single "reserved.db" concept is more simple, which I like. Then we will anyway have [store = path=3D../../admin/reserved.db]var1=3DJoe[/store] and [recall = var1&path=3D../../admin/reserved.db] to add flexibility. Both solutions have pro and cons. It would be interesting to debate = about it. We are flexible=85. - chris > On 05 Feb 2015, at 17:57, Kenneth Grome = wrote: >=20 >> from to >> var1 Joe >> var2 Biden >>=20 >> In fact, [store]var1=3DJoe[/store] will do the same as [replace=20 >> db=3Dreserved.db&eqFROMdata=3Dvar1&append=3DT]var1=3DJoe[/replace] >=20 > I think you actually mean this: > [replace db=3Dreserved.db&eqFROMdata=3Dvar1&append=3DT]to=3DJoe[/replace= ] >=20 >=20 >> reserved.db >> If such a database does not exist, it will be automatically >> created at the same level the creating code file is located. >=20 > 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: >=20 > [recall var1] >=20 > 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). >=20 > 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: >=20 > [recall name=3Dvar1&db=3Dreserved.db] > [recall name=3Dvar1&db=3D../databases/reserved.db] > [recall name=3Dvar1&db=3Da/deeper/folder/reserved.db] >=20 > 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! >=20 > 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: >=20 > 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 >=20 > OR ... >=20 > 2- using a more complex tags like this in all our templates simply > to recall our "global" permanent variables: >=20 > [recall name=3Dvar1&db=3D/databases/reserved.db] >=20 > =46rom my point of view, having the default db location the same as > the template is a mistake for these reasons too: >=20 > 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. >=20 > 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. >=20 > 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=3Dvar1&db=3D../dbs/reserved.db] tag format to > designate a db in another folder. >=20 > 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? >=20 >=20 > 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. >=20 > Please correct me if my understanding is wrong about any of this. > Thank you. >=20 > :) >=20 > Regards, > Kenneth Grome > WebDNA Solutions > http://www.webdnasolutions.com > Web Database Systems and Linux Server Management >=20 >=20 > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us
christophe.billiottet@webdna.us
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 can't find database (1997)
Webcat XML/XSLT Performance vs. static Html (2006)
New syntax feedback for 4.0 (2000)
WebCat2b13MacPlugIn - More limits on [include] (1997)
using showpage and showcart commands (1996)
Globals Problem and now can't close databases (2003)
shipcost (1997)
Mystery File (2005)
OT: Amazon Patents (2000)
Template not found error messages (1997)
Email (1998)
Emailer setup (1997)
SMTP Mail Server (2003)
WebCommerce Security Alert! (1996)
Converting Esiting Html Table Forms to WebCat (1997)
More on the email templates (1997)
Need help (1998)
Just a thought (1998)
RE: Discounting prices across a site (1997)
Sendmail truncation in Eudora Clients (1998)