Tag Archives: forms

Create complex form field showing and hiding rules with jQuery Interdependencies library

Posted on by
10

jQuery Interdependencies is a library to create rules for showing and hiding form fields dynamically on your HTML form. It’s use case are the situations where the form filling can take different decision tree paths and the field choices and values affect other fields. The most common scenario is that you have  a “please specify” style text field which becomes available if the user marks a certain checkbox choice.

Test the simple demo above online. This is what the rule code for the above form looks like (see the orignal blog post for syntax highlighting):

// Start creating a new ruleset
var ruleset = $.deps.createRuleset();

// Show diet text input option only when special diet option is selected
var dietRule = ruleset.createRule("#diet", "==", "special");
dietRule.include("#special-diet");

// Make these fields visible when user checks hotel accomodation
var hotelRule = ruleset.createRule("#accomodation", "==", true);
hotelRule.include("#adults");
hotelRule.include("#children");

// Make the ruleset effective on the whole page
ruleset.install();

However, jQuery Interdependecies can do much more. Using the jQuery Interdependecies library simplifies the process of creating form logic rules over vanilla Javascript / jQuery a lot.

  • Your code does become a spaghetti of ifs, elses and Javascript callback functions
  • It is not limited to an input type, but works with all HTML controls: text, checkbox, radio button, select dropdown, etc.
  • It correctly handles nested decision trees, where your form 1st level choice reveals 2nd level choices which in turn reveal 3rd level choices and so on
  • It works well with dynamically generated forms and situations where there are multiple forms on a single page
  • It has API documentation based on JSDuck. Everyone loves good documentation.
  • It is independent from any HTML markup or form framework: you can use it in any project

So, let’s a have little more complex example what we can do:

The example above is from real life system, but you can try the simplified demo version online.

Enjoy – jQuery Interdependencies Github.

\"\" Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+

Unprotecting Microsoft Word .docx document

Posted on by
29

Let’s say that you get a form, for example from the government, in Microsoft Word format. You need to fill in the fields which are supposed to be nicely laid out for you. However there are problems filling in those fields because of document formatting, Microsoft Word version incompatibility, etc. argh reasons. This wouldn’t happen in the beatiful word of Office productivity suite, would it?

You could easily fill in the form if you could simply just edit the document and put the text there. But this is prevented using Microsoft Word form password protection mechanism. You need to know the password to enable the editing of the document.

The documention “protection” is not actually very big protection at all. You simply have a flag in the .docx file telling “oh please dear user do not change my beautiful document and just try to have your text in the predefined fields”. The authors of the document are probably right and an average Joe will destroy the document formatting in Word. On the other hand if you know what you are doing you just can get your paperwork done. The password, saved inside the document, is not very much protection, as you can manually gut the document and flip the flag inside.

.docx is actually zip archive containing XML files and you can manipulate its contents with a text editor and ZIP program. Unzip:

mkdir temp
cd temp
unzip ../"KEHITTÄMISTUEN MAKSATUSHAKEMUS.docx"

Edit the unzipped file word/settings.xml using your favorite plain-text editor.

Remove attributes in the following element:

<w:documentProtection w:edit="forms" w:enforcement="1" 
  w:cryptProviderType="rsaFull" 
  w:cryptAlgorithmClass="hash" 
  w:cryptAlgorithmType="typeAny" 
  w:cryptAlgorithmSid="4" 
  w:cryptSpinCount="50000" 
  w:hash="iMNelgcwaqcjZrxjRjtl0SRWLpY=" 
  w:salt="ik/s9VEtUXAkIehywGuyqQ=="/>

Now it looks like:

<w:documentProtection />

Re-zip:

zip -ur ../KEHITTÄMISTUEN\ MAKSATUSHAKEMUS.docx *

Re-open in Microsoft Word.

Poof. The form protection is gone. Sip coffee and continue with your inspirating paper work.

\"\" Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+

SEO tips: query strings, multiple languages, forms and other content management system issues

Posted on by
12

This post is collection of search engine optimization tips for content management systems, especially for Plone.

1. Do not index query strings

It is often desirable to make sure that query string pages (http://yoursite/page?query_string_action=something) do not end up into the search indexes. Otherwise search bots might index pages like site’s own search engine results  (yoursite/search?SearchableText=…) lowering the visibility of  actual content pages.

GoogleBot has regex support in robots.txt and can be configured to ignore any URL ? in it. See the example below.

Query string indexing causes the crawler crawl things like

  • Various search results (?SearchableText)
  • Keyword lists (?Subject)
  • Language switching code (?set_language)… making set_language appear as the document in the search results

Also, “almost” human readable query strings look ugly in the address bar…

2. Top level domains and languages

Using top level domain name (.fi for Finland, .uk for United Kingdoms, and so on.) to make distinction between different languages and areas is optimal solution from the SEO point of view. Search engines use TLD information to reorder the search results based on where  the search query is performed  (there is difference between google.com and google.fi results).

Plone doesn’t use any query strings for content pages. Making robots to ignore query strings is especially important if you are hosting multilingual site and you use top level domain name (TLD) to separate languages: if you don’t configure robots.txt to ignore ?set_language links only one of your top level domains (.com, .fi, .xxx) will get proper visibility in the search results. For example we had situation where our domain www.twinapex.fi did not get proper visibility because Google considered www.twinapex.com?set_language=fi as the primary content source (accessing Finnish content through English site and  language switching links).

3. Shared forms

Plone has some forms (send to, login) which can appear on any content page. These must be disallowed or otherwise you might have a search result where the link goes to the form page instead of the actual content page.

4. Hidden content and content excluded from the navigation

Any content excluded from the sitemap navigation  should be put under disallowed in robots.txt. E.g. if you check “exclude from navigation” for Plone folder remember to update robots.txt also.

In our case, our internal image bank must not end up being indexed, though images themselves are visible on the site. Otherwise you get funny search result: if you search by person’s name the photo will be the first hit instead of biography.

5. Sitemap protocol

Crawlers use Sitemap protocol to help determining the content pages on your site (note: sitemap seems to be used for hinting only and it is not authoritative).  Since version 3.1 Plone can automatically generate sitemap.xml.gz. You still need to register sitemap.xml.gz in Google webmaster tools manually.

There exists a sitemap protocol extension for mobile sites.

6. Webmaster tools

Google Webmaster tools enable you to monitor your site visibility in Google and do some search engine specific tasks like submitting sitemaps.

I do not know what kind of similar functionality other search provides have. Please share your knowledge in the blog comments regarding this.

7. HTML <head> metadata

Search engines mostly ignore <meta> tags besides title so there is no point of trying fine-tune them.

8. Example robots.txt

Here is our optimized robots.txt for www.twinapex.com:

# Normal robots.txt body is purely substring match only
# We exclude lots of general purpose forms which are available in various mount points of the site
# and internal image bank which is hidden in the navigation tree in any case
User-agent: *
Disallow: set_language
Disallow: login_form
Disallow: sendto_form
Disallow: /images

# Googlebot allows regex in its syntax
# Block all URLs including query strings (? pattern) - contentish objects expose query string only for actions or status reports which
# might confuse search results.
# This will also block ?set_language
User-Agent: Googlebot
Disallow: /*?*
Disallow: /*folder_factories$

# Allow Adsense bot on entire site
User-agent: Mediapartners-Google*
Disallow:
Allow: /*

9. Useful resources