anyMeta 3.3 series refreshes Ajax and standard templates

Figure and Document handling

We changed the Figure and Document handling. Figures and documents are “hung” on articles and so on using the predicates figure and document. The interesting point here is that within the templates we refer to specific images. The first group of images is mostly used at the top of the page, withing the text we refer to yet another set of images and below the text we might want to have yet another set of figures.

Of course, where everything shows up depends completely om the templates being used.

To make it easier to add images to specific spots on your page we added the concept of groups of images. Each group consists of 10 items and we have six groups. We have changed the on the page editing and the admin backend to correctly handle these groups of images.

Because of these changes it is now possible to control where your figure will show up, without resorting to specific templates. A nice step forward to make the common set of templates applicable to many more sites.

This change introduced an incompatibility with older versions. One of the reasons to call this release a 3.3 and not a 3.2 release.

The common templates

Which brings us to the common templates. This is the set of templates that is build in into anyMeta, part of every install. The templates are designed for flexibility, so that with proper application of css we can derive many different website design without having to implement specific templates.

Besides being extremely flexible to use, the templates also support a very nice implementation of editing content on the pages themselves (that is without resorting to backends and the like). For that we use JQuery, an excellent Ajax toolkit. See more below.

Katharina, Bas and Guilherme have been hard at work to make this all possible. My compliments to them!

Ajax support moves to JQuery

JQuery? Didn't I wrote before that we were using Dojo? Indeed, we were using Dojo. Dojo is still in place for older templates, but all development is done using JQuery.

We had major performance problems with Dojo, originating in the way Dojo analyses the html page. It first makes a copy of the interesting parts of the DOM tree, and then uses that copy for parsing and adding behaviour or visible modifications. Dojo has support for parsing parts of the DOM tree instead of the whole DOM. The performance problem remains though, as Dojo can't be configured to parse till a certain depth. So when you want a Dojo supported tab bar on top of your page, Dojo will parse the whole page.

This results in a very noticable delay after the page has been loaded. This delay was unacceptable for us and our customers. Especially when the page gets more complicated.

Moving to JQuery solved all our performance problems. And it solved another problem, it is easier to program direct to the DOM than indirect as Dojo does. The APIs provided by the browsers are powerful, especially when combined with the selectors JQuery provides.

JQuery turned out to be an excellent choice for the implementation of more and more robust and much wanted functionality in the client side of anyMeta sites.

Thanks to Bas and Guilherme for making this work!

Template engine optimisation and changes

By caching more information I made the template engine more efficient. All information about templates is stored in the memcache, making it easier and faster to check if there is a database stored template usable for displaying things with a certain kind or type.

I also made the template engine more flexible and adapted to the usage of the common templates. It is now possible to override specific parts of the common templates with database based templates, css or javascript.

So is it now possible to create a specific template for a specific type, something that should be completely different shown, but without disrupting the templates for all other content. Eg. a photo book context item (as on the sides of these pages) could show the first four photos of the set, but normal sets just show a single image and more text.

Better support for keywords and tags

Do you know that feeling of uncertainty, when you tag a photo with (say) two dogs. Shall I use dog or dogs? or both. On Flickr you see that most people resort to both. A typical anyMeta system has a lot less material than the millions of photos Flickr has, so when you tag something wrongly in anyMeta your content has a nice chance of getting lost.

Wouldn't it be nice when it really doesn't matter, that dog and dogs are the same tag? Indeed. And that is what we have done. We have added alternative texts to tags and keywords. Just add in the body a list of alternatives, one per line as a tag can be multiword. Your tag will now be found using all of those alternatives. Of course the same holds for multi language versions. Make a tag that is chien, dog and hond and three different languages will be able to find it! And even better, it will display in the correct language for your visitors.

So start meta-tagging your tags and keywords with all alternative spellings and add some nice translations while you are on it!

Bugfixes

Many bugfixes have been done. See the list underneath

Bug fixes (Problem Reports)

• 764 PR: slow matcher takes only things with similar keywords
• 767 PR: winnow/filter on tags is not working
• 809 PR: logon when someone is logged on does not work
• 826 PR: de accuracy van de datum in het thing wordt niet bewaard
• 834 PR: admin gender label H_PERS_GENDER has wrong values
• 835 PR: import vergeet taalversie
• 836 PR: data import zet automatisch imported things on pubstate=9
• 849 PR: import does not create types
• 852 PR: image in any_any only visible after publish
• 863 PR: creating an artefact gives notice
• 866 PR: rss gives warning
• 868 PR: notice after publishing predicate
• 880 PR: new friends list shows duplicates
• 886 PR: saving coverage.date_start with inline edit influence the date_end and vice versa
• 890 PR: any_icon with filter scale always needs a width and a height
• 892 PR: the home_list is not reacting on numbers entered for its length
• 893 PR: {any_img_uri id=$thg_id} resizes the image
• 907 PR: Edit-in-place double character escape?
• 925 PR: any_icon and the symbolic2id (unexpected fallback behaviour)

Change Requests

• 702 CR: default attachment controller: fetch parents for attachment
• 773 CR: check if a new tag is an existing keyword
• 774 CR: Alternative spelling of keywords
• 782 CR: Add pivot table for fulltext keyword/tag search
• 802 CR: parameterised listpublish for children and parents
• 803 CR: parameterised listmatch
• 805 CR: import and create account module (add create accounts when importing CSV data)
• 813 CR: register, 2 times email, 1 time password
• 814 CR: pivoting should be delayed for onthepageedit
• 824 CR: simple search sorteren op textscore (in the admin backend)
• 845 CR: inline edit captions of figures and documents
• 847 CR: set order while connecting an image
• 848 CR: standard controller, add 'add' handling for the 'inline edit'
• 850 CR: add tag (list of tags) using the REST API
• 851 CR: different registration mail depending if user created with import or with register controller
• 906 CR: installer (easier install, more complete, better out-of-the-box experience)