I keep hearing, especially here on StackOverflow, about people generating webpage content "dynamically." Does this mean generating content anytime after design time, or only on the client side, or some other definition?
In other words, as it relates to web development, what is the definition of "dynamic"?
This means that you are generating HTML through code, i.e., PHP, python, etc. Instead of hosting static HTML pages, you can generate HTML which is representative of the current state of your site/DB.
As with any popular word, people use it to mean many different things.
Original definition: static web pages were just a file that the server read off the disk and served verbatim. dynamic pages included code, such as PHP, that was interpreted by the server and replaced with specially-tailored information before it was sent to the user.
Static pages don't really exist anymore. Any site you care about will be "dynamic" in some form. As a result, the term got recycled to mean any number of things:
A page that rearranges its DOM and/or CSS after it has been received from the server. This is usually accomplished with Javascript, and may involve hiding/showing different parts of the page or displaying them in different ways. For example, a tabbed interface that displays different pieces of the page depending on which tab the user clicks on.
A page that requests new information from the server with AJAX requests and displays it using a method similar to #1. For example, user clicks on "More..." next to an article stub and the entire article is loaded and displayed without the need for a full page refresh.
Everything that involves more on the part of the server than to just transmit a file on its harddisk.
It refers to the possibility of generation of complete web pages based on content that was not known or available at the time that the "scaffolding" for the web pages was created.
A dynamic web page give you new information for each view (maybe). For example, a static webpage has always the same information on it, a dynamic web page contents can change, depending on specific variables, like which user is logged in etc.
Values that are not hard coded into the code that forms the website. The values can come from a number of sources including databases which have their content created by users, or scraped from other websites or any other number of places.
Static content is not changed between requests, dynamic content may be changed depends of time, request parameters etc. Static content usually is stored in files (like html, css, images, scripts etc.). Dynamic content is generated. Generation process usually uses two parts: page template that contains page markup in special format with placeholders for dynamic parts, and other data that are obtained from external sources like database, web service etc. Special application combines template with data to get final html (or other content) is responded to request.
Dynamic content is by definition changes with time and person.Your gmail data is different from mine(person).Both of us receive emails regularly(time),atleast.
A dynamic web page is a kind of web page that has been prepared with fresh information (content and/or layout), for each individual viewing. It is not static because it changes with: the time (ex. a news content), the user (ex. preferences in a login session), the user interaction (ex. web page game), the context (parametric customization), or all of them.
Ajax combines client and server side dynamic data.
Dynamically has been used to mean:
1. content or result generated on the fly. not ahead of time. generation follows some kind of process where a script or function is invoked.
2. re-calculated, not cached.
3. using some kind of lookup (as in the case of dynamic methods in an object).
4. not statically.
Related
I am trying to have a single GAS project that changes its UI by serving up different HTML pages based on what the user clicks. I cannot figure out how to serve up different HTML from the script, replace the current browser page and retain state. Any help appreciated. Thank you.
I use two options:
Have a main page which has buttons or text areas with onchange set to a function which calls back to the server side and gets new page data, then replace the current page or a portion of the page, with the new page.
Pass parameters in the URL and have the server side doGet() parse the parameters and branch to load a given page based on these values.
I have used a combination of both of these effectively. Basically I have a div which has my "menu" and a div which is the section to be replaced. My menu changes and then data is sent back to the server to get the dynamic body. The HTML is returned and then I replace using innerHTML.
In the same code I offer the ability to pass menu values via the published URL. This allows me to go directly to some values if I so choose as I have a Google Site where we embed the script into pages and the menu selections may be specific to that page. It allows us to use an iFrame to show the web app and go directly to the pertinent interface.
With google.script.run you can run any script on the server from the html page. By communicating with the server you have access to PropertiesService which gives you the capability to store information between pages. Personally I like the HTML Service createHtmlOutput(html) because I can edit the html without having to edit a separate page.
I decided to answer your question here so that I could use the code section.
Question:
I am actually looking to avoid manipulating the HTML and serve up a
completely different HTML file stored in the project. How do I make
the page call the script again and replace itself with the new
content?
We I'm guessing that completely replacing the page is not really what you want because the user will suffer a page refresh. But you could create divs like this:
<style>#R01{display:none;}</style>
<div class="replaceable" id="R01"></div>
If you put all your replaceable content in divs like that then you can request content from the server via calls like this:
google.script.run
.withSuccessHandler(updateConversation)
.withFailureHandler(showStatus)
.getConversation();
and put the new content into the appropriate divs and then change the css with another pair and turn the old content off and the new content on. Thereby avoiding a page refresh. Don't forget to save the old data into the PropertiesService first. So I don't think changing the entire page is the way to go but I could be wrong. I think just changing some of the internal content will avoid the need for a total page refresh. If you want to change images you can avoid another download by using CSS Sprites
I am planning to design a web application with multiple HTML and JSP pages. The first page of myapp (index.html) loads up with the url
localhost:8080/mywebapp
without an explicitly pointing it to
localhost:8080/mywebapp.index.html
because web-xml has index.html in its startup script. Thats perfectly fine!
But how to toggle between multiple JSPs and HTMLs that are in the web app keeping the URL constant
localhost:8080/mywebapp
The user should not be knowing the navigation pattern when he is using the web-app.
Ideas on any frameworks or implementations are highly appreciated.
Thanks
Leaving aside the fact that you shouldn't do this, essentially what you have to do is bypass the standard routing method of your application.
You can do this one of two ways.
1) Use Ajax to call all the different URLs you need from within a single page. This will give you the single URL you're looking for though it doesn't of course prevent anyone from trivially working out what the actual navigation URLs are and unless you build a single page app and do some really evil interdependencies finding your navigation is trivially easy.
2) Your second option would be to create a single servlet which takes parameters which identify which part of your application you want to use. If you really wanted to be horribly evil you could hash those arguments with some form of per user short duration cookie so that even if they identify the actual web calls you're making running them manually won't actually work.
i have a website which contains many news articles. IN the database, each article has so-called "tags" which the user sees displayed alongside the article. When the user clicks on the tag, they are directed to a list of other articles also containing this tag.
Should I generate a distinct HTML page for each newly created tag, or should I create one single page and vary the content based on what tag the user clicked on using session variables????
obviously, the pages will not be completely static since I will update them everytime a new article with a matching tag is uploaded
You certainly shouldn't use session data. That is for data that needs to persist, but it set on a per user basis. Using it for per-request data will just break bookmarking and introduce race conditions.
You should have a distinct URI for each tag. It doesn't matter (from an end user perspective) if you use dynamically generated content (either via a query string, or parsing the URI in your server side code (most frameworks, e.g. Dancer, will handle this for you)) or if you use generated static pages.
Static pages make it easier to handle caching and give better performance on very high traffic systems, but tend to require a rebuild of large sections of the site if content changes. You can get similar performance improvements by using server side caching (e.g. via memcached).
Dynamic pages are usually simpler to implement.
I suggest you to create a listing page that contains title and small description of all articles containing a particular tag similar to WordPress.
For example, here is listing page for the tag jQuery:
http://sarfraznawaz.wordpress.com/tag/jquery/
I would create one page, and then rewrite the url so that it referenced the tag page so something like this
Tag element == New
tagpage.aspx
http://www.yourwebsite.com/New.aspx
this allows you to have one page to update the content with but allows each page to be indexed by Google.com.
I'm not sure what language you are using but I would look up URL rewriting
here's a link for rewriting in apache:
http://httpd.apache.org/docs/2.0/misc/rewriteguide.html
here's a link for rewriting in asp.net:
http://msdn.microsoft.com/en-us/library/ms972974.aspx
Is it possible to make JSON data readable by a Google spider?
Say for instance that I have a JSON feed that contains the data for an e-commerce site. This JSON data is used to populate a human-readable page in the users browser. (I.E. The translation from JSON data to human displayed page is done inside the users browser; not my choice, just what I've been given to work with, its an old legacy CGI application and not an actual server-side scripting language.)
My concern here is that, the google spiders will not be able to pickup/directly link to the item in question when a user clicks on it in google, being presented with an index page full of all the items, rather than being linked directly to the item they clicked on.
Is there anyway of "informing" the google spider in the JSON that what they should feed the user a different link?
While Google does crawl and index JavaScript in some circumstances, it's still best to serve "normal" (X)HTML content if at all possible. In this case, it would help to know the rest of the site's setup, in particular: is the JSON content just used to create a feed of links to the product pages (with static content) or are all product pages also generated by JSON feeds? If the feed is only used to point to the actual product pages (which are static) then one way to make the product pages discoverable could be to create a HTML sitemap page or some other alternate form of navigation. A XML Sitemap file can also help, but I would recommend not using it as the sole way of making the product pages discoverable.
If all of the content is only accessible through JSON feeds, then I think you will have to make some bigger changes if you want that content to be accessible through search results.
One way to handle it could also be to use the new JavaScript crawling/indexing proposal, which basically would result in a headless browser being set up between your site and Google: http://code.google.com/web/ajaxcrawling/ (whether setting this up or revamping the rest of the site is easier is hard to say :-))
You should make a wrapper page in server-side code around the JSON data, and respond to requests with either the wrapper or the regular version depending on the User-Agent.
What I mean by autolinking is the process by which wiki links inlined in page content are generated into either a hyperlink to the page (if it does exist) or a create link (if the page doesn't exist).
With the parser I am using, this is a two step process - first, the page content is parsed and all of the links to wiki pages from the source markup are extracted. Then, I feed an array of the existing pages back to the parser, before the final HTML markup is generated.
What is the best way to handle this process? It seems as if I need to keep a cached list of every single page on the site, rather than having to extract the index of page titles each time. Or is it better to check each link separately to see if it exists? This might result in a lot of database lookups if the list wasn't cached. Would this still be viable for a larger wiki site with thousands of pages?
In my own wiki I check all the links (without caching), but my wiki is only used by a few people internally. You should benchmark stuff like this.
In my own wiki system my caching system is pretty simple - when the page is updated it checks links to make sure they are valid and applies the correct formatting/location for those that aren't. The cached page is saved as a HTML page in my cache root.
Pages that are marked as 'not created' during the page update are inserted into the a table of the database that holds the page and then a csv of pages that link to it.
When someone creates that page it initiates a scan to look through each linking page and re-caches the linking page with the correct link and formatting.
If you weren't interested in highlighting non-created pages however you could just have a checker to see if the page is created when you attempt to access it - and if not redirect to the creation page. Then just link to pages as normal in other articles.
I tried to do this once and it was a nightmare! My solution was a nasty loop in a SQL procedure, and I don't recommend it.
One thing that gave me trouble was deciding what link to use on a multi-word phrase. Say you had some text saying "I am using Stack Overflow" and your wiki had 3 pages called "stack", "overflow" and "stack overflow"....which part of your phrase gets linked to where? It will happen!
My idea would be to query the titles like SELECT title FROM articles and simply check if each wikilink is in that array of strings. If it is you link to the page, if not, you link to the create page.
In a personal project I made with Sinatra (link text) after I run the content through Markdown, I do a gsub to replace wiki words and other things (like [[Here is my link]] and whatnot) with proper links, on each checking if the page exists and linking to create or view depending.
It's not the best, but I didn't build this app with caching/speed in mind. It's a low resource simple wiki.
If speed was more important, you could wrap the app in something to cache it. For example, sinatra can be wrapped with the Rack caching.
Based on my experience developing Juli, which is an offline personal wiki with autolink, generating static HTML approach may fix your issue.
As you think, it takes long time to generate autolinked Wiki page. However, in generating static HTML situation, regenerating autolinked Wiki page happens only when a wikipage is newly added or deleted (in other words, it doesn't happen when updating wikipage) and the 'regenerating' can be done in background so that usually I don't matter how it take long time. User will see only the generated static HTML.