Re: [WebDNA] Issues regarding static vs. dynamic pages
This WebDNA talk-list message is from 2011
It keeps the original formatting.
numero = 106154
interpreted = N
texte = That's what I did. -Dan -------------------------------------------------- From: "William DeVaul"
Sent: Monday, January 24, 2011 7:31 AM To: Subject: Re: [WebDNA] Issues regarding static vs. dynamic pages > Can't you just write the static file whenever the content or the > keyword database is changed? This way changes are immediately visible > and the page generated once. This is similar to memcached in theory > which the sites that can withstand and Oprah mention would have. > > On Mon, Jan 24, 2011 at 9:48 AM, Dan Strong wrote: >>>Or better yet, I would prefer to just write the results to a complete set >>> of static web pages for the entire website. >> >> >> >> This is exactly what I ended up doing, except that I made the results >> static >> includes and now include them in the site as opposed to having so many >> staic >> actual pages. This way, the purpose of the CMS isn't lost. In doing this, >> I >> also figured out how to make it so the friendly URLs can work properly >> and >> will be testing and implementing them today. >> >> >> >> -Dan >> >> From: Kenneth Grome >> Sent: Monday, January 24, 2011 5:33 AM >> To: talk@webdna.us >> Subject: [WebDNA] Issues regarding static vs. dynamic pages >> >>> >> every single word from each text of >> >>> >> each page is compared to a database in order to >> >>> >> create dynamic links: all the links from the websites >> >>> >> are in fact created "on the fly". >> >> If I had coded this type of feature I would not have done it this way -- >> precisely because it is slow and unnecessarily demanding of resources >> with >> every hit to the website. >> >> Instead I would create a script that processes "every single word from >> each >> text of each page" only once a day, and I would have this script write >> the >> resulting text with links to a new database. >> >> Or better yet, I would prefer to just write the results to a complete set >> of >> static web pages for the entire website. Then the server can deliver >> these >> static pages without requiring such a heavy load on WebDNA at the time >> each >> page is requested. >> >> The end result is that the site could be made up of mostly static pages >> not >> served by WebDNA. Yet those static pages would still be dynamically >> generated by WebDNA once a day to make sure they are current and >> up-to-date >> every 24 hours. >> >> Naturally the site admin should be able to run this script manually so he >> can update these pages "on demand" whenever he makes an important update >> that needs to be displayed to visitors immediately. >> >> I've done this kind of thing for several client sites before so I know it >> works -- and it works well. It makes the website very fast because most >> pages can be cached and gzipped by the server -- rather than being >> rendered >> by WebDNA upon each request -- thus avoiding unnecessarily heavy demands >> on >> WebDNA when those pages are requested. >> >> And by using a trigger to run my script in the middle of the night when >> almost no one is visiting, the heavy WebDNA processing is performed at >> the >> most opportune time in terms of server resources, so it never slows down >> the >> experience of daytime visitors unnecessarily. >> >> Oh, you say that with your site consisting of mostly static pages you >> cannot >> use WebDNA to let your visitors dynamically search your site? Don't worry >> about it because they couldn't care less what software powers the search. >> So >> instead of using WebDNA for site searches, just give your visitors a >> Google >> search box, and let them do a custom Google search within your mostly >> static >> site ... >> >> Not only are most people already familiar with the way Google search >> works >> (so they like this option) but this little trick also insures that Google >> *WILL* index all your static web pages -- on a regular basis -- probably >> once a day if your page headers tell Google that those pages expire >> daily. >> >> Sincerely, >> >> Kenneth Grome >> >> --------------------------------------------------------- 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 >> --------------------------------------------------------- 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 > --------------------------------------------------------- > 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:
That's what I did. -Dan -------------------------------------------------- From: "William DeVaul" Sent: Monday, January 24, 2011 7:31 AM To: Subject: Re: [WebDNA] Issues regarding static vs. dynamic pages > Can't you just write the static file whenever the content or the > keyword database is changed? This way changes are immediately visible > and the page generated once. This is similar to memcached in theory > which the sites that can withstand and Oprah mention would have. > > On Mon, Jan 24, 2011 at 9:48 AM, Dan Strong wrote: >>>Or better yet, I would prefer to just write the results to a complete set >>> of static web pages for the entire website. >> >> >> >> This is exactly what I ended up doing, except that I made the results >> static >> includes and now include them in the site as opposed to having so many >> staic >> actual pages. This way, the purpose of the CMS isn't lost. In doing this, >> I >> also figured out how to make it so the friendly URLs can work properly >> and >> will be testing and implementing them today. >> >> >> >> -Dan >> >> From: Kenneth Grome >> Sent: Monday, January 24, 2011 5:33 AM >> To: talk@webdna.us >> Subject: [WebDNA] Issues regarding static vs. dynamic pages >> >>> >> every single word from each text of >> >>> >> each page is compared to a database in order to >> >>> >> create dynamic links: all the links from the websites >> >>> >> are in fact created "on the fly". >> >> If I had coded this type of feature I would not have done it this way -- >> precisely because it is slow and unnecessarily demanding of resources >> with >> every hit to the website. >> >> Instead I would create a script that processes "every single word from >> each >> text of each page" only once a day, and I would have this script write >> the >> resulting text with links to a new database. >> >> Or better yet, I would prefer to just write the results to a complete set >> of >> static web pages for the entire website. Then the server can deliver >> these >> static pages without requiring such a heavy load on WebDNA at the time >> each >> page is requested. >> >> The end result is that the site could be made up of mostly static pages >> not >> served by WebDNA. Yet those static pages would still be dynamically >> generated by WebDNA once a day to make sure they are current and >> up-to-date >> every 24 hours. >> >> Naturally the site admin should be able to run this script manually so he >> can update these pages "on demand" whenever he makes an important update >> that needs to be displayed to visitors immediately. >> >> I've done this kind of thing for several client sites before so I know it >> works -- and it works well. It makes the website very fast because most >> pages can be cached and gzipped by the server -- rather than being >> rendered >> by WebDNA upon each request -- thus avoiding unnecessarily heavy demands >> on >> WebDNA when those pages are requested. >> >> And by using a trigger to run my script in the middle of the night when >> almost no one is visiting, the heavy WebDNA processing is performed at >> the >> most opportune time in terms of server resources, so it never slows down >> the >> experience of daytime visitors unnecessarily. >> >> Oh, you say that with your site consisting of mostly static pages you >> cannot >> use WebDNA to let your visitors dynamically search your site? Don't worry >> about it because they couldn't care less what software powers the search. >> So >> instead of using WebDNA for site searches, just give your visitors a >> Google >> search box, and let them do a custom Google search within your mostly >> static >> site ... >> >> Not only are most people already familiar with the way Google search >> works >> (so they like this option) but this little trick also insures that Google >> *WILL* index all your static web pages -- on a regular basis -- probably >> once a day if your page headers tell Google that those pages expire >> daily. >> >> Sincerely, >> >> Kenneth Grome >> >> --------------------------------------------------------- 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 >> --------------------------------------------------------- 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 > --------------------------------------------------------- > 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 >
"Dan Strong"
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:
Date problems (1997)
Sub Totals (2000)
Add to a field (1998)
[BULK] [WebDNA] [BULK] 7.x and 6.x on same server (2012)
Re:2nd WebCatalog2 Feature Request (1996)
Quit revisited (1997)
4.5 on Apache 2 (2005)
Losing Variable Values/Data (2001)
shownext (1997)
creator code (1997)
Bulletin Board needed (2007)
Add (1998)
Max Record length restated as maybe bug (1997)
WebTen and WebCat (1997)
RE: [sendmail]- bcc? (1998)
ShowNext (1997)
preserving the zero's (1999)
More Applescript (1997)
Two submit buttons ? (1997)
need help with textA field (1998)