Some of you use TeamDesk as a back-end data management solution while extracting the content via SOAP API from the database to present on an front-end site, such as online shop. By the way, it's a way TeamDesk promo site works; the list of applications and their categories is managed via TeamDesk application, and the promo site utilizes the API to obtain the info.

Let's describe typical scenario: there is a Product table with Title, Description and Image columns; first two are a obviously a Text, and the last is Attachment.

To present the list of products with images in an HTML you typically need two pages. One will perform API's Login() call, then Query() to get the list of products and then render Title and Description texts and HTML <img> tag referring to the second page. Second page will again perform Login() and GetAttachment() API calls and serve the binary data obtained from latter call as an image.

Suppose your product list page displays 100 products at once. How many API requests it will generate? It's easy to calculate: there would be one Login()/Query() pair from the page itself and one Login()/GetAttachment() pair per product, resulting to 202 calls for each page view. Since each call generates network traffic and the network is a potential bottleneck, is there a way to reduce the number of calls?

Perhaps you can share API object between pages performing login once per session; this approach will cut the number of API requests in half; 102 requests exactly – one for first-time Login(), one Query() and 100 GetAttachment(). But is further optimization possible?

Let's check what typical website visitor does. She reads the list of products (102 requests), then clicks on a link to see more of some product details (this will generate some more requests we are not interested in at the moment). If she's not interested in the product she presses browser's back button or clicks a link to return to the product list to check another product – and this generates yet another 102 requests.

Perhaps you can optimize product list page logic to perform Query() only when list changes, but this requires some relatively sophisticated logic and advanced coding skills. It would be much easier to cut the number of calls to an image-serving page down, or, better to say, you have a chance to remove image-serving page at all.

As you probably know, some time ago we have enabled public access to attachment files. If public access is enabled, the file is served to the user without a need to login. Our web page serving the file performs various browser cache checks and return file only if the browser does not have it cached or cached copy is out-of-date. And now you can utilize this page on your site.

If you include attachment column in your Query() call you'll get back the file name and some additional info separated by semicolon, e.g:

filename;revision;uniqueidentifier

There are two pages in TeamDesk you can refer from your site:

https://www.teamdesk.net/secure/db/<app-id>/attachment.aspx 
and
https://www.teamdesk.net/secure/db/<app-id>/image.aspx

First serves attachment file as is, second assumes the file is image and produces the thumbnail of specified width and height

Both pages accept two parameters:

fid is a number identifying the column. You can obtain this identified by visiting column's page in the setup section and capturing the number following the string column= in the browser's address bar.
guid is an uniqueidentifier, the text after last semicolon in the  attachment string.

To generate the link to attachment file as-is that will be served directly from TeamDesk you'll need to provide an URL to:

https://www.teamdesk.net/secure/db/<app-id>/attachment.aspx?fid=<column-id>&guid=<uniqueidentifier>

Image thumbnails are served in a similar way:

https://www.teamdesk.net/secure/db/<app-id>/image.aspx?fid=<column-id>&guid=<uniqueidentifier>&w=<size>

Last parameter specifies the size of the square box, in pixels, the image will be fit to. The aspect ratio of the image is preserved and resulting image will not exceed box dimensions; e.g. if you specify w=100 16x16 image will remain the same, 400x400 image will be downscaled to 100x100, 200x100 image will be downscaled to 100x50 and 100x200 image will be downscaled to 50x100.

TeamDesk setup sidebar is now extended with Search Keywords box.

