Please Share your Product Ideas with us!

All ideas are welcome. Just because the Idea doesn't make it into the product immediately does not make it a bad idea.

FullConstruct Page Column order should be configurable

The Full Construct page column order is not always "User Friendly".

  • Some are just annoying such as the Address Fields. (Expect Street, City, State, Zip) as opposed to State, Zip, City, Street)
  • Others such as Templates that combine Header and Detail data should display all the Header columns first followed by the Detail level columns
  • Appended fields display in the "middle" of the Page (e.g. zComment)

On initial observation it looks like the order can be controlled by the Field Priority in Target Design but that is not the case. The attached document  based on a specific Target Design configuration illustrates the column order generated for the following:

  • DCS FullConstruct Table
  • DCS FullConstruct Page
  • DSPConstruct Source Schema (stTABLE generated in dswXXX Database)

NOTE: The column order in the Horizontal View is not the same as the DCS Table column order. Also the stTABLE columns are arranged in a third order. None of which is in the same order as the Target Design Field Priority.

Target Design is actually not even the best method of controlling the Page's Column order since any change to the column order would require another Sync To Map action that has other implications. We have implemented a Workaround that utilizes a separate page that allows the developer to configure the column priorities then click a button that updates the Horizontal View.

  • Tracey Karanovich
  • Oct 14 2017
  • Already exists
  • May 10, 2018

    Admin response

    Column order on the page (web views) is already configurable via priority in Target Design. If you would like to make additional changes without syncing to Map, you should use the Construct Autogen Level feature. 

    Autoconstruct was meant to be a jumpstart to building DCS pages and is not expected to create perfect pages as you specifically want them on build. It is expected that the user would build when necessary, then manually modify the page as they see fit. In order to prevent those changes from being overwritten, there is a setting called 'Construct Auto Gen Level' on the vertical view of the Full Construction Target Source. I have pasted the DSP Help related to the field below. 

     

    Construct Auto Gen Level

    This option controls whether the Construct page is updated or overwritten. Values are:

    • Off - Construct objects and pages are not generated.
    • New - Adds new fields to the page table and new column properties to page. Does not rebuild page views. (You will have to manually add new fields to your Hor and Ver views)
    • Rebuild - Drops and recreates all views and column properties and adds new fields to the page table.

    NOTE: This field defaults to Rebuild.

     

    I have attached a screenshot for you to review. 

  • Attach files
  • Tracey Karanovich commented
    October 19, 2017 04:46

    Regarding the following statement:

    "Column order on the page (web views) is already configurable via priority in Target Design."
    • The Column order is not configurable via priority in Target Design. My attachment provided an example of this. Attached is a more obvious example
    • As stated in the Enhancement Request, Target Design is actually not even the best method of controlling the Page's column order since any change to the column order would require another Sync To Map action that has other implications

    Regarding the suggestion to use the Construct Autogen Level, the key issue is the statement:

    "Autoconstruct was meant to be a jumpstart to building DCS pages and is not expected to create perfect pages as you specifically want them on build."

    This is not a "bug report". We understand the FullConstruct automation functionality is limited and appreciate the significant improvements provided in the DSP6.6 upgrade. This enhancement as well as several others I submitted are intended to provide feedback on what enhancements are needed to move the FullConstruct  functionality past a jumpstart to a robust tool for implementing a Template based migration process.