Responsive skin when using script to populate topic

This forum is for discussions on the Help & Manual Premium Pack and the Premium Pack Toolbox configuration utility introduced with Premium Pack 3

Moderators: Alexander Halser, Tim Green

Post Reply
Helen Abbott
Posts: 26
Joined: Mon Dec 17, 2012 3:53 pm

Responsive skin when using script to populate topic

Unread post by Helen Abbott »

I'm trying to use a v3 responsive skin, Premium Pack version 3.15.

After publishing WebHelp, I need to run a script that populates content in several reference topics.

With a non-responsive skin, this works fine - I've been using the script for a few months now.

With a responsive skin (without any customization), I have to manually refresh the page contents every time I hit the page. Otherwise, the unsubstituted variables are displayed.

Is populating topic contents with a script supported with v3 skins?

Thanks,
Helen Abbott
You do not have the required permissions to view the files attached to this post.
User avatar
Tim Green
Site Admin
Posts: 23154
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: Responsive skin when using script to populate topic

Unread post by Tim Green »

Hi Helen,
Is populating topic contents with a script supported with v3 skins?
This isn't possible in the way you have been doing it because of the way that the new WebHelp 3 format works. Topics are no longer loaded as normal HTML files. The original page you visit is a normal HTML file, but that then becomes your main page. After that, browsing to a new topic is performed in a different way. The new topic is loaded by getting the content from a compressed data file and replacing the contents of the current topic with the new topic contents.

This only replaces the content area of the page, everything else remains unchanged. This is many orders of magnitude faster than just loading a normal HTML file, because all the other page components, CSS files, JS files etc. are already there. Particularly in large complex pages, this can reduce page loading times from seconds to milliseconds. This is particularly important on mobile devices, but it is also a much better user experience on desktop browsers as well.

Theoretically, it would still be possible to update the content from a script. However, you would need to synchronize this with the page loading script of the skin, so that your routines for changing the HTML content in the DOM are executed after everything else has loaded and all dynamic operations have terminated.

The simplest way to do this would be to introduce a delay that is long enough so that you are sure everything is loaded when you perform your operations. That would really be the only solution at the moment. I've made a note of this, and I will look into introducing hooks that external scripts can hook into to perform actions after the page is loaded.
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Helen Abbott
Posts: 26
Joined: Mon Dec 17, 2012 3:53 pm

Re: Responsive skin when using script to populate topic

Unread post by Helen Abbott »

Thanks for your reply, Tim. Unfortunately I'll have to hold off on customizing a responsive skin for now. If you implement hooks for external scripts, I look forward to trying again!

Helen
User avatar
Tim Green
Site Admin
Posts: 23154
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: Responsive skin when using script to populate topic

Unread post by Tim Green »

Hi Helen,

I'll keep you posted! :)
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Simon Dismore
Posts: 454
Joined: Thu Nov 16, 2006 1:29 pm
Location: London, UK

Re: Responsive skin when using script to populate topic

Unread post by Simon Dismore »

Helen Abbott wrote:After publishing WebHelp, I need to run a script that populates content in several reference topics.
Instead of running your script after publishing the WebHelp, would it be feasible to have the script generate the help tables in advance? If so, I can imagine two approaches.

(A) Scripts create HTML, linked via #MERGE
In this approach you have your script create the variable tables as external "partial" HTML files and then use #MERGE to insert the file contents into the topics during compilation. By partial, I mean the file doesn't have <html><head></head><body></body>, but just a node like:

Code: Select all

<table class="help-table" cellspacing="0" cellpadding="0">
    <thead>
        <tr>
            <th>Variable</th>
            <th>Expression</th>
            <th>Description</th>
        </tr>
    </thead>
    <tbody>
        <!-- etc etc -->
    </tbody>
</table>
Option A has the advantage of being pretty simple to test. You could create the partial pages manually by editing your non-responsive output, but that would be tedious to maintain. Alternatively you could automate this using a copy of your existing project. I can set out the steps if you're interested. The HTML partial files may be re-usable in web applications that have front-ends built using React, Angular, Meteor etc.

(B) Scripts create XML, linked as snippets
If you are using the Pro version of Help & Manual you could alternatively have your script create the variable tables as files in H&M XML format which you can then link as snippets. The syntax isn't all that different from the HTML your script is already generating (see Helpman_XML_Ref.chm for details). An XML snippet for Approval Workflow Variables for New Requests might be something like this (excluding style attributes):

Code: Select all

<topic template="">
  <body>
    <para><table rowcount="3" colcount="3">
      <thead>
        <td>
          <para><text>Variable</text></para>
        </td>
        <td>
          <para><text>Expression</text></para>
        </td>
        <td>
          <para><text>Description</text></para>
        </td>
      </thead>
      <tr>
        <td colspan="3">
          <para ><text>Request</text></para>
        </td>
      </tr>
      <tr>
        <td>
          <para><text>Change in CPUs</text></para>
        </td>
        <td>
          <para><text>request.changeInCpuCount</text></para>
        </td>
        <td>
          <para><text>For new requests: The difference between the number of CPUs requested and the number of CPUs configured in the service catalog. If using legacy component forms, the requested value is compared to the source template value.</text></para>
          <para><text>For change requests: The difference between the requested number of CPUs and the actual number of CPUs.</text></para>
        </td>
      </tr>
    </table></para>
  </body>
</topic>
Option B has the have the advantage of working in all H&M output formats, not just Web and CHM. The XML files can be managed using other tools like the Premium Pack toolbox and commercial programs like Oxygen, so are re-usable for DITA, e-publishing etc. You can convert from XML to HTML if necessary.
Helen Abbott
Posts: 26
Joined: Mon Dec 17, 2012 3:53 pm

Re: Responsive skin when using script to populate topic

Unread post by Helen Abbott »

Thanks very much Simon. I'll talk to the dev team about this.

Helen
User avatar
Tim Green
Site Admin
Posts: 23154
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: Responsive skin when using script to populate topic

Unread post by Tim Green »

Hi Helen,

In addition to this, I've set up an option that will allow you to add script in an external file containing code to be executed after every page loads. If you write to me a support AT ec-software.com (replace the AT with @) and let me know which skin you want to use this with I can send you a beta version.

The implementation is quite simple: You enter the source code of functions you want to use in an external baggage file with a specific name. Then you enter the name of one (and only one) function you want to execute in a new configuration variable. That function needs to execute everything you require from your code, so if necessary it needs to be the main function that calls all the other functions.
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Post Reply