Call Us Today! +1 (866) 331-1354|sales@docova.com

Migrate Notes to DOCOVA Blog Series Part 13: Shared columns and fields

Welcome to blog series part 13 of 17 on migrating Notes apps to DOCOVA.  This entry is dedicated to shared columns and fields.  It’s short and sweet.

DOCOVA does not support the concept of shared columns and fields between applications at this time.

Say what?  I know, right?  DOCOVA is so over the top, so chalk full of functionality…it’s crazy, alas at the time of writing this blog entry, it doesn’t support shared columns and fields.  Well, that’s the reason right there…we’ve been busy with the other stuff.  “It’s on the list”.  “It’s coming”.  For our “library” templates, we actually do have view column definitions that are shared across any library as well as custom search fields that can be defined and used across libraries and applications when using DOCOVA’s advanced searching features.  The problem right now is that we have a few ideas around how we’d like to implement this functionality, and it may be different than how we are currently doing it, or not.  So, stay tuned.

For now, when Notes app views are imported via the DOCOVA App Importer, if they are using a shared column, then the column is treated as though it is specifically part of the view in that app.

When a form or subform is imported, shared fields that may have been used are treated as if they were specific to the form or subform.

Comments?

You can fast-track and get all the whitepapers on our migration methodology and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology – MIGRATE whitepaper

By |May 11th, 2017|Notes Migration, Technical|Comments Off on Migrate Notes to DOCOVA Blog Series Part 13: Shared columns and fields

Migrate Notes to DOCOVA Blog Series Part 12: Multi-value fields

Welcome to blog series part 12 of 17 on migrating Notes apps to DOCOVA.  In this entry it’s all about multi-value fields.

Notes had the concept of multi-value fields on forms.  All fields were basically treated as arrays of values.  For example when addressing field values in LotusScript, you might write some code like;

Dim myval = doc.myfield(0)  (where doc is a NotesDocument)

Although it’s a bit of an odd duck, DOCOVA supports the same type of addressing when it comes to form fields.  It’s easier to migrate the code over and easy for Notes developers to quickly understand and use. Thus something like doc.myfield(0) is translated into doc.getfield(“myfield”)[0] in JavaScript.

Or, for a list of fields;
Var myfields = doc.getFields(myfieldlist) and get the field with myfields.myfieldname[0]

One additional important note as it relates to multi-value fields is that if a multi-value field is used in a view column, DOCOVA “views” support the “Show multiple values as separate entries” option.  From a techy point of view, in a relational database environment, I should be able to hear people saying “wow” right about now.

Comment below!

You can fast-track and get all the whitepapers on our migration methodology and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology – MIGRATE whitepaper

 

By |May 9th, 2017|Notes Migration, Technical|Comments Off on Migrate Notes to DOCOVA Blog Series Part 12: Multi-value fields

Migrate Notes to DOCOVA Blog Series Part 11: Pass-thru HTML and Generate HTML for all fields

Welcome to blog series part 11 of 17 on migrating Notes apps to DOCOVA. In this entry I’m going to talk about “Pass-thru HTML and Generate HTML for all fields”.

A neat aspect of forms development in Notes was the ability to treat text on a form as pass-thru HTML.  This meant that you could add HTML and inline JavaScript directly onto your forms and mark it as pass-thru so that the Domino server would let the text “pass-thru” as HTML/JavaScript when the form was being rendered via a browser.

DOCOVA’s App Builder allows developers to achieve the same thing so that they can put HTML and inline JavaScript directly onto a form/subform.  Aside from a typical “block” of HTML, DOCOVA allows the developer to surround other elements, like Computed Text as an example.  Hence something like ComputedText can be leveraged in the pass-thru HTML or JavaScript.  For example, a developer can hide or show content based on an @formula placed in Computed Text in the style of an HTML element.

This functionality opens up a huge variety of permutation around mixing HTML/JavaScript and elemental constructs.

When importing Notes applications into DOCOVA, text marked as pass-thru HTML/JavaScript is treated in a similar fashion and supported in DOCOVA.

On Notes forms, when rendered in a browser, if a field was computed, computed for display or computed when composed, there was no “id” or “name” attributes assigned to those fields, meaning, there was no way to address those fields.  So, turn on “Generate HTML for all fields” and voila, now you had a way to address these fields.

Since DOCOVA supports computed, computed for display and computed when composed fields, we felt it was fitting for DOCOVA to always auto-generate the relevant HTML for those types of fields so that they are always accessible in the browser for whatever your functionality needs are.

Comment below.

You can fast-track and get all the whitepapers on our migration methodology and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology – MIGRATE whitepaper

By |May 4th, 2017|Notes Migration, Technical|Comments Off on Migrate Notes to DOCOVA Blog Series Part 11: Pass-thru HTML and Generate HTML for all fields