Differences

This shows you the differences between two versions of the page.

--- public:tellmaps_url_and_seo [2014/04/25 13:00]
honzik [Javascript implementation]
+++ public:tellmaps_url_and_seo [2014/05/05 07:27] (current)
honzik
@@ Line 21: / Line 21: @@
   * a **local hash**, ''#local-hash'' - this is used as a normal hash, i.e. to scroll to a given part of document (top / bottom etc).
-[Implementation] code to retriveve params from hash part: https://gist.github.com/miohtama/1570295
+[Implementation details] code to retriveve params from hash part: https://gist.github.com/miohtama/1570295
 ===== URLs for Tellmaps =====
@@ Line 32: / Line 32: @@
   * for site content: directly name of the page, such as ''/contact'', ''/about us'' etc.
   * for tellmaps: identifier of tellmap, tellmap ID or name. Arbitrarily, edition name. Examples: ''/tellmap/oil-consupmtion'' or with edition, ''/tellmap/angola/human-resouce-index''. The identifiers should be URL-parsable strings in lower case, or less preferably ID (numeric). The nesting of edition/map is better for SEO purposes.
-  * for country/province profiles: should be very simmilar but using different prefix than ''tellmaps'' such as ''/province/{edition_name}/{province_name}''
+  * for country/province profiles: should be very simmilar but using different prefix than ''tellmap'' such as ''/province/{edition_name}/{province_name}''
   * ...some more?
-The general rule of thumb is: if we have a content we want to serve to search index as static, it should have an unique path.
+The general rule of thumb is: if we have a content we want to serve to search engine as a static document, it should have an unique path component.
 ==== Param set ====
@@ Line 48: / Line 48: @@
 Advantages of param set over path set (such as ''/tellmap/WDAWORLD01/date/1974/focus/BRA/cartogram/true''):
-  * params are simpler to parse / assemble
+  * params are simpler to parse / assemble, it's much harder to make a mistake as would be in the above if we remove one part of component, such as ''date''
   * we can distinguish between what is a path to resource, and what is only a different way to display it
@@ Line 58: / Line 58: @@
 ===== Javascript implementation =====
-The main idea is to create a Javascript service which can be called from existing system modules to perform URL-based operations.
-API should provide:
 <code javascript>
 /**
- * Register a given path.
+ * revised version with one settings object and multiple callback definitions
- * @param uri_string string with path. May contain variables in the format of '':variable'' - will be passed to callback on request.
+ * @param settings - collection {}, specify these properties:
- * @param callback - a function in the form of function(passed_vars, get_vars)
+ *  - path - string - define a path component with possible :variable notation
- *   passed_vars is a collection of { variable_name: variable_value }
+ *  - onPathSet - function(variables) - pass in a callback to be called whenever a path changes
- *   get_vars is a collection of param set (GET) in form of { param_name: param_value } with automatic completion from default_params_object
+ *                    - @param variables - collection of passed :variable values
- *   function will be called whenever URI matches on URI change
+ *                        in format { variable_name: variable_value }
- * @param default_params_object - contains default GET values in form of { param_name: param_def_value }
+ *  - onPathOut - function() - pass in a callback to as destructor function
+ *              - is called whenever path components change from this path
+ *  - onParamsChange - function(params) - pass in a callback to be called whenever a param string changes
+ *                     - @param params - collections of passed GET params
+ *                         in format { param_name: param_value }
+ *  - defaultParams - collection - define an array of default GET values - they automatically pre-fill the
+ *                   params in onParamsChange callback if not provided from GET
+ *  - onHashChange - function(local_hash) - pass in a callback to be called whenever a local hash part changes
+ *                     - @param local_hash - provides new value of local_hash
+ *     - @default if not defined, will perform a scroll to page top / element of ID #local_hash,
+ *                as standard hash does
+ *  - debug - boolean - provide console.log outputs on various operations of this registerURI block
  * @return none
+ *
+ * notes:
+ *  - all callbacks have "this" set which can access the following:
+ *    getHash(), getParams(), getParamString(), getPath()
+ *    please do not use their "set" counterparts directly.
  **/
-function registerURI( uri_string, callback, default_params_object ) {
+function registerUri( settings ) {
+...
 /**
@@ Line 84: / Line 97: @@
  *   function will be called on URI parse failed
  * @return none
+ *
+ * notes:
+ *  - callback has "this" set which can access the following:
+ *    getHash(), getParams(), getParamString(), getPath()
+ *    please do not use their "set" counterparts directly.
  **/
-function onURIFail( callback ) {
+function onUriFail( callback ) {
+...
-/** do we need more API? **/
+/**
+ * Get proper URI string to be used in parts of the app
+ * @param path - string, path component part
+ * @param get_params - get param collection in the form of { param_name : param_value }
+ * @param local_hash - string, local hash part
+ * @return string final string
+ **/
+function getUriString( path, get_params, local_hash ) {
+...
 </code>
+This solution has these advantages:
+  * destructor on path component change - can be used to free memory-intensive resouces, kill dialogs etc.
+  * separate GET params / path component / local hash change callbacks - better, isolated events. The event order is as follows:
+<code>
+(change a path component) -> trigger onPathSet -> trigger onParamChange -> trigger onHashChange
+(change a params part) -> trigger onParamChange only
+(change a local hash part) -> trigger onHashChange only
+</code>
+===== Server-side implementation =====
+==== Old URI redirection ====
+Should perform a redirection from old to new format using rules described above. Should be done server-side with R=301 redirects.
+==== SEO - support ====
+Shebang format has an advantage in that it allows search engines to crawl them. When it notices the shebang format such as ''http://example.com/#!/some/path'', it automatically requests ''http://example.com?_escaped_fragment=/some/path'' and this can be processed using the server and serving the search engine with custom SEO-ready content version of a given resource.
+**This will need much more through-thinking** but the URL part is a good start.

Kurzor wiki

User Tools

Site Tools

Differences

Page Tools