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