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 >> fromto >> 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:

    
  1. Re: [WebDNA] [store] and [recall]: default db location (WebDNA TPP 2015)
  2. Re: [WebDNA] [store] and [recall]: default db location (Terry Wilson 2015)
  3. Re: [WebDNA] [store] and [recall]: default db location (Donovan Brooke 2015)
  4. Re: [WebDNA] [store] and [recall]: default db location (Donovan Brooke 2015)
  5. Re: [WebDNA] [store] and [recall]: default db location (Donovan Brooke 2015)
  6. Re: [WebDNA] [store] and [recall]: default db location (christophe.billiottet@webdna.us 2015)
  7. Re: [WebDNA] [store] and [recall]: default db location (Kenneth Grome 2015)
  8. Re: [WebDNA] [store] and [recall]: default db location (christophe.billiottet@webdna.us 2015)
  9. [WebDNA] [store] and [recall]: default db location (Kenneth Grome 2015)
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 >> fromto >> 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:

[WebDNA] Sorting questions (2009) Unique SKU Numbers (2000) [WebDNA] Stuck with installing Webdna 8.5 (2017) Help with ShowNext (1998) Beta List (1998) math a various prices (1997) Writefile problem (1999) [WebDNA] Sandbox Triggers (2008) [subtotal] and others (1997) [OT] - Block Traffic to DevBox (2003) Authentication (1998) WebCat2 - [format thousands] (1997) Register First (2000) WebCat2b13MacPlugin - [math][date][/math] problem (1997) Verify entry into a text field (2005) Help! (1996) docs for WebCatalog2 (1997) HELP WITH DATES (1997) Re:2nd WebCatalog2 Feature Request (1996) Multiple catalog databases and showcart (1997)