Congratulations!

[Valid RSS] This is a valid RSS feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

Source: http://feeds.feedburner.com/DocovaTechincalBlog

  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/rss2full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?><rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0" version="2.0">
  3.  
  4. <channel>
  5. <title>Technical – DOCOVA.com</title>
  6. <link>http://www.docova.com</link>
  7. <description>DOCOVA.com Website</description>
  8. <lastBuildDate>Thu, 27 Jul 2017 15:26:56 +0000</lastBuildDate>
  9. <language>en-US</language>
  10. <sy:updatePeriod>hourly</sy:updatePeriod>
  11. <sy:updateFrequency>1</sy:updateFrequency>
  12. <generator>https://wordpress.org/?v=4.7.5</generator>
  13. <atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="self" type="application/rss+xml" href="http://feeds.feedburner.com/DocovaTechincalBlog" /><feedburner:info uri="docovatechincalblog" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="hub" href="http://pubsubhubbub.appspot.com/" /><feedburner:browserFriendly></feedburner:browserFriendly><item>
  14. <title>Why we DO migrate code.</title>
  15. <link>http://www.docova.com/why-we-do-migrate-code/</link>
  16. <comments>http://www.docova.com/why-we-do-migrate-code/#comments</comments>
  17. <pubDate>Tue, 27 Jun 2017 13:28:54 +0000</pubDate>
  18. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  19. <category><![CDATA[Notes Migration]]></category>
  20. <category><![CDATA[Technical]]></category>
  21.  
  22. <guid isPermaLink="false">http://www.docova.com/?p=5931</guid>
  23. <description><![CDATA[I decided to write a blog entry on the issue of migrating Notes application code when migrating Notes applications to DOCOVA.  When I say &#8220;code&#8221;, I mean the LotusScript and @formula language that is contained in Notes applications. Now, I&#8217;ve seen some blogs and vendor web pages that espouse how you should NOT attempt to migrate the code.  These vendors typically want to convince you that you should re-develop your Notes applications on their platforms.  I get it.  That represents a lot in terms of billable services.  The bottom line, really, is that they simply lack the tools capable of migrating the code, so they try to convince you that you shouldn&#8217;t do it. Part of the DOCOVA Migration Methodology includes the task of migrating Notes applications, including the code, to the DOCOVA platform.  Developing the tools to convert LotusScript and @formula language to other languages like JavaScript and PHP is not easy.  But, we&#8217;ve done the work. In our research of business partners and organizations that still consult in or have Lotus Notes and Domino environments, we&#8217;ve found that they are looking for viable platforms to move their Notes applications to.  In companies that are still using Notes and Domino, the overwhelming consensus is that THE number one activity they DO NOT want to engage in is process re-engineering their Notes applications.  They want an efficient, cost effective way to convert their Notes applications to a new platform with as little interruption to their business as possible.  Once migrated, they want to be able to continue enhancing these applications while building new ones when they can properly plan the time, cost and resources to do so. We have found that across the board, the [&#8230;]]]></description>
  24. <content:encoded><![CDATA[<p>I decided to write a blog entry on the issue of migrating Notes application code when migrating Notes applications to DOCOVA.  When I say &#8220;code&#8221;, I mean the LotusScript and @formula language that is contained in Notes applications.</p>
  25. <p>Now, I&#8217;ve seen some blogs and vendor web pages that espouse how you should NOT attempt to migrate the code.  These vendors typically want to convince you that you should re-develop your Notes applications on their platforms.  I get it.  That represents a lot in terms of billable services.  The bottom line, really, is that <strong>they simply lack the tools capable of migrating the code</strong>, so they try to convince you that you shouldn&#8217;t do it.</p>
  26. <p>Part of the <strong><a href="http://www.docova.com/migrationmethodology/" target="_blank" rel="noopener noreferrer">DOCOVA Migration Methodology</a></strong> includes the task of migrating Notes applications, including the code, to the DOCOVA platform.  Developing the tools to convert LotusScript and @formula language to other languages like JavaScript and PHP is not easy.  But,<strong> we&#8217;ve done the work</strong>.</p>
  27. <p>In our research of business partners and organizations that still consult in or have Lotus Notes and Domino environments, we&#8217;ve found that they are looking for viable platforms to move their Notes applications to.  In companies that are still using Notes and Domino, the <strong>overwhelming consensus</strong> is that THE number one activity <strong>they DO NOT want to engage in is process re-engineering their Notes applications</strong>.  They want an efficient, cost effective way to convert their Notes applications to a new platform with as little interruption to their business as possible.  Once migrated, they want to be able to continue enhancing these applications while building new ones when they can properly plan the time, cost and resources to do so.</p>
  28. <p>We have found that across the board, the vast majority of companies still on Notes and Domino have staff with skills that encompass the most popular browser application development languages in use today, that being JavaScript, Java, PHP and Python.  They all need their applications to be browser based and cross-device.  Also, the majority of these organizations already have and use Microsoft SQL Server, MySQL, Oracle or PostgreSQL as database management solutions somewhere in their organization.  <strong>This market reality is exactly what we have catered to in developing DOCOVA.</strong></p>
  29. <p>The companies we talk to often have hundreds or sometimes into the thousands of Notes applications that they need to migrate.  To sit down with staff, dig through, revisit, re-engineer and re-develop these applications is a nightmare in terms of time and money.  The VPs, CIOs and Directors of these organizations understand that fact.</p>
  30. <p>The vendors that don&#8217;t have code conversion solutions will argue that you can&#8217;t convert &#8220;old&#8221; LotusScript code to a new modern development language, like JavaScript or PHP, because you&#8217;d miss out on &#8220;new capabilities&#8221;, syntax and patterns.  Well two things.  First off, I agree, and of course this is why when LotusScript and @formula code is converted from your Notes application to DOCOVA, it is <strong>transformed into DOCOVA&#8217;s modern JavaScript/PHP object oriented API</strong> which leverages modern language constructs.  Secondly,  the last time I looked, LotusScript declared variables, used functions, conditional statements, looping constructs and class structures.  This hasn&#8217;t gone away in any language&#8230;and yes, DOCOVA converts all of this.  Moving forward, DOCOVA&#8217;s development environment is flexible enough to allow developers to implement whatever &#8220;modern&#8221; programming approaches they deem fit to leverage for their applications.</p>
  31. <p>Vendors will also argue that companies shouldn&#8217;t try to convert their old, tired, bug-ridden applications to a new platform.  I kind of resent these pejorative assumptions. Although the Notes client interface for applications is dated, most of our customers take the workflow and business logic, &#8220;the code&#8221; of their Notes applications very seriously.  They use their applications on a daily basis to run their businesses.  To treat them as if they were &#8220;throw-away&#8221; is misguided.  That said though, it is true that sometimes, for some applications, companies would rather re-develop them.  This too is perfect for DOCOVA as it offers a comprehensive drag and drop, WYSIWYM (what-you-see-is-what-you-mean) browser integrated application design environment for building applications super fast.</p>
  32. <p><strong>With DOCOVA and our migration methodology, it’s NOT about keeping the old stuff old.</strong>  The import is about modernizing your legacy Notes apps into a new modern platform in an automated fashion.  Notes UI elements are transformed into new modern browser based UI elements and LotusScript and @formula language are converted to JavaScript/PHP and DOCOVA’s modern object oriented API.</p>
  33. <p>So yes, if you&#8217;re looking to move off of Notes and Domino and are wondering what to do with your applications, we of course encourage you to seek out and review all of the Notes and Domino &#8220;migration&#8221; solutions you can find.  Then come and see DOCOVA.  Using this approach will help you truly appreciate what it has to offer!</p>
  34. <p>Let us give you a demonstration.  Our experience in Notes application migrations will quickly become evident and you will gain an understanding as to why we boast the most complete end-to-end migration solution for your Notes applications.</p>
  35. ]]></content:encoded>
  36. <wfw:commentRss>http://www.docova.com/why-we-do-migrate-code/feed/</wfw:commentRss>
  37. <slash:comments>2</slash:comments>
  38. </item>
  39. <item>
  40. <title>Migrate Notes to DOCOVA Blog Series Part 17: Input translation and input validation formulas</title>
  41. <link>http://www.docova.com/migrate-notes-to-docova-blog-series-part-17-input-translation-and-input-validation-formulas/</link>
  42. <pubDate>Thu, 25 May 2017 12:51:27 +0000</pubDate>
  43. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  44. <category><![CDATA[Notes Migration]]></category>
  45. <category><![CDATA[Technical]]></category>
  46.  
  47. <guid isPermaLink="false">http://www.docova.com/?p=5361</guid>
  48. <description><![CDATA[Welcome to blog series part 17 of 17 on migrating Notes apps to DOCOVA.  The subject of this blog is Input translation and input validation formulas (formulae if you prefer). Right.  So, one day I hear this argument coming from down the hall here at DOCOVA.  The dev team embroiled in some discussion.  Oh the controversy.  Fisticuffs? Naw.  Heated?  Maybe that would be a bit of a stretch.  The debate?  How should input translation and input validation formulas be handled in DOCOVA? In a Notes developer client, you can click on a field on a form and provide a formula for translating or validating values for that field. Should DOCOVA do it the same way?  On the one hand, from a migration point of view, it&#8217;s one to one, it&#8217;s easier to migrate the formulae over to DOCOVA associated with the fields on the forms.  The way Notes did it, it was convenient and pretty easy to find, add, edit, what have you. On the other hand, it&#8217;s a bit disjointed especially on the validation side of things.  The save/submit process stops for each problem encountered rather than summarize the issues and present them to the user so that the user can fix them all and save again. So, the question becomes, should DOCOVA implement these formulae the way Notes did? Well, as of the writing of this blog post I can say, when it comes to input translation formulas, we went ahead and added the option to fields in the App Builder.  Kinda makes sense for that. However, for input validation, again as at the time of my writing this blog, remains outstanding.  I will come back and update this later but for now, [&#8230;]]]></description>
  49. <content:encoded><![CDATA[<p>Welcome to blog series part 17 of 17 on migrating Notes apps to DOCOVA.  The subject of this blog is Input translation and input validation formulas (formulae if you prefer).</p>
  50. <p>Right.  So, one day I hear this argument coming from down the hall here at DOCOVA.  The dev team embroiled in some discussion.  Oh the controversy.  Fisticuffs? Naw.  Heated?  Maybe that would be a bit of a stretch.  The debate?  How should input translation and input validation formulas be handled in DOCOVA?</p>
  51. <p>In a Notes developer client, you can click on a field on a form and provide a formula for translating or validating values for that field.</p>
  52. <p>Should DOCOVA do it the same way?  On the one hand, from a migration point of view, it&#8217;s one to one, it&#8217;s easier to migrate the formulae over to DOCOVA associated with the fields on the forms.  The way Notes did it, it was convenient and pretty easy to find, add, edit, what have you.</p>
  53. <p>On the other hand, it&#8217;s a bit disjointed especially on the validation side of things.  The save/submit process stops for each problem encountered rather than summarize the issues and present them to the user so that the user can fix them all and save again.</p>
  54. <p>So, the question becomes, should DOCOVA implement these formulae the way Notes did?</p>
  55. <p>Well, as of the writing of this blog post I can say, when it comes to input translation formulas, we went ahead and added the option to fields in the App Builder.  Kinda makes sense for that.</p>
  56. <p>However, for input validation, again as at the time of my writing this blog, remains outstanding.  I will come back and update this later but for now, there are two trains of thought.  First, just bring the formulas over and have them the same way as Notes does, as an attribute of a field.  With this approach, migration is easier and the simplicity of it remains.  Alternatively, when importing a form, we gather up all validation formulas and combine them into one function that gets executed on submit.  This approach would lend itself to being more easily converted into something it should be. Stay tuned.  The bottom line though, is that input validation formulas can easily be converted over to DOCOVA and implemented with a field or in your own .js, we&#8217;re  just looking to make it a bit more automated.</p>
  57. <p>Comments?</p>
  58. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology &#8211; MIGRATE whitepaper.</p>
  59. ]]></content:encoded>
  60. </item>
  61. <item>
  62. <title>Migrate Notes to DOCOVA Blog Series Part 16: Form events</title>
  63. <link>http://www.docova.com/migrate-notes-to-docova-blog-series-part-16-form-events/</link>
  64. <pubDate>Tue, 23 May 2017 12:24:52 +0000</pubDate>
  65. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  66. <category><![CDATA[Notes Migration]]></category>
  67. <category><![CDATA[Technical]]></category>
  68.  
  69. <guid isPermaLink="false">http://www.docova.com/?p=5359</guid>
  70. <description><![CDATA[Welcome to blog series part 16 of 17 on migrating Notes apps to DOCOVA.  In this entry I&#8217;m going to talk about form events. Okay, so the talk about form events usually starts of with the question: Does DOCOVA have document events like onLoad, onUnload, QueryOpen, QuerySave and WebQueryOpen? Yes.  DOCOVA supports both typical browser events like onLoad and onUnload but has also been extended to handle similar events that were found in Notes forms like QueryOpen, QuerySave, PostSave and so forth.  Many Notes applications made heavy use of these events, we couldn&#8217;t just leave them out now, could we? DOCOVA implements these events in a similar fashion because they are useful and it makes migrating Notes application to DOCOVA much easier.  I mean, could you imagine having to try to implement these events in some other target collaboration platform aside from DOCOVA?  Good luck with that. 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 &#8211; MIGRATE whitepaper]]></description>
  71. <content:encoded><![CDATA[<p>Welcome to blog series part 16 of 17 on migrating Notes apps to DOCOVA.  In this entry I&#8217;m going to talk about form events.</p>
  72. <p>Okay, so the talk about form events usually starts of with the question:</p>
  73. <p><strong>Does DOCOVA have document events like onLoad, onUnload, QueryOpen, QuerySave and WebQueryOpen?</strong></p>
  74. <p>Yes.  DOCOVA supports both typical browser events like onLoad and onUnload but has also been extended to handle similar events that were found in Notes forms like QueryOpen, QuerySave, PostSave and so forth.  Many Notes applications made heavy use of these events, we couldn&#8217;t just leave them out now, could we?</p>
  75. <p>DOCOVA implements these events in a similar fashion because they are useful and it makes migrating Notes application to DOCOVA much easier.  I mean, could you imagine having to try to implement these events in some other target collaboration platform aside from DOCOVA?  Good luck with that.</p>
  76. <p>Comment below.</p>
  77. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology &#8211; MIGRATE whitepaper</p>
  78. ]]></content:encoded>
  79. </item>
  80. <item>
  81. <title>Migrate Notes to DOCOVA Blog Series Part 15: Private on first use folders</title>
  82. <link>http://www.docova.com/migrate-notes-to-docova-blog-series-part-15-private-on-first-use-folders/</link>
  83. <pubDate>Thu, 18 May 2017 12:38:43 +0000</pubDate>
  84. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  85. <category><![CDATA[Notes Migration]]></category>
  86. <category><![CDATA[Technical]]></category>
  87.  
  88. <guid isPermaLink="false">http://www.docova.com/?p=5357</guid>
  89. <description><![CDATA[Welcome to blog series part 15 of 17 on migrating Notes apps to DOCOVA..  In this entry I&#8217;m going to talk about good &#8216;ol Private on first use folders. This is another one of those &#8220;interesting&#8221; Notes application design constructs.  In my journeys I don&#8217;t think I&#8217;ve ever come across this same sort of construct in any other application environment.  Anywhere.  Ever.  Sure, a private folder, but &#8220;&#8230;on first use&#8221; is the kicker.  Interestingly, this construct can be implemented with some creativity behind it. DOCOVA supports “Private on first use folders”, depicted as “Content personal to each user”.  So, when a person accesses a “view” as a folder, it will be treated as though this folder is private to the user. This is most useful when selecting documents manually.  One way that Notes applications leveraged this design construct in the past was that sometimes a search was performed to gather documents together and then present them to the specific User doing the search via this folder type. There you go.  Supported. 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 &#8211; MIGRATE whitepaper]]></description>
  90. <content:encoded><![CDATA[<p>Welcome to blog series part 15 of 17 on migrating Notes apps to DOCOVA..  In this entry I&#8217;m going to talk about good &#8216;ol Private on first use folders.</p>
  91. <p>This is another one of those &#8220;interesting&#8221; Notes application design constructs.  In my journeys I don&#8217;t think I&#8217;ve ever come across this same sort of construct in any other application environment.  Anywhere.  Ever.  Sure, a private folder, but &#8220;&#8230;on first use&#8221; is the kicker.  Interestingly, this construct can be implemented with some creativity behind it.</p>
  92. <p>DOCOVA supports “Private on first use folders”, depicted as “Content personal to each user”.  So, when a person accesses a “view” as a folder, it will be treated as though this folder is private to the user.</p>
  93. <p>This is most useful when selecting documents manually.  One way that Notes applications leveraged this design construct in the past was that sometimes a search was performed to gather documents together and then present them to the specific User doing the search via this folder type.</p>
  94. <p>There you go.  Supported.</p>
  95. <p>Comment below.</p>
  96. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology &#8211; MIGRATE whitepaper</p>
  97. ]]></content:encoded>
  98. </item>
  99. <item>
  100. <title>Migrate Notes to DOCOVA Blog Series Part 14: Column sorting and categorizing</title>
  101. <link>http://www.docova.com/migrate-notes-to-docova-blog-series-part-14-column-sorting-and-categorizing/</link>
  102. <pubDate>Tue, 16 May 2017 12:18:04 +0000</pubDate>
  103. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  104. <category><![CDATA[Notes Migration]]></category>
  105. <category><![CDATA[Technical]]></category>
  106.  
  107. <guid isPermaLink="false">http://www.docova.com/?p=5355</guid>
  108. <description><![CDATA[Welcome to blog series part 14 of 17 on migrating Notes apps to DOCOVA..  In this entry I&#8217;m going to talk about view column sorting and categorizing. All view sorting and categorizing functionality is supported in DOCOVA.  Additionally, other properties like “Show multiple values as separate entries” and showing response docs in a hierarchy are also supported. I mean, as you get more in depth with DOCOVA, you&#8217;ll learn the breadth of the view object model and all the cool stuff you can do, even switching to Calendar and Gantt style views. So ya, what can I tell ya.  That&#8217;s it for now.  Supported!  Bam! 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 &#8211; MIGRATE whitepaper]]></description>
  109. <content:encoded><![CDATA[<p>Welcome to blog series part 14 of 17 on migrating Notes apps to DOCOVA..  In this entry I&#8217;m going to talk about view column sorting and categorizing.</p>
  110. <p>All view sorting and categorizing functionality is supported in DOCOVA.  Additionally, other properties like “Show multiple values as separate entries” and showing response docs in a hierarchy are also supported.</p>
  111. <p>I mean, as you get more in depth with DOCOVA, you&#8217;ll learn the breadth of the view object model and all the cool stuff you can do, even switching to Calendar and Gantt style views.</p>
  112. <p>So ya, what can I tell ya.  That&#8217;s it for now.  Supported!  Bam!</p>
  113. <p>Comment below!</p>
  114. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology &#8211; MIGRATE whitepaper</p>
  115. ]]></content:encoded>
  116. </item>
  117. <item>
  118. <title>Migrate Notes to DOCOVA Blog Series Part 13: Shared columns and fields</title>
  119. <link>http://www.docova.com/migrate-notes-to-docova-blog-series-part-13-shared-columns-and-fields/</link>
  120. <pubDate>Thu, 11 May 2017 12:52:29 +0000</pubDate>
  121. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  122. <category><![CDATA[Notes Migration]]></category>
  123. <category><![CDATA[Technical]]></category>
  124.  
  125. <guid isPermaLink="false">http://www.docova.com/?p=5353</guid>
  126. <description><![CDATA[Welcome to blog series part 13 of 17 on migrating Notes apps to DOCOVA.  This entry is dedicated to shared columns and fields.  It&#8217;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&#8230;it&#8217;s crazy, alas at the time of writing this blog entry, it doesn&#8217;t support shared columns and fields.  Well, that&#8217;s the reason right there&#8230;we&#8217;ve been busy with the other stuff.  &#8220;It&#8217;s on the list&#8221;.  &#8220;It&#8217;s coming&#8221;.  For our &#8220;library&#8221; 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&#8217;s advanced searching features.  The problem right now is that we have a few ideas around how we&#8217;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 &#8211; MIGRATE whitepaper]]></description>
  127. <content:encoded><![CDATA[<p>Welcome to blog series part 13 of 17 on migrating Notes apps to DOCOVA.  This entry is dedicated to shared columns and fields.  It&#8217;s short and sweet.</p>
  128. <p>DOCOVA does not support the concept of shared columns and fields between applications at this time.</p>
  129. <p>Say what?  I know, right?  DOCOVA is so over the top, so chalk full of functionality&#8230;it&#8217;s crazy, alas at the time of writing this blog entry, it doesn&#8217;t support shared columns and fields.  Well, that&#8217;s the reason right there&#8230;we&#8217;ve been busy with the other stuff.  &#8220;It&#8217;s on the list&#8221;.  &#8220;It&#8217;s coming&#8221;.  For our &#8220;library&#8221; 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&#8217;s advanced searching features.  The problem right now is that we have a few ideas around how we&#8217;d like to implement this functionality, and it may be different than how we are currently doing it, or not.  So, stay tuned.</p>
  130. <p>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.</p>
  131. <p>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.</p>
  132. <p>Comments?</p>
  133. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology &#8211; MIGRATE whitepaper</p>
  134. ]]></content:encoded>
  135. </item>
  136. <item>
  137. <title>Migrate Notes to DOCOVA Blog Series Part 12: Multi-value fields</title>
  138. <link>http://www.docova.com/migrate-notes-to-docova-blog-series-part-12-multi-value-fields/</link>
  139. <pubDate>Tue, 09 May 2017 12:01:37 +0000</pubDate>
  140. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  141. <category><![CDATA[Notes Migration]]></category>
  142. <category><![CDATA[Technical]]></category>
  143.  
  144. <guid isPermaLink="false">http://www.docova.com/?p=5351</guid>
  145. <description><![CDATA[Welcome to blog series part 12 of 17 on migrating Notes apps to DOCOVA.  In this entry it&#8217;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&#8217;s a bit of an odd duck, DOCOVA supports the same type of addressing when it comes to form fields.  It&#8217;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 &#8220;views&#8221; 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 &#8220;wow&#8221; 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 &#8211; MIGRATE whitepaper &#160;]]></description>
  146. <content:encoded><![CDATA[<p>Welcome to blog series part 12 of 17 on migrating Notes apps to DOCOVA.  In this entry it&#8217;s all about multi-value fields.</p>
  147. <p>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;</p>
  148. <p><span style="color: #339966;">Dim myval = doc.myfield(0)  (where doc is a NotesDocument)<br />
  149. </span></p>
  150. <p>Although it&#8217;s a bit of an odd duck, DOCOVA supports the same type of addressing when it comes to form fields.  It&#8217;s easier to migrate the code over and easy for Notes developers to quickly understand and use. Thus something like <span style="color: #339966;">doc.myfield(0)</span> is translated into <span style="color: #339966;">doc.getfield(“myfield”)[0]</span> in JavaScript.</p>
  151. <p>Or, for a list of fields;<br />
  152. <span style="color: #339966;">Var myfields = doc.getFields(myfieldlist) and get the field with myfields.myfieldname[0]</span></p>
  153. <p>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 &#8220;views&#8221; 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 &#8220;wow&#8221; right about now.</p>
  154. <p>Comment below!</p>
  155. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology &#8211; MIGRATE whitepaper</p>
  156. <p>&nbsp;</p>
  157. ]]></content:encoded>
  158. </item>
  159. <item>
  160. <title>Migrate Notes to DOCOVA Blog Series Part 11: Pass-thru HTML and Generate HTML for all fields</title>
  161. <link>http://www.docova.com/migrate-notes-to-docova-blog-series-part-11-pass-thru-html-and-generate-html-for-all-fields/</link>
  162. <pubDate>Thu, 04 May 2017 13:02:41 +0000</pubDate>
  163. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  164. <category><![CDATA[Notes Migration]]></category>
  165. <category><![CDATA[Technical]]></category>
  166.  
  167. <guid isPermaLink="false">http://www.docova.com/?p=5349</guid>
  168. <description><![CDATA[Welcome to blog series part 11 of 17 on migrating Notes apps to DOCOVA. In this entry I&#8217;m going to talk about &#8220;Pass-thru HTML and Generate HTML for all fields&#8221;. 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 &#8220;Generate HTML for all fields&#8221; 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 [&#8230;]]]></description>
  169. <content:encoded><![CDATA[<p>Welcome to blog series part 11 of 17 on migrating Notes apps to DOCOVA. In this entry I&#8217;m going to talk about &#8220;Pass-thru HTML and Generate HTML for all fields&#8221;.</p>
  170. <p>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.</p>
  171. <p>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.</p>
  172. <p>This functionality opens up a huge variety of permutation around mixing HTML/JavaScript and elemental constructs.</p>
  173. <p>When importing Notes applications into DOCOVA, text marked as pass-thru HTML/JavaScript is treated in a similar fashion and supported in DOCOVA.</p>
  174. <p>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 &#8220;Generate HTML for all fields&#8221; and voila, now you had a way to address these fields.</p>
  175. <p>Since DOCOVA supports computed, computed for display and computed when composed fields, we felt it was fitting for DOCOVA to <em>always</em> 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.</p>
  176. <p>Comment below.</p>
  177. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology &#8211; MIGRATE whitepaper</p>
  178. ]]></content:encoded>
  179. </item>
  180. <item>
  181. <title>Migrate Notes to DOCOVA Blog Series Part 10: Refresh fields on keyword change</title>
  182. <link>http://www.docova.com/migrate-notes-to-docova-blog-series-part-10-refresh-fields-on-keyword-change/</link>
  183. <pubDate>Tue, 02 May 2017 12:11:35 +0000</pubDate>
  184. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  185. <category><![CDATA[Notes Migration]]></category>
  186. <category><![CDATA[Technical]]></category>
  187.  
  188. <guid isPermaLink="false">http://www.docova.com/?p=5347</guid>
  189. <description><![CDATA[Welcome to blog series part 10 of 17 on migrating Notes apps to DOCOVA.  In this entry it&#8217;s all about &#8220;Refresh fields on keyword change&#8221;. Ya, let&#8217;s take a moment to just love this one.  Have you ever used it in your Notes apps?  Refresh fields on keyword change was a bit of an odd beast, no?  The purpose of this operation was to enable field options (or values) to be recalculated based on the change of a selection field. For example, if you had one keyword field on a form named [State] and another keyword field on your form named [City] when you open the form you could get all the States as options to choose from in the State field keyword field, however if the City field was based on what State was selected, then you need to have the City field recalculate what list of cities to show to the user. Notes forms accomplished this by using the “Refresh fields on keyword change” option.  Although maybe you could argue that it worked fine in a Notes client, in a browser, the page reload, aside from super inefficient, would cause the page/form to jump back to the top of the page as due to the refresh.  Traditionally, with JavaScript, you&#8217;d typically load up all possible options in some multi-dimensional array&#8230;fast&#8230;and not too complicated unless you needed to add a third or more selection fields to the mix. Ugh.  A better way is to use an AJAX or JSON call to retrieve the new options. In DOCOVA, keyword type fields like selection dropdown fields, checkboxes and radio buttons can all be hooked together in the App Builder so that they track each other and [&#8230;]]]></description>
  190. <content:encoded><![CDATA[<p>Welcome to blog series part 10 of 17 on migrating Notes apps to DOCOVA.  In this entry it&#8217;s all about &#8220;Refresh fields on keyword change&#8221;.</p>
  191. <p>Ya, let&#8217;s take a moment to just love this one.  Have you ever used it in your Notes apps?  Refresh fields on keyword change was a bit of an odd beast, no?  The purpose of this operation was to enable field options (or values) to be recalculated based on the change of a selection field.</p>
  192. <p>For example, if you had one keyword field on a form named [State] and another keyword field on your form named [City] when you open the form you could get all the States as options to choose from in the State field keyword field, however if the City field was based on what State was selected, then you need to have the City field recalculate what list of cities to show to the user.</p>
  193. <p>Notes forms accomplished this by using the “Refresh fields on keyword change” option.  Although maybe you could argue that it worked fine in a Notes client, in a browser, the page reload, aside from super inefficient, would cause the page/form to jump back to the top of the page as due to the refresh.  Traditionally, with JavaScript, you&#8217;d typically load up all possible options in some multi-dimensional array&#8230;fast&#8230;and not too complicated unless you needed to add a third or more selection fields to the mix. Ugh.  A better way is to use an AJAX or JSON call to retrieve the new options.</p>
  194. <p>In DOCOVA, keyword type fields like selection dropdown fields, checkboxes and radio buttons can all be hooked together in the App Builder so that they track each other and can independently get the options lists they need dynamically with no need for a “Refresh fields” option.  DOCOVA leverages AJAX to accomplish this but the real convenience is the ease with which a developer can hook up this common form control functionality.</p>
  195. <p>It&#8217;s a super convenient option in DOCOVA that I love.  Chime in with your &#8220;Refresh fields on keyword change&#8221; encounters in the comments below.</p>
  196. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology &#8211; MIGRATE whitepaper which goes over these technical aspects.</p>
  197. ]]></content:encoded>
  198. </item>
  199. <item>
  200. <title>Calendar View Integration in DOCOVA V5</title>
  201. <link>http://www.docova.com/calendar-view-integration-in-docova-v5/</link>
  202. <pubDate>Mon, 01 May 2017 21:50:03 +0000</pubDate>
  203. <dc:creator><![CDATA[David Wice]]></dc:creator>
  204. <category><![CDATA[Announcements]]></category>
  205. <category><![CDATA[Technical]]></category>
  206.  
  207. <guid isPermaLink="false">http://www.docova.com/?p=5897</guid>
  208. <description><![CDATA[You&#8217;ve built a new application for your client and they love it. You&#8217;re their hero. Two weeks later, they&#8217;re back with a list of enhancement questions and new ideas. This can happen regardless how many requirements gathering sessions you have. Once the system is in Production and all the users start accessing it, the requests start to come in. One of these requests may be &#8220;Can we see the data in a Calendar format?&#8221;. For those of us that have spent many years building Notes applications, this was a fairly simple request, just create a new view and set the view style to Calendar and add your fields. With DOCOVA, we wanted to make sure that it was a simple request in DOCOVA App Builder as well, and we&#8217;ve done it! Thanks to the jQuery platform and the FullCalendar open source plug-in (https://fullcalendar.io/), we have been able to provide a powerful calendar layout that is completely integrated with App Builder.  A Calendar view can be added as easily as adding a standard grid view. A configuration option toggles between the two layouts. When Calendar is selected, the available options are shown on the Calendar Settings tab From there, you just need to assign your date fields to applicable view columns This allows you to show the same data in a grid layout &#8230;and a calendar layout For more information on building applications in DOCOVA App Builder, visit http://www.docova.com/home-application-development/]]></description>
  209. <content:encoded><![CDATA[<p>You&#8217;ve built a new application for your client and they love it. You&#8217;re their hero. Two weeks later, they&#8217;re back with a list of enhancement questions and new ideas. This can happen regardless how many requirements gathering sessions you have. Once the system is in Production and all the users start accessing it, the requests start to come in.</p>
  210. <p>One of these requests may be &#8220;Can we see the data in a Calendar format?&#8221;. For those of us that have spent many years building Notes applications, this was a fairly simple request, just create a new view and set the view style to Calendar and add your fields. With DOCOVA, we wanted to make sure that it was a simple request in DOCOVA App Builder as well, and we&#8217;ve done it!</p>
  211. <p>Thanks to the jQuery platform and the FullCalendar open source plug-in (<a href="https://fullcalendar.io/" target="_blank" rel="noopener noreferrer">https://fullcalendar.io/</a>), we have been able to provide a powerful calendar layout that is completely integrated with App Builder.  A Calendar view can be added as easily as adding a standard grid view. A configuration option toggles between the two layouts.</p>
  212. <p><img class="alignnone size-full wp-image-5898" src="http://www.docova.com/wp-content/uploads/2017/05/Cal1.png" alt="" width="452" height="280" srcset="http://www.docova.com/wp-content/uploads/2017/05/Cal1.png 452w, http://www.docova.com/wp-content/uploads/2017/05/Cal1-300x186.png 300w" sizes="(max-width: 452px) 100vw, 452px" /></p>
  213. <p>When Calendar is selected, the available options are shown on the Calendar Settings tab<br />
  214. <img class="alignnone size-full wp-image-5899" src="http://www.docova.com/wp-content/uploads/2017/05/Cal2.png" alt="" width="658" height="189" srcset="http://www.docova.com/wp-content/uploads/2017/05/Cal2.png 658w, http://www.docova.com/wp-content/uploads/2017/05/Cal2-300x86.png 300w" sizes="(max-width: 658px) 100vw, 658px" /></p>
  215. <p>From there, you just need to assign your date fields to applicable view columns<br />
  216. <img class="alignnone size-full wp-image-5900" src="http://www.docova.com/wp-content/uploads/2017/05/Cal3.png" alt="" width="796" height="205" srcset="http://www.docova.com/wp-content/uploads/2017/05/Cal3.png 796w, http://www.docova.com/wp-content/uploads/2017/05/Cal3-300x77.png 300w, http://www.docova.com/wp-content/uploads/2017/05/Cal3-768x198.png 768w" sizes="(max-width: 796px) 100vw, 796px" /></p>
  217. <p>This allows you to show the same data in a grid layout<br />
  218. <img class="alignnone size-full wp-image-5901" src="http://www.docova.com/wp-content/uploads/2017/05/Cal4.png" alt="" width="535" height="86" srcset="http://www.docova.com/wp-content/uploads/2017/05/Cal4.png 535w, http://www.docova.com/wp-content/uploads/2017/05/Cal4-300x48.png 300w" sizes="(max-width: 535px) 100vw, 535px" /></p>
  219. <p>&#8230;and a calendar layout<br />
  220. <img class="alignnone size-large wp-image-5902" src="http://www.docova.com/wp-content/uploads/2017/05/Cal5-1024x564.png" alt="" width="1000" height="551" srcset="http://www.docova.com/wp-content/uploads/2017/05/Cal5-1024x564.png 1024w, http://www.docova.com/wp-content/uploads/2017/05/Cal5-300x165.png 300w, http://www.docova.com/wp-content/uploads/2017/05/Cal5-768x423.png 768w, http://www.docova.com/wp-content/uploads/2017/05/Cal5.png 1100w" sizes="(max-width: 1000px) 100vw, 1000px" /></p>
  221. <p>For more information on building applications in DOCOVA App Builder, visit <a href="http://www.docova.com/home-application-development/">http://www.docova.com/home-application-development/</a></p>
  222. ]]></content:encoded>
  223. </item>
  224. <item>
  225. <title>Migrate Notes to DOCOVA Blog Series Part 9: Response Documents</title>
  226. <link>http://www.docova.com/migrating-notes-to-docova-part-9-response-documents/</link>
  227. <comments>http://www.docova.com/migrating-notes-to-docova-part-9-response-documents/#comments</comments>
  228. <pubDate>Thu, 27 Apr 2017 09:00:24 +0000</pubDate>
  229. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  230. <category><![CDATA[Notes Migration]]></category>
  231. <category><![CDATA[Technical]]></category>
  232.  
  233. <guid isPermaLink="false">http://www.docova.com/?p=5345</guid>
  234. <description><![CDATA[Welcome to blog series part 9 of 17 on migrating Notes apps to DOCOVA..  In this entry I&#8217;m going to talk about how DOCOVA handles response or child documents. First let me take a second to praise response documents in IBM Notes.  You know, they seem like such a simple thing but I think it&#8217;s surprising how many systems don&#8217;t include this type of construct out of the box.  With their ability to inherit field info from their parent on creation and deep hierarchical depiction in views, they were great in my opinion.  Ya, sure, there were oddities here and there in views, but overall I think they were really useful and easy to implement. THAT SAID.  Yes, DOCOVA supports the design construct of response/child documents.  And, yes, column totals in a categorized view look correct in that the category total disappears when the category is expanded and shows up at the bottom as you&#8217;d expect.  Why they never got around to that, I&#8217;ll never know!  Also, in case you&#8217;re wondering about the obvious, yes, when creating response or child documents from a parent, you have the option to have fields automatically inherited from the parent onto the child just as Notes had done. I&#8217;m quite happy that we have this feature in DOCOVA, it&#8217;s really useful&#8230;and built right in. 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 &#8211; MIGRATE whitepaper which goes over these technical aspects. Comments below!  Ya&#8230;tell me how much you like response docs!]]></description>
  235. <content:encoded><![CDATA[<p>Welcome to blog series part 9 of 17 on migrating Notes apps to DOCOVA..  In this entry I&#8217;m going to talk about how DOCOVA handles response or child documents.</p>
  236. <p>First let me take a second to praise response documents in IBM Notes.  You know, they seem like such a simple thing but I think it&#8217;s surprising how many systems don&#8217;t include this type of construct out of the box.  With their ability to inherit field info from their parent on creation and deep hierarchical depiction in views, they were great in my opinion.  Ya, sure, there were oddities here and there in views, but overall I think they were really useful and easy to implement.</p>
  237. <p>THAT SAID.  Yes, DOCOVA supports the design construct of response/child documents.  And, yes, column totals in a categorized view look correct in that the category total disappears when the category is expanded and shows up at the bottom as you&#8217;d expect.  Why they never got around to that, I&#8217;ll never know!  Also, in case you&#8217;re wondering about the obvious, yes, when creating response or child documents from a parent, you have the option to have fields automatically inherited from the parent onto the child just as Notes had done.</p>
  238. <p>I&#8217;m quite happy that we have this feature in DOCOVA, it&#8217;s really useful&#8230;and built right in.</p>
  239. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology &#8211; MIGRATE whitepaper which goes over these technical aspects.</p>
  240. <p>Comments below!  Ya&#8230;tell me how much you like response docs!</p>
  241. ]]></content:encoded>
  242. <wfw:commentRss>http://www.docova.com/migrating-notes-to-docova-part-9-response-documents/feed/</wfw:commentRss>
  243. <slash:comments>2</slash:comments>
  244. </item>
  245. <item>
  246. <title>12 Apps in 18 Days – A Notes Migration Project</title>
  247. <link>http://www.docova.com/12-apps-in-18-days-a-notes-migration-project/</link>
  248. <pubDate>Wed, 26 Apr 2017 16:09:27 +0000</pubDate>
  249. <dc:creator><![CDATA[David Wice]]></dc:creator>
  250. <category><![CDATA[Notes Migration]]></category>
  251. <category><![CDATA[Technical]]></category>
  252.  
  253. <guid isPermaLink="false">http://www.docova.com/?p=5853</guid>
  254. <description><![CDATA[Jamesway Incubator, located in Cambridge Ontario, manufactures and sells incubators worldwide.   For years they have used IBM Notes and Domino collaboration products to automate business processes and share information with a staff located all over the world.  However, like many in the Notes and Domino community, a corporate decision was recently made to switch to Microsoft based technologies. Replacing Notes based email is relatively easy, since the migration tools and processes are well defined.  Migrating Notes based applications is much more difficult.  Fortunately, Jamesway implemented DOCOVA as a document management system almost a decade ago to manage corporate documents, and the new version of DOCOVA (V5), has been specifically designed to migrate Notes based applications to SQL. DOCOVA V5 understands the design elements that were unique to Notes, and knows how to handle them when moving to SQL based technologies. Jamesway contracted DLI to perform the Notes application migration.  DOCOVA App Importer did the heavy lifting by automatically migrating the application design from Lotus Domino to DOCOVA, leaving the developer free to adjust and tweak the migrated applications. Without App Importer to take care of the grunt work it would have taken 6 months instead of 3 weeks to transform these applications. The DOCOVA migration methodology (Analyze, Plan, Migrate, Manage) has guided this project.  The initial analysis provided us with key information so that we could provide a quote for the migration and identify resource requirements. In discussions with Jamesway, the migration plan was developed, which in this case was to migrate off the Notes client first, keeping the Domino backend, then move the migrated applications and existing Document Management system to the DOCOVA SQL platform.   Since the DOCOVA UI is the same regardless of the [&#8230;]]]></description>
  255. <content:encoded><![CDATA[<p><strong><a href="http:///www.jamesway.com" target="_blank" rel="noopener noreferrer">Jamesway Incubator</a></strong>, located in Cambridge Ontario, manufactures and sells incubators worldwide.   For years they have used IBM Notes and Domino collaboration products to automate business processes and share information with a staff located all over the world.  However, like many in the Notes and Domino community, a corporate decision was recently made to switch to Microsoft based technologies.</p>
  256. <p>Replacing Notes based email is relatively easy, since the migration tools and processes are well defined.  Migrating Notes based applications is much more difficult.  Fortunately, Jamesway implemented <strong><a href="http://www.docova.com/is-docova-right-for-you/" target="_blank" rel="noopener noreferrer">DOCOVA</a></strong> as a document management system almost a decade ago to manage corporate documents, and the new version of <strong><a href="https://youtu.be/Bsm4t02k7ZI" target="_blank" rel="noopener noreferrer">DOCOVA (V5)</a></strong>, has been specifically designed to migrate Notes based applications to SQL. <strong><a href="https://youtu.be/Bsm4t02k7ZI" target="_blank" rel="noopener noreferrer">DOCOVA V5</a></strong> understands the design elements that were unique to Notes, and knows how to handle them when moving to SQL based technologies.</p>
  257. <p>Jamesway contracted DLI to perform the Notes application migration.  DOCOVA App Importer did the heavy lifting by automatically migrating the application design from Lotus Domino to DOCOVA, leaving the developer free to adjust and tweak the migrated applications. Without App Importer to take care of the grunt work it would have taken 6 months instead of 3 weeks to transform these applications.</p>
  258. <p><strong><a href="http://www.docova.com/migrationmethodology/" target="_blank" rel="noopener noreferrer">The DOCOVA migration methodology </a></strong>(Analyze, Plan, Migrate, Manage) has guided this project.  The initial analysis provided us with key information so that we could provide a quote for the migration and identify resource requirements. In discussions with Jamesway, the migration plan was developed, which in this case was to migrate off the Notes client first, keeping the Domino backend, then move the migrated applications and existing Document Management system to the DOCOVA SQL platform.   Since the DOCOVA UI is the same regardless of the backend platform, Jamesway could spread the migration out over time to be better able to handle the resource requirements on their end.</p>
  259. <p>The applications migrated included maintenance management, requisition systems (purchase order, cheque, etc), as well as reference/document repository applications.  Utilizing App Importer, the developer doing the migration didn&#8217;t need to know what the application did or the business logic behind it, as it was all migrated intact.</p>
  260. <p><img class="alignnone size-large wp-image-5856" src="http://www.docova.com/wp-content/uploads/2017/04/JWWorkspace-1024x563.png" alt="" width="1000" height="550" srcset="http://www.docova.com/wp-content/uploads/2017/04/JWWorkspace-1024x563.png 1024w, http://www.docova.com/wp-content/uploads/2017/04/JWWorkspace-300x165.png 300w, http://www.docova.com/wp-content/uploads/2017/04/JWWorkspace-768x422.png 768w, http://www.docova.com/wp-content/uploads/2017/04/JWWorkspace.png 1103w" sizes="(max-width: 1000px) 100vw, 1000px" /></p>
  261. <p>All aspects of the design were migrated (Layouts, Pages, Views, Calendar Views, Forms, Subforms, Agents, Script Libraries, Images, Folders) as well as the data, including profile documents.  What about security? Yes, that was migrated too, including document level security (authors/readers/controlled access sections). As for the LotusScript, that was automatically translated to Javascript.</p>
  262. <p>Being an early release of DOCOVA V5 there were hurdles to be crossed and issues to be addressed. In some cases application logic just doesn&#8217;t flow the same way in a browser as it does in a local Notes client (eg. dialogs, prompt boxes, etc), requiring some adjustments/tweaking by the developer post migration. Luckily the DOCOVA Application Analysis process flags these cases for us.  We are also constantly improving App Importer to address new scenarios, which means that if we were to repeat the project with the current version of <strong><a href="https://youtu.be/Bsm4t02k7ZI" target="_blank" rel="noopener noreferrer">DOCOVA V5</a></strong>, it could be completed in even less time.</p>
  263. <p>The Jamesway project has now moved into UAT. After we showed IT management the migrated applications and they saw how the business logic and UI have been maintained, they were quite comfortable taking on the UAT step, since there is little to no training required. Users just need to be shown how to access the new platform and add their applications to the workspace.</p>
  264. <p>While we still have some work to do to complete the <strong><a href="http://www.docova.com/migrationmethodology/" target="_blank" rel="noopener noreferrer">migration to the SQL platform</a></strong>, we&#8217;ve been able to take what could have been a very costly re-development project and deliver results in a short period of time, at a reasonable cost.</p>
  265. ]]></content:encoded>
  266. </item>
  267. <item>
  268. <title>Migrate Notes to DOCOVA Blog Series Part 8: Profile Docs</title>
  269. <link>http://www.docova.com/migrate-notes-to-docova-blog-series-part-8-profile-docs/</link>
  270. <pubDate>Wed, 26 Apr 2017 12:35:37 +0000</pubDate>
  271. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  272. <category><![CDATA[Notes Migration]]></category>
  273. <category><![CDATA[Technical]]></category>
  274.  
  275. <guid isPermaLink="false">http://www.docova.com/?p=5444</guid>
  276. <description><![CDATA[Welcome to blog series part 8 of 17 on migrating Notes apps to DOCOVA.  In this entry I&#8217;m going to go over profile documents. In Notes apps, profile docs were convenient for, and typically used for, holding application settings type information.  The information on profile docs was easily gotten with @formula commands like @GetProfileField. The question is: Does DOCOVA support profile documents? Yes.  If a Notes application used profile documents then they will be supported in the migrated application in DOCOVA.  When migrating, of course the related profile document’s form will get migrated.  DOCOVA knows, based on how the form is edited, that the generated/updated document is to be treated as a profile document and saves it as such, similar to the way Domino handled profile docs. When the data of a Notes application is migrated, DOCOVA App Importer™ knows when a document is is a profile type document and will handle the conversion on the DOCOVA side. @Formula methods like @GetProfileField and @SetProfileField are supported in DOCOVAScript™ as $$GetProfileField and $$SetProfileField as well as $$Command([EditProfile]). If you&#8217;ve used profile documents in any of your Notes applications, when they are migrated over to DOCOVA, you can still use them in the same fashion as you did in Notes, and use them in any newly created DOCOVA apps too. 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 &#8211; MIGRATE whitepaper which goes over these technical aspects. Post comments and questions below!]]></description>
  277. <content:encoded><![CDATA[<p>Welcome to blog series part 8 of 17 on migrating Notes apps to DOCOVA.  In this entry I&#8217;m going to go over profile documents.</p>
  278. <p>In Notes apps, profile docs were convenient for, and typically used for, holding application settings type information.  The information on profile docs was easily gotten with @formula commands like @GetProfileField.</p>
  279. <p>The question is: Does DOCOVA support profile documents?</p>
  280. <p>Yes.  If a Notes application used profile documents then they will be supported in the migrated application in DOCOVA.  When migrating, of course the related profile document’s form will get migrated.  DOCOVA knows, based on how the form is edited, that the generated/updated document is to be treated as a profile document and saves it as such, similar to the way Domino handled profile docs.</p>
  281. <p>When the data of a Notes application is migrated, DOCOVA App Importer™ knows when a document is is a profile type document and will handle the conversion on the DOCOVA side.</p>
  282. <p>@Formula methods like @GetProfileField and @SetProfileField are supported in DOCOVAScript™ as $$GetProfileField and $$SetProfileField as well as $$Command([EditProfile]).</p>
  283. <p>If you&#8217;ve used profile documents in any of your Notes applications, when they are migrated over to DOCOVA, you can still use them in the same fashion as you did in Notes, and use them in any newly created DOCOVA apps too.</p>
  284. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology &#8211; MIGRATE whitepaper which goes over these technical aspects.</p>
  285. <p>Post comments and questions below!</p>
  286. ]]></content:encoded>
  287. </item>
  288. <item>
  289. <title>Migrate Notes to DOCOVA Blog Series Part 7: XPages</title>
  290. <link>http://www.docova.com/migrate-notes-to-docova-blog-series-part-7-xpages/</link>
  291. <pubDate>Thu, 20 Apr 2017 14:17:28 +0000</pubDate>
  292. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  293. <category><![CDATA[Notes Migration]]></category>
  294. <category><![CDATA[Technical]]></category>
  295.  
  296. <guid isPermaLink="false">http://www.docova.com/?p=5442</guid>
  297. <description><![CDATA[Welcome to blog series part 7 of 17 on migrating Notes apps to DOCOVA.  In this entry I&#8217;m going to discuss XPages. So, the simple question is: Does DOCOVA migrate and support XPages? Annnnd, the answer is: No. For DOCOVA’s development we pretty much stayed away from XPages for two reasons.  First, although we might have been able to leverage it on the Domino side, it wasn’t a good fit for the SQL edition of DOCOVA which caters to several different relational platforms.  Second, we never really got a good feeling about XPages.  We always felt it was a bit of an odd design construct slapped on a platform that IBM wasn&#8217;t giving much attention to anymore.  For those reasons, we did not invest any time in it except to use it for DOCOVA&#8217;s Public File Access (PFA) component for Domino installed instances. As it turns out, based on the comments coming out of IBM Connect 2017, it appears that IBM has all but abandoned XPages. The good news is that the DOCOVA App Builder is a powerful drag-and-drop, point-and-click IDE that enables businesses to quickly rebuild forms/pages that used XPages.  So, that might be helpful for some. Also, although it might be a bit of a stretch, if you still have the forms and such that you may have redeveloped in XPages then those can/will be migrated and modernized in DOCOVA. Aside from XPages, if you&#8217;ve built Notes applications that are web enabled through passthru HTML/inline JavaScript, DOCOVA does support the migration of all that and will be the topic of another blog post. You can fast-track and get all the whitepapers on our migration methodology and everything that is being discussed in this [&#8230;]]]></description>
  298. <content:encoded><![CDATA[<p>Welcome to blog series part 7 of 17 on migrating Notes apps to DOCOVA.  In this entry I&#8217;m going to discuss XPages.</p>
  299. <p>So, the simple question is: Does DOCOVA migrate and support XPages?</p>
  300. <p>Annnnd, the answer is: No.</p>
  301. <p>For DOCOVA’s development we pretty much stayed away from XPages for two reasons.  First, although we might have been able to leverage it on the Domino side, it wasn’t a good fit for the SQL edition of DOCOVA which caters to several different relational platforms.  Second, we never really got a good feeling about XPages.  We always felt it was a bit of an odd design construct slapped on a platform that IBM wasn&#8217;t giving much attention to anymore.  For those reasons, we did not invest any time in it except to use it for DOCOVA&#8217;s Public File Access (PFA) component for Domino installed instances.</p>
  302. <p>As it turns out, based on the comments coming out of IBM Connect 2017, it appears that IBM has all but abandoned XPages.</p>
  303. <p>The good news is that the DOCOVA App Builder is a powerful drag-and-drop, point-and-click IDE that enables businesses to quickly rebuild forms/pages that used XPages.  So, that might be helpful for some.</p>
  304. <p>Also, although it might be a bit of a stretch, if you still have the forms and such that you may have redeveloped in XPages then those can/will be migrated and modernized in DOCOVA.</p>
  305. <p>Aside from XPages, if you&#8217;ve built Notes applications that are web enabled through passthru HTML/inline JavaScript, DOCOVA does support the migration of all that and will be the topic of another blog post.</p>
  306. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology &#8211; MIGRATE whitepaper which goes over these technical aspects.</p>
  307. <p>Post comments and questions below!</p>
  308. ]]></content:encoded>
  309. </item>
  310. <item>
  311. <title>Migrate Notes to DOCOVA Blog Series Part 6: Security</title>
  312. <link>http://www.docova.com/migrate-notes-to-docova-blog-series-part-6-security/</link>
  313. <pubDate>Wed, 19 Apr 2017 13:00:22 +0000</pubDate>
  314. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  315. <category><![CDATA[Notes Migration]]></category>
  316. <category><![CDATA[Technical]]></category>
  317.  
  318. <guid isPermaLink="false">http://www.docova.com/?p=5343</guid>
  319. <description><![CDATA[Welcome to blog series part 6 of 17 on migrating Notes apps to DOCOVA.  In this entry I&#8217;m going to talk about three things. Security, security and security. We thought the security in Notes/Domino was pretty good.  It was clear, easy to manage and provided for a lot of variable implementation.  DOCOVA’s enhanced security capabilities were made so that it is flexible enough to support the Notes/Domino approach to security. DOCOVA application access control is handled similarly to Notes database ACLs.  They are managed through the UI of the DOCOVA App Builder integrated development environment (yes, all browser based) in the Properties of an application.  People, groups and roles can be added and created in the access control of an application and specific functionality can be assigned like the ability to delete documents/records and more. DOCOVA also supports Authors and Readers fields and yes, in conjunction with the access control of the application, similar to how Notes/Domino did.  Additionally, things like controlled access sections and document modes like read mode and edit mode are also supported. From a directory/address book perspective, DOCOVA connects to Address Books and Directories via  LDAP for things like authentication.  For DOCOVA instances that are on non-Domino platforms, DOCOVA allows for the creation of its own self-contained Directory which can be used to manage users and authentication services.  What&#8217;s cool is that both internal directories and the DOCOVA directory can be used simultaneously to do things like manage internal staff in your own internal directories like Active Directory while managing external users via DOCOVA&#8217;s directory. 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 [&#8230;]]]></description>
  320. <content:encoded><![CDATA[<p>Welcome to blog series part 6 of 17 on migrating Notes apps to DOCOVA.  In this entry I&#8217;m going to talk about three things. Security, security and security.</p>
  321. <p>We thought the security in Notes/Domino was pretty good.  It was clear, easy to manage and provided for a lot of variable implementation.  DOCOVA’s enhanced security capabilities were made so that it is flexible enough to support the Notes/Domino approach to security.</p>
  322. <p>DOCOVA application access control is handled similarly to Notes database ACLs.  They are managed through the UI of the DOCOVA App Builder integrated development environment (yes, all browser based) in the Properties of an application.  People, groups and roles can be added and created in the access control of an application and specific functionality can be assigned like the ability to delete documents/records and more.</p>
  323. <p>DOCOVA also supports Authors and Readers fields and yes, in conjunction with the access control of the application, similar to how Notes/Domino did.  Additionally, things like controlled access sections and document modes like read mode and edit mode are also supported.</p>
  324. <p>From a directory/address book perspective, DOCOVA connects to Address Books and Directories via  LDAP for things like authentication.  For DOCOVA instances that are on non-Domino platforms, DOCOVA allows for the creation of its own self-contained Directory which can be used to manage users and authentication services.  What&#8217;s cool is that both internal directories and the DOCOVA directory can be used simultaneously to do things like manage internal staff in your own internal directories like Active Directory while managing external users via DOCOVA&#8217;s directory.</p>
  325. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology &#8211; MIGRATE whitepaper which goes over these technical aspects.</p>
  326. <p>If you have any questions or comments, post &#8217;em below.</p>
  327. ]]></content:encoded>
  328. </item>
  329. <item>
  330. <title>Migrate Notes to DOCOVA Blog Series Part 5: File attachments</title>
  331. <link>http://www.docova.com/migrate-notes-to-docova-blog-series-part-5-file-attachments/</link>
  332. <pubDate>Tue, 18 Apr 2017 15:33:01 +0000</pubDate>
  333. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  334. <category><![CDATA[Notes Migration]]></category>
  335. <category><![CDATA[Technical]]></category>
  336.  
  337. <guid isPermaLink="false">http://www.docova.com/?p=5341</guid>
  338. <description><![CDATA[Welcome to blog series part 5 of 17 on migrating Notes apps to DOCOVA.  In this entry I&#8217;m going to talk about how file attachments are migrated over to DOCOVA. When it comes to the importing of data from a Notes application to a DOCOVA application, the DOCOVA App Importer initially scans and detects all file attachments in the source nsf and keeps track of what form design elements contain an attachment. As the import of form designs occurs, if a form had an attachment, not only will the App Importer import the form design element, but it will also add the DOCOVA file attachment element to that form.  The DOCOVA file attachment element is one of the most powerful file attachment handlers available for browser applications and allows for things like editing files in-place, renaming files and much more. If you&#8217;re using DOCOVA on Domino then attachments remain with their newly created associated document in DOCOVA.  In non-Domino DOCOVA instances the file attachments are moved and stored on the new server’s file system and associated to their parent document/record.  No matter what the backend platform is, Domino or SQL, from a user&#8217;s perspective the DOCOVA interface is always the same, showing the attachments on their documents via the DOCOVA file attachment element. All attachments in DOCOVA are full-text indexed regardless of platform so that all attachments are part of the full-text searching capabilities of DOCOVA. 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 &#8211; MIGRATE whitepaper which goes over these technical aspects. Comment below!]]></description>
  339. <content:encoded><![CDATA[<p>Welcome to blog series part 5 of 17 on migrating Notes apps to DOCOVA.  In this entry I&#8217;m going to talk about how file attachments are migrated over to DOCOVA.</p>
  340. <p>When it comes to the importing of data from a Notes application to a DOCOVA application, the DOCOVA App Importer initially scans and detects all file attachments in the source nsf and keeps track of what form design elements contain an attachment.</p>
  341. <p>As the import of form designs occurs, if a form had an attachment, not only will the App Importer import the form design element, but it will also add the DOCOVA file attachment element to that form.  The DOCOVA file attachment element is one of the most powerful file attachment handlers available for browser applications and allows for things like editing files in-place, renaming files and much more.</p>
  342. <p><a href="http://www.docova.com/wp-content/uploads/2017/03/files.jpg"><img class="alignnone size-full wp-image-5404" src="http://www.docova.com/wp-content/uploads/2017/03/files.jpg" alt="files" width="1036" height="285" srcset="http://www.docova.com/wp-content/uploads/2017/03/files.jpg 1036w, http://www.docova.com/wp-content/uploads/2017/03/files-300x83.jpg 300w, http://www.docova.com/wp-content/uploads/2017/03/files-768x211.jpg 768w, http://www.docova.com/wp-content/uploads/2017/03/files-1024x282.jpg 1024w" sizes="(max-width: 1036px) 100vw, 1036px" /></a></p>
  343. <p>If you&#8217;re using DOCOVA on Domino then attachments remain with their newly created associated document in DOCOVA.  In non-Domino DOCOVA instances the file attachments are moved and stored on the new server’s file system and associated to their parent document/record.  No matter what the backend platform is, Domino or SQL, from a user&#8217;s perspective the DOCOVA interface is always the same, showing the attachments on their documents via the DOCOVA file attachment element.</p>
  344. <p>All attachments in DOCOVA are full-text indexed regardless of platform so that all attachments are part of the full-text searching capabilities of DOCOVA.</p>
  345. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology &#8211; MIGRATE whitepaper which goes over these technical aspects.</p>
  346. <p>Comment below!</p>
  347. ]]></content:encoded>
  348. </item>
  349. <item>
  350. <title>Migrate Notes to DOCOVA Blog Series Part 4: Richtext and Doclinks</title>
  351. <link>http://www.docova.com/migrate-notes-to-docova-blog-series-part-4-richtext-and-doclinks/</link>
  352. <pubDate>Wed, 12 Apr 2017 13:57:35 +0000</pubDate>
  353. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  354. <category><![CDATA[Notes Migration]]></category>
  355. <category><![CDATA[Technical]]></category>
  356.  
  357. <guid isPermaLink="false">http://www.docova.com/?p=5339</guid>
  358. <description><![CDATA[Welcome to blog series part 4 of 17 on migrating Notes apps to DOCOVA.  In this blog entry I&#8217;ll talk about richtext and how it gets migrated over. So, first off, there is  no such thing as a “richtext” field in a browser as compared to what a richtext field is in a Notes client.  If you are running DOCOVA on a Domino platform rather than one of the other SQL database platforms, DOCOVA RT remains RT and is rendered to HTML by the server when the page/form is first loaded.  From that point on it is treated and stored as HTML content.  On non-Domino SQL platforms as part of the migration and we convert the RT content to HTML and store it as HTML. With DOCOVA, when creating or editing a page/form in DOCOVA, a couple of HTML editor options are used to enable much of the functionality that a richtext field had in the Notes client.  One of the HTML editors is the TinyMCE plugin and the other is a custom DOCOVA HTML editor that we&#8217;ve built. One question that gets asked is what happens to the doclinks that were in richtext fields?  When migrating data from Notes documents that have richtext fields that contain doclinks, we track which documents have the doclinks and what those links are “hooked” to.  As we migrate the data we keep track of what documents have the doclinks and what the doclinks are connected to so that once the data lands in DOCOVA the links are reconnected. Additionally, DOCOVA’s API has a richtext navigator class that operates similarly to the NotesRichtextNavigator class to support any code that might leverage this class. You can fast-track and get all the [&#8230;]]]></description>
  359. <content:encoded><![CDATA[<p>Welcome to blog series part 4 of 17 on migrating Notes apps to DOCOVA.  In this blog entry I&#8217;ll talk about richtext and how it gets migrated over.</p>
  360. <p>So, first off, there is  no such thing as a “richtext” field in a browser as compared to what a richtext field is in a Notes client.  If you are running DOCOVA on a Domino platform rather than one of the other SQL database platforms, DOCOVA RT remains RT and is rendered to HTML by the server when the page/form is first loaded.  From that point on it is treated and stored as HTML content.  On non-Domino SQL platforms as part of the migration and we convert the RT content to HTML and store it as HTML.</p>
  361. <p>With DOCOVA, when creating or editing a page/form in DOCOVA, a couple of HTML editor options are used to enable much of the functionality that a richtext field had in the Notes client.  One of the HTML editors is the TinyMCE plugin and the other is a custom DOCOVA HTML editor that we&#8217;ve built.</p>
  362. <p>One question that gets asked is what happens to the doclinks that were in richtext fields?  When migrating data from Notes documents that have richtext fields that contain doclinks, we track which documents have the doclinks and what those links are “hooked” to.  As we migrate the data we keep track of what documents have the doclinks and what the doclinks are connected to so that once the data lands in DOCOVA the links are reconnected.</p>
  363. <p>Additionally, DOCOVA’s API has a richtext navigator class that operates similarly to the NotesRichtextNavigator class to support any code that might leverage this class.</p>
  364. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology &#8211; MIGRATE whitepaper which goes over these technical aspects.</p>
  365. <p>Please leave any comments/feedback below!</p>
  366. ]]></content:encoded>
  367. </item>
  368. <item>
  369. <title>Migrate Notes to DOCOVA Blog Series Part 3: @formula language</title>
  370. <link>http://www.docova.com/migrate-notes-to-docova-blog-series-part-3-formula-language/</link>
  371. <pubDate>Mon, 10 Apr 2017 14:59:34 +0000</pubDate>
  372. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  373. <category><![CDATA[Notes Migration]]></category>
  374. <category><![CDATA[Technical]]></category>
  375.  
  376. <guid isPermaLink="false">http://www.docova.com/?p=5337</guid>
  377. <description><![CDATA[Welcome to blog series part 3 of 17 on migrating Notes apps to DOCOVA. In this post I&#8217;m going to talk about @formula and @command language. Most Notes apps have the @formula and @command language strewn throughout them.  The @formula and @command languages were very useful in that they were an easy way to quickly accomplish simple tasks as well as tackle what were sometimes quite complex operations without being a master coder. In order to handle the conversion of @formula and @command languages, we dropped DOCOVAScript™ into DOCOVA.  DOCOVAScript is its own scripting language and can support the @[email protected] language conversion from Notes.  The big diff is that DOCOVA uses “$$” in front of its commands instead of the &#8220;@&#8221; sign.  For example, @DbColumn is supported with $$DBColumn.  @Username is $$Username and so on.  Pretty straightforward. I&#8217;m really pleased with how DOCOVAScript has turned out in DOCOVA.  It&#8217;s such a big part of what Notes apps were that I&#8217;m glad we can support it. The next question you should ask is&#8230;.what about @if, @do and @for statements?  And the answer is yes, those are converted too. When the DOCOVA App Importer encounters any @formula or @command functions it converts them to a corresponding $$ DOCOVAScript command that supports them.  There are some anomalies that are handled when converting this code due to some of the deep nesting capabilities of these functions in Notes not having the same context in a browser. As a result, some of the more complex nested @ code may need to be jigged slightly different (identified by DOCOVA Analyzer™), but for Notes developers making the transition to DOCOVA, the code is easy to identify and leverage&#8230;and of course the resulting capability [&#8230;]]]></description>
  378. <content:encoded><![CDATA[<p>Welcome to blog series part 3 of 17 on migrating Notes apps to DOCOVA. In this post I&#8217;m going to talk about @formula and @command language.</p>
  379. <p>Most Notes apps have the @formula and @command language strewn throughout them.  The @formula and @command languages were very useful in that they were an easy way to quickly accomplish simple tasks as well as tackle what were sometimes quite complex operations without being a master coder.</p>
  380. <p>In order to handle the conversion of @formula and @command languages, we dropped DOCOVAScript™ into DOCOVA.  DOCOVAScript is its own scripting language and can support the @[email protected] language conversion from Notes.  The big diff is that DOCOVA uses “$$” in front of its commands instead of the &#8220;@&#8221; sign.  For example, @DbColumn is supported with $$DBColumn.  @Username is $$Username and so on.  Pretty straightforward.</p>
  381. <p>I&#8217;m really pleased with how DOCOVAScript has turned out in DOCOVA.  It&#8217;s such a big part of what Notes apps were that I&#8217;m glad we can support it.</p>
  382. <p>The next question you should ask is&#8230;.what about @if, @do and @for statements?  And the answer is yes, those are converted too.</p>
  383. <p>When the DOCOVA App Importer encounters any @formula or @command functions it converts them to a corresponding $$ DOCOVAScript command that supports them.  There are some anomalies that are handled when converting this code due to some of the deep nesting capabilities of these functions in Notes not having the same context in a browser. As a result, some of the more complex nested @ code may need to be jigged slightly different (identified by DOCOVA Analyzer™), but for Notes developers making the transition to DOCOVA, the code is easy to identify and leverage&#8230;and of course the resulting capability is similar.</p>
  384. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that is being discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology &#8211; MIGRATE whitepaper which goes over these technical aspects.</p>
  385. <p>Questions? Comments?  Enter them below.</p>
  386. ]]></content:encoded>
  387. </item>
  388. <item>
  389. <title>Migrate Notes to DOCOVA Blog Series Part 2: LotusScript</title>
  390. <link>http://www.docova.com/migrate-notes-to-docova-blog-series-part-2-lotusscript/</link>
  391. <pubDate>Thu, 06 Apr 2017 13:30:38 +0000</pubDate>
  392. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  393. <category><![CDATA[Notes Migration]]></category>
  394. <category><![CDATA[Technical]]></category>
  395.  
  396. <guid isPermaLink="false">http://www.docova.com/?p=5335</guid>
  397. <description><![CDATA[Welcome to blog series part 2 of 17 on migrating Notes apps to DOCOVA.  In this entry I&#8217;m going to go over LotusScript. In part 3 of this series I&#8217;ll talk about @formula and @command language. When we began to embark on the journey of providing a killer platform and migration strategy to bring Notes applications to DOCOVA, we knew that the conversion of LotusScript was going to be an important part of it. Converting LotusScript to JavaScript and PHP is complex.  If anyone out there has ever embarked on writing a grammar, lexer/parser for converting one programming language to another, you know what I mean. But it&#8217;s more than just the conversion of one programming language to another, it&#8217;s also about the object model and API that address that model. To facilitate migrations from Notes to DOCOVA and indeed provide similar powerful app building constructs, we dropped an object model into DOCOVA that, among other things, is supportive when converting Notes code. We also dropped in a JSON based API with front and back-end methods and properties in order to support the conversion of LotusScript methods and properties.  This support allows for a more direct conversion when migrating Notes applications to DOCOVA, and enables developers to hit the ground running. Example time!  To give you a bit of an idea of what some LotusScript converted to DOCOVA&#8217;s API looks like, here is an example of defining a workspace object and composing a new document by providing a form name. In LotusScript it would look something like this, Dim workspace As New NotesUIWorkspace Call workspace.ComposeDocument( &#8220;&#8221;, &#8220;&#8221;, &#8220;Main Topic&#8221; ) In DOCOVA&#8217;s API (Javascript in this particular case) it would look like this; var workspace [&#8230;]]]></description>
  398. <content:encoded><![CDATA[<p>Welcome to blog series part 2 of 17 on migrating Notes apps to DOCOVA.  In this entry I&#8217;m going to go over LotusScript. In part 3 of this series I&#8217;ll talk about @formula and @command language.</p>
  399. <p>When we began to embark on the journey of providing a killer platform and migration strategy to bring Notes applications to DOCOVA, we knew that the conversion of LotusScript was going to be an important part of it.</p>
  400. <p>Converting LotusScript to JavaScript and PHP is complex.  If anyone out there has ever embarked on writing a grammar, lexer/parser for converting one programming language to another, you know what I mean.</p>
  401. <p>But it&#8217;s more than just the conversion of one programming language to another, it&#8217;s also about the object model and API that address that model.</p>
  402. <p>To facilitate migrations from Notes to DOCOVA and indeed provide similar powerful app building constructs, we dropped an object model into DOCOVA that, among other things, is supportive when converting Notes code.</p>
  403. <p>We also dropped in a JSON based API with front and back-end methods and properties in order to support the conversion of LotusScript methods and properties.  This support allows for a more direct conversion when migrating Notes applications to DOCOVA, and enables developers to hit the ground running.</p>
  404. <p>Example time!  To give you a bit of an idea of what some LotusScript converted to DOCOVA&#8217;s API looks like, here is an example of defining a workspace object and composing a new document by providing a form name.</p>
  405. <p><strong>In LotusScript it would look something like this,</strong></p>
  406. <p><span style="color: #008000;">Dim workspace As New NotesUIWorkspace</span><br />
  407. <span style="color: #008000;">Call workspace.ComposeDocument( &#8220;&#8221;, &#8220;&#8221;, &#8220;Main Topic&#8221; )</span></p>
  408. <p><strong>In DOCOVA&#8217;s API (Javascript in this particular case) it would look like this;</strong></p>
  409. <p><span style="color: #008000;">var workspace = Docova.getUIWorkspace();</span><br />
  410. <span style="color: #008000;">workspace.compose({ </span><span style="color: #008000;">formname: &#8220;Main Topic&#8221; </span><span style="color: #008000;">});</span></p>
  411. <p>DOCOVA implements a front-end and back-end class structure with classes like DOCOVAUIDocument and DOCOVAView.</p>
  412. <p>With the class structure and API in hand, the DOCOVA App Importer does two things.  One it converts the Lotusscript programming language to JavaScript and/or PHP as needed and two, replaces Notes class and API references with DOCOVA class and API references.</p>
  413. <p>Also worth mentioning is that DOCOVA’s App Importer will handle anomalies such as case-sensitivity.  LotusScript didn’t care if you used a mix of case with variables.  For example, if a variable named “MyField” was initially declared, but then later in the code referenced as “myfield”, LotusScript was quite happy with that.  Other programming languages don’t allow this including JavaScript and PHP. DOCOVA’s importing process works to resolve these types of issues at import time.</p>
  414. <p>It all sounds pretty magical eh?  Well, it is, but now for a bit of a reality check.</p>
  415. <p>Although the DOCOVA conversion is impressive, DOCOVA does not support every class that is provided in the Notes/Domino environment.  This is mainly due to the fact that many Notes/Domino classes no longer make sense and have no context in browser land.</p>
  416. <p>Providing class and API similarities makes the transition for I.T staff and consultants much faster and easier while removing a significant amount of risk from these migration efforts.</p>
  417. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that will be discussed in this series of posts.  Specifically, you can get the DOCOVA Notes/Domino Migration Methodology &#8211; MIGRATE whitepaper which goes over these technical aspects.</p>
  418. <p>Hit us up for a demonstration!  Comment below.</p>
  419. ]]></content:encoded>
  420. </item>
  421. <item>
  422. <title>Migrate Notes to DOCOVA Blog Series Part 1: What gets migrated?</title>
  423. <link>http://www.docova.com/migrate-notes-to-docova-blog-series-part-1-what-gets-migrated/</link>
  424. <pubDate>Tue, 04 Apr 2017 14:11:39 +0000</pubDate>
  425. <dc:creator><![CDATA[John Ryan]]></dc:creator>
  426. <category><![CDATA[Notes Migration]]></category>
  427. <category><![CDATA[Technical]]></category>
  428.  
  429. <guid isPermaLink="false">http://www.docova.com/?p=5333</guid>
  430. <description><![CDATA[Welcome to the first installment of the Migrate Notes to DOCOVA blog series.  This is a multi-part series touching on what gets migrated when moving Notes applications to the DOCOVA collaboration platform.  It doesn&#8217;t have to be Sharepoint.  I will publish entries on a regular basis, every couple of days or so, I&#8217;m shooting for Tuesdays and Thursdays right now. You can fast-track and get all the whitepapers on our migration methodology and everything that will be discussed in these blog posts. The &#8220;parts&#8221; of this series are based around questions we frequently get asked about what gets migrated to DOCOVA when migrating a Notes application, so, although there will be 17 parts, if I get asked about other things that emerge as important enough to blog about, then I might add more. If you have questions that you don&#8217;t want to drop into the comments section you can email me at [email protected] Who am I?  I&#8217;m John Ryan, I&#8217;ve been working with Notes and Domino since 1993.  I am a co-owner, with Gary Walsh, of DLI.tools Inc., the company behind DOCOVA.  I am the CTO here and chief architect of DOCOVA&#8230;although (tongue in cheek)&#8230;really, I&#8217;m just the guy who sets impossible goals for our exceptional development team&#8230;and somehow, they pull it off!  We&#8217;ve won many awards (11 of them) over the years for DOCOVA and other software products we&#8217;ve developed. I&#8217;m really jazzed about our new version of DOCOVA.  It is version 5.  In version 5 we&#8217;ve added a user workspace, a browser-based integrated development environment called App Builder and App Importer, an integrated tool you run in DOCOVA to import Notes applications into DOCOVA. When investigating Notes application migration solutions, Notes developers should [&#8230;]]]></description>
  431. <content:encoded><![CDATA[<p>Welcome to the first installment of the Migrate Notes to DOCOVA blog series.  This is a multi-part series touching on what gets migrated when moving Notes applications to the DOCOVA collaboration platform.  It doesn&#8217;t have to be Sharepoint.  I will publish entries on a regular basis, every couple of days or so, I&#8217;m shooting for Tuesdays and Thursdays right now.</p>
  432. <p>You can fast-track and get <strong><a href="http://www.docova.com/migrationmethodology/">all the whitepapers on our migration methodology</a> </strong>and everything that will be discussed in these blog posts.</p>
  433. <p>The &#8220;parts&#8221; of this series are based around questions we frequently get asked about what gets migrated to DOCOVA when migrating a Notes application, so, although there will be 17 parts, if I get asked about other things that emerge as important enough to blog about, then I might add more.</p>
  434. <p>If you have questions that you don&#8217;t want to drop into the comments section you can email me at [email protected]</p>
  435. <p>Who am I?  I&#8217;m John Ryan, I&#8217;ve been working with Notes and Domino since 1993.  I am a co-owner, with Gary Walsh, of DLI.tools Inc., the company behind DOCOVA.  I am the CTO here and chief architect of DOCOVA&#8230;although (tongue in cheek)&#8230;really, I&#8217;m just the guy who sets impossible goals for our exceptional development team&#8230;and somehow, they pull it off!  We&#8217;ve won many awards (11 of them) over the years for DOCOVA and other software products we&#8217;ve developed.</p>
  436. <p>I&#8217;m really jazzed about our new version of DOCOVA.  It is version 5.  In version 5 we&#8217;ve added a user workspace, a browser-based integrated development environment called App Builder and App Importer, an integrated tool you run in DOCOVA to import Notes applications into DOCOVA.</p>
  437. <p>When investigating Notes application migration solutions, Notes developers should be asking the tough questions about what exactly gets migrated to the target platform and that&#8217;s what this series is about.</p>
  438. <p>Lots of solutions out there talk about archiving and retiring Notes applications, or switching them over to off-the-shelf (cloud and on premises) solutions.  Dig deeper and you&#8217;ll see their plan is to get your applications down to the bare minimum&#8230;and then redevelop them on the new platform, or use and modify them in some separate interface from the intended target interface.</p>
  439. <p>So, why doesn&#8217;t anybody out there have a true end-to-end migration solution for Notes applications like DOCOVA?  Two reasons, first, because it&#8217;s difficult.  Second, because it&#8217;s difficult.</p>
  440. <p>Companies don&#8217;t want to process re-engineer their Notes applications on a &#8220;new&#8221; software platform because it can&#8217;t do what Notes did.  They need better.  That&#8217;s why we stepped into this arena.</p>
  441. <p>DOCOVA V5 was made to be very flexible and can support many of the design elements coming from Notes applications, helping to make migrations more of an &#8220;apples to apples&#8221; modernizing of your Notes applications.  Trying to migrate to something like Sharepoint and Office 365 is like trying to hammer a square peg into a round hole.</p>
  442. <p>Also, just for the record, I want to point out a couple of things about DOCOVA because we have had developers assume certain things about DOCOVA in the past.  First of all, DOCOVA does not use XPages.  Second, although you can run DOCOVA on Domino as one of the database platforms, the applications are still migrated. This means Notes applications are converted to DOCOVA applications.  DOCOVA does NOT serve as a &#8220;front-end&#8221; to existing NSFs.  Got it?  Let&#8217;s move on.</p>
  443. <p>Okay&#8230;all that said, in this first entry of the blog series, at a high level, let&#8217;s talk about what gets migrated?  Subsequent blog entries will go into more detail about specific elements that get converted.</p>
  444. <p>DOCOVA&#8217;s migration tool is called the App Importer and it will import the user interface (UI), business logic, security, database schema and data.  Each of these is explained in more detail below.</p>
  445. <p><img class="alignnone wp-image-5365 size-full" src="http://www.docova.com/wp-content/uploads/2017/02/WhatGetsMigrated-e1487702173761.jpg" alt="WhatGetsMigrated" width="868" height="565" /></p>
  446. <p><strong>User Interface (UI):</strong></p>
  447. <p>Most of the design elements that make up the Notes application interface like forms, views, subforms, framesets, outlines, pages and image resources are converted to the new migrated application.</p>
  448. <p>Additionally, within these design elements their attributes are maintained.  For example, within forms and subforms, items like fields, tables, controlled access sections and embedded views are brought over.  In views, column properties like “Show multiple values as separate entries” are supported as well as sorting, categorization and totaling (except with totaling&#8230;DOCOVA views don&#8217;t have that extraneous category total.  You know what I mean?  Ya, that&#8217;s a good thing).</p>
  449. <p><strong>Business Logic:</strong></p>
  450. <p>Yep, the code.  When a Notes application is imported into DOCOVA, all of the @[email protected] language and LotusScript is converted to JavaScript and/or PHP.  If you know about parsers and lexers and grammars&#8230;ya&#8230;that stuff.</p>
  451. <p>No need to re-engineer your business processes and logic.  Unless you want to.</p>
  452. <p>Alright, wait a second!  It&#8217;s true that there are significant differences between a Notes client and a browser client.  So, yes, there are anomalies that can happen, however in our DOCOVA Analyzer tool, we identify certain things that need to be reviewed in the code to make sure it was translated properly.  This speeds the QA process significantly.  Best thing to do is get a demo with us.  The conversion is stunning really.</p>
  453. <p><strong>Security:</strong></p>
  454. <p>Security in DOCOVA is very flexible and hence can handle the security aspects found with Notes applications.  Access control lists, access types and fields like authors and readers and controlled access sections are all supported.  DOCOVA can also maintain its own User Directory, but can also integrate with LDAP directory sources like Active Directory and others.  Pretty convenient.</p>
  455. <p><strong>Database Schema:</strong></p>
  456. <p>So this is pretty killer.  When importing a Notes application over to DOCOVA, you don’t have to first create the database layout like tables and table relationships or anything like that.  DOCOVA will automatically create everything for you.</p>
  457. <p><strong>Data:</strong></p>
  458. <p>This one goes without saying, right?  Of course the data has to be migrated too.  All Notes document data is copied over to the new migrated application.  Additionally, all attachments are brought over and things like richtext and doclinks are maintained in the new environment.</p>
  459. <p>Okay&#8230;that&#8217;s enough for this installment.  Stay tuned for Part 2 in this blog series where I will delve deeper into LotusScript, what gets migrated, and how we do it.</p>
  460. <p>Comment below!</p>
  461. ]]></content:encoded>
  462. </item>
  463. </channel>
  464. </rss>
  465.  

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

  1. Download the "valid RSS" banner.

  2. Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)

  3. Add this HTML to your page (change the image src attribute if necessary):

If you would like to create a text link instead, here is the URL you can use:

http://www.feedvalidator.org/check.cgi?url=http%3A//feeds.feedburner.com/DocovaTechincalBlog

Copyright © 2002-9 Sam Ruby, Mark Pilgrim, Joseph Walton, and Phil Ringnalda