This box allows you to search every table for an objects containing the search term in their name or formula. It is quite useful when the user reports a problem or asks for advice mentioning the view or column but forgetting about the table the object is contained. Also, you can now quickly check whether and where some function is used in the formulas. For example if your are planning to upgrade to user property table it is worth searching for Role(, UserToName(, UserToEmail( to gradually replace these calls with role references or references to user property table's columns.

How often you need to add the additional information such as salary or department to your application users' records?

Usually you can do it by creating a table (say, User Properties table) with column of User type as a key and adding necessary additional properties as columns of this table. Whenever you need this info for the user recorded in some other table you can relate two tables and extract all necessary information via lookups.

The problem arises when you need to extract this information for the current user, typically when defining access rights such as "Allow view records related to the people from my department". Before you would need a formula column calculating User() formula and a relationship to user property table and a column to extract the value. But situation gets worse since you need to do it for every table you need this information in.

With "native" support for User Property table it's all much easier now.

First, enable User Property Table feature under Setup > Labs. Once enabled, visit Setup > Sharing / Roles > Set User Property table. TeamDesk will propose you to select existing table having a User column as a key column, or create a new one:

Once user table is selected, it will be extended with E-Mail, First Name, Last Name, Screen Name, Role, Default Set, External Customer and Last Access read only columns containing live snapshot from the information found in setup section.

Also you'll have couple of new options.

* For any column of user type you can create lookups to the information stored in user tables right from the column's view screen:

* Wherever you need an information from User Properties related to current user, you can simply refer to the column of User Properties table by its name.

* Setup's Manage Users page is extended with button to edit corresponding record in User Property table.

Obviously users just invited do not have a record in User Properties. For such users the button is named "Add User Property" and creates new record with user's dropdown pre-selected.

We added a number of shortcuts to manage relation-related settings in TeamDesk.

First of all, there are two new items under Columns section of table's setup menu: Create new lookup column and Create new summary column.

Each one leads to a subset of general Manage Relations page, focusing on selected functionality.

Above is a screenshot from Manage Relations page. Since lookups are relevant for master tables only, Create new lookup page displays only References section:

while Create new summary displays Selections section:

Column list now sports New Lookup and New Reference buttons to replicate setup links' functionality.

Columns participating in relationships as reference columns now report the table(s) they refer to:

Column's view screen displays the information about associated relationship:

Also, relationship's basic properties are edited together with column.

Enjoy!

Now, after selecting a template from the application library we are prompting you to either create a new application or to merge the template with any existing application you own.

This will allow you to build application by combining simple templates together.

Recently we encountered some issues with DOCX templates created in Word 2010. Unlike its predecessor Word 2010 uses more complicated constructs for merge fields we use for placeholders and we did not recognize such definitions properly. We revised merge fields identification algorithm, fixed few other issues by the way and step by step ended up with completely new document generation algorithm.

Our old client-side .DOC generation module used Word Automation to expand the template. When we started working on server-side code, we simply replicated old algorithm with all the quirks – this helped us to ensure that movement from old to new technology will produce (nearly) identical results.

Yet, one part definitely needed improvement: the detail records generation. Due to lack of suitable methods in the automation our code had somehow sophisticated algorithm that tracked row and column index of each placeholder in the detail table and performed replacement of whole cells, not just the placeholders. This caused some formatting and layout restrictions, for example, the font and color should be defined for the cell as whole, not for the content of the cell; nested tables were not allowed.

Now, generator works more straightforward from user's perspective. First we replace all master-level placeholder in the document wherever they are placed. Next, we generate detail tables one by one. Here we have to repeat some part of template for each detail record. Due to lack of non-visual markers in a Word documents and for backward compatibility we define repeatable item the table row. We find and locate all the placeholder for detail table and find innermost table row they have in common. This row will be repeatable block. For each record we clone the row with all placeholders, replace the placeholders and insert now-expanded content back into the table. Here are illustrations:

The row marked gray will be repeatable block since it's a common row for all detail placeholders. Since we now operate on a field level, single table cell can contain several placeholders and/or text around the placeholders.

Now, more complicated layout:

Here we nest detail table into another table. The repeatable block is the row in the inner table since this one is innermost common to both detail placeholders. And now even more complicated:

Here, the row in outer table will be repeated since it's common for both detail placeholders. There is no problem for inner table to contain master information – it will be simply repeated for each row in the detail table.

We are trying to preserve the text formatting wherever possible, but formatting should be applied to placeholder as a whole. Many Word's formatting commands apply to a word the cursor placed on. As we replace the placeholder completely, we do not preserve the styling defined within the placeholder. Moreover, if multiple styles are defined for placeholder content, it's not clear what style to use for content. For example, what font, size, style and color we should use when replacing this?

«Master Info»

As a bonus, we've added column usage information for the documents. Make any change in your app, save and columns will start to report their usage in the DOCX documents.

In this post we'll try to outline the steps you'll need to do to migrate to a new form layout from your existing applications. It's not only the change in a way the form appears on the screen. TeamDesk has developed over the years and many times new features supersede old ones. With new layout we are trying to fold various settings into one consolidated thing.

* In old layout Default Form was displayed in a single-column with order of the columns as defined in a table, without sections, and text blocks. In a new layout, Default Form is a fully featured form with sections, text blocks and columns' order separated from the columns' order defined in the table. If you have single custom form associated with all roles and actions you are few clicks away from successful migration.

* In old layout you were able to define multiple forms per table and associate various forms for different roles and actions. In a new layout we are defining a single form per table; multiple forms are dropped in favor of using form behaviors to specify what columns should be hidden from the form; with behaviors you can emulate role-based differences plus achieve a lot more.

* New layout affects Default Forms only, custom forms are not affected. To see which users will be affected, please check what roles in what tables in your application are associated with Default Form via Setup mode > table's tab > Forms > Associate Forms with Roles and Actions. If your have found the roles you do not want to enable new feature ]instantly, make a copy of Default Form and associate a copy of the form with the role(s).

* To enable new form layout you need to go to Setup mode > Setup tab > Tools section > Labs and enable Grid Form Layout. You can enable or disable this feature anytime.

Once you enable the feature, Forms menu will be reorganized. Old one contained:

• Customize Form Behavior
• Create New Form
• Customize Existing Form
• Associate Forms with Roles and Actions

New one is shortened to:

• Customize Form Layout
• Customize Form Behavior
• Generate Web-to-Record Form

If you had custom forms defined for a table you can still have access to them; the link to old functionality is moved under Rules section > Custom Forms link.

* If you have single custom form for all roles and actions, view the form and click "Copy to Default Form" button. This will copy all the columns, sections and text blocks to a new layout's Default Form. Then change form associations to set Default Form for roles and actions you want to enable new functionality to. If you are satisfied with results, change the association for remaining roles and actions.

* If you have multiple custom forms associated with various roles and actions start with the form most suitable for migration (containing most of the columns for example). Then adjust the columns' visibility as necessary via form behaviors:

1. To differentiate between Add and Edit mode you can use
   RecordId()='0' behavior's filter condition.
2. To differentiate between roles you can simply address the role name enclosed in square brackets in the filter, for example [My Role].

The Preview button found under Customize Form Layout can help you to play with behaviors and roles without actually deploying the form.

* Web-To-Record (W2R) functionality is also slightly affected. While old W2R forms exist, they will work unchanged. Yet if you decide to migrate completely, please note that there will be a single W2R gateway URL per table.

Enable all the columns from all of your W2R forms. Save. Capture <form>'s action URL from generated HTML code and use updated URL on your site forms.

* Once you complete the migration you can delete all of your custom forms to hide Rules > Custom Forms item.

* Few months ago we started experimenting with new form layout. The development is finished now and new layout is enabled in new applications by default. This post describes design decisions we've made during the development and the outcome. We'll describe the migration plan for existing customers in the next post.

* In TeamDesk we call database tables record properties' columns. Some databases call it fields. Here we'll speak mostly about HTML layouts that consist of rows and columns. To avoid mixing up definitions we'll refer to the content of HTML tables as rows and columns and to TeamDesk database columns as fields.

Traditionally TeamDesk used tables for forms. When we started developing the product in 2005 this was perhaps the only truly cross-browser way for making multi-column layouts.

Many things changed since then. Many web standards reached recommendation stage. Browser vendors switching to rapid development to support latest web specifications. Smartphones and tablets arose. We've added many nice features such as dynamic recalculations and form behaviors to TeamDesk.

In tables intersections of rows and columns form cells. In TeamDesk each field were occupying two cells: one for column label and another, next to the label, to display the value or provide an editor. The browser is responsible for the table layout, determining optimal size for each row and column, but the browser will never break a row if its content exceeds the screen width. This is good for tabular data, but in case of forms it is a big problem to render the layout for devices with narrow screens.

Suppose, you have the form laid out in four columns (two fields in a row, each field occupies two columns). Suppose we have long labels and wide-enough content, so each column does not exceed 320px.

This is what we had:

While, in theory, narrow screen can be detected and four columns could be broken in four rows (label above the value below, field after field), the browser will never do that:

This was the first problem to solve. Another was also caused by table layout. See, what's wrong here?

Field 1 was hidden by either column access right or by form behavior. But, despite what you may expect Field 2 is not shifted to the left (or Field 3 is not shifted up.) In table layout hiding the cell is identical to hiding its content, the space occupied by the cell is not "freed."

In addition to changed web landscape we had a number of various layout improvement ideas from our customers. So we decided to take on new form layout.

First of all, widely used browsers have decent support for latest cascading style sheet standard. From this standard, two things were of our interest: CSS floats to allow grid-like layout without sticking to tables; and CSS media queries to provide additional layout hints for smartphones and tablet devices. So we ended up with the following rules:

1. The form is divided into four equally sized virtual "columns";
2. The width is always expressed in number of columns;
3. The field can occupy one to four virtual columns (Width1 - Width4). You can instruct the field to occupy new row (hard break), or to be displayed next to preceding field. If the total width of the fields in a row exceeds 4, the field exceeding the width will be displayed in a new row (soft break);
4. You can provide alternative label to a field;
5. You can specify whether to display the label to the left of the value or above it;
6. The field contained in the section. If there is no section defined explicitly we define unnamed one;
7. The width of the section is defined by the sum of fields' widths in  row but does not exceed 4;
8. Sections are laid out the same way as columns.
9. You can apply behaviors to every form item including sections and text blocks.

Perhaps these rules need some explanations:

Why 4 columns? Customers asked us to have a possibility to define 3 fields in a row. Yet, 4 columns give more options to have a form look like  a grid: you can define 1x4 or 2x2 or 4x1, plus combinations of 3+1, 1+3, 2+1+1 1+2+1, 1+1+2. Below is an example of the form from Leads Management application laid out with new features:

Default layout is optimized to work well on a 1280px screen which we believe is a standard for most desktops and does not depend on browser's standard support level. With sidebar hidden, it should work as well on a 1024px screen which is a standard for netbooks and tablet devices in a landscape mode.

For narrower screens we'll provide additional layout hints. For example we can force the layout in two columns or always display label above to free more space to display the value. Yet, this is still the work in progress.

Hard and soft breaks start playing when fields and sections are dynamically shown and hidden. Hard breaks are always respected. Soft breaks are not: when you hide preceding field next field is shifted to the left. If there is enough of free space in a row we'll try to fit the field from the next row. Preview button will give you an idea how the form will look like with various combinations of View/Edit modes, roles and behavior rules in effect.

Displaying the label above makes sense when you have either narrow section (Width1) to make more room for content or wide content by definition such as multiline text. We tried to experiment with some automated decisions, yet finally decided for default layout to leave it up to user's consent.

But hey, tables are not gone! Some e-mail clients have limited HTML rendering capabilities, so in e-mail notifications we are still using tables to make sure our layout can be read correctly.

Previously, you needed to type some text into the type-in picker and move input focus out of control to have your search query resolved to particular record. Yet, there were no clear indication if there is no records matching your query or there is multiple records; TeamDesk leaves your text unchanged and error message appears only when you click Save button.

With latest release we have added auto completion functionality to type-in pickers. Starting from second letter you've typed TeamDesk sends your text to the application and gets back the list of top 20 matched records.

These records are displayed in the dropdown under input box allowing you to choose one. Search logic was modified to implicitly add a star (*) wildcard to the end of your query.