locked
How display the Browse screens in a one (left) frame in a frameset and the Add-Edit and Details screens in the right frame in a frameset? RRS feed

  • Question

  • Context

    • Think of the Windows Explorer UI with the folder view being displayed in the narrower left pane and the folder details being displayed in the right pane
    • Imagine an HTML frameset the is configured similarly with a narrow frame on the left and a large frame on the right
    • As a concept, I'd like to host a LS HTML app in the left frame (i.e. the default Browse screen) but whenever I click or tap to open the Details form or an Add-New form, these 2 forms appear in the larger right frame.
    • I'm not imagining any sort of hierarchy of objects in the left Browse pane ...just the usual flow/layout of objects the way LS normally would display them.

    Questions

    • Any thoughts on whether this is even remotely possible?
    • If so, how would you approach it?

    Michael Herman (Toronto)


    Xpert Search Agents for Microsoft web sites: http://www.parallelspace.net/MicrodeX

    Friday, November 29, 2013 7:42 PM

Answers

  • Hi Michael,

    I can't say for certain, but I am pretty sure that this is not possible with the current version of the HTML client. The primary reason being is that the current client works on top of JQuery Mobile (JQM) and there is no option to display more that one screen at a given time, with the exception of Popups.  JQM uses a technique to hide/show div areas to hide/show screens (including popups).

    I am however happy to report that this is more than remotely possible. I have been working on a solution that may serve to help with this type of scenario but it is not quite ready for prime time, although not that far away either. 

    I call my solution CompositionJS (CJS), which is a combination of common frameworks and custom script that leverages model meta data to drive complex UI from the HTML LS client.

    In my approach I have chosen to remove the full version of JQM out of the JavaScript stack and have replaced it with a version of JQM that only supports touch and keyboard navigation but not screen layout. 

    To manage screen layout I am using Bootstrap with AngularJS as well I am using the UI-Router library for AngularJS to manage deeply nested routes which should support the type of behavior you described through route layout. 

    I have a custom Angular Screen Service which manages all screen creation called up by custom Angular Screen Directives.  

    Angular Directives provide the ability to create new HTML Element/Attribute declarative types which have a backing scope that is initialized via an Angular Controller. 

    Angular has a Dependency Injection container which I leverage to inject the custom Angular Screen Service directly into the backing Angular controllers which serve to initialize a screen directive.

    Here is a component overview of CJS ...

    The screen directive has a ScreenName attribute which is the name of the LS screen to render.  One or more screen directives can be declared within the markup of a single partial view to compose any complex UI-Route scenario. 

    By simply arranging the partial HTML views within the UI-Route to include one or more screen directives, the underlying screens are automatically surfaced, via way of the Screen service and msls.js.

    Thus in your example as you described, a Browse screen on the right could easily navigate to another LS screen however in a CJS case this would to navigate to a specific route within the UI-Router definitions. 

    In the UI-Router these route definitions can be setup as hierarchal relationships to obtain scenarios such as a master child relationship of views.  

    In the final CJS product I will provide a number of DSL modeling tools to help simplify the layout of screen routes as well as command injection which will emit meta data utilized by framework at runtime. 

    My main focus of late has been on control-view overrides where I am replacing the built-in control-views with custom views.  In particular I am currently focusing on replacing the table control with the Kendo-UI Grid/Pager control.  Once I am able to do this I think the HTML client will gain a lot more usability that it currently has. 

    CJS will utilize 90% of the MSLS script and decouples from JQM allowing for broader usage scenarios of the HTML client.  

    Although this approach is minimally intrusive it does see some small changes to the existing msls.js script as such it may be too customized for your needs.  

    Here is a sample of 3 screen directives on a single page...

    As you will see in this short video, there is still lots more work that needs to be done but it's coming and it will work.

    As I said at the beginning, this is still not ready for prime time, not yet at least.

     

    Cheers

    Johnny


    Johnny Larue, http://www.softlandingcanada.com

    Monday, December 2, 2013 5:58 AM

All replies

  • Hi Michael,

    I can't say for certain, but I am pretty sure that this is not possible with the current version of the HTML client. The primary reason being is that the current client works on top of JQuery Mobile (JQM) and there is no option to display more that one screen at a given time, with the exception of Popups.  JQM uses a technique to hide/show div areas to hide/show screens (including popups).

    I am however happy to report that this is more than remotely possible. I have been working on a solution that may serve to help with this type of scenario but it is not quite ready for prime time, although not that far away either. 

    I call my solution CompositionJS (CJS), which is a combination of common frameworks and custom script that leverages model meta data to drive complex UI from the HTML LS client.

    In my approach I have chosen to remove the full version of JQM out of the JavaScript stack and have replaced it with a version of JQM that only supports touch and keyboard navigation but not screen layout. 

    To manage screen layout I am using Bootstrap with AngularJS as well I am using the UI-Router library for AngularJS to manage deeply nested routes which should support the type of behavior you described through route layout. 

    I have a custom Angular Screen Service which manages all screen creation called up by custom Angular Screen Directives.  

    Angular Directives provide the ability to create new HTML Element/Attribute declarative types which have a backing scope that is initialized via an Angular Controller. 

    Angular has a Dependency Injection container which I leverage to inject the custom Angular Screen Service directly into the backing Angular controllers which serve to initialize a screen directive.

    Here is a component overview of CJS ...

    The screen directive has a ScreenName attribute which is the name of the LS screen to render.  One or more screen directives can be declared within the markup of a single partial view to compose any complex UI-Route scenario. 

    By simply arranging the partial HTML views within the UI-Route to include one or more screen directives, the underlying screens are automatically surfaced, via way of the Screen service and msls.js.

    Thus in your example as you described, a Browse screen on the right could easily navigate to another LS screen however in a CJS case this would to navigate to a specific route within the UI-Router definitions. 

    In the UI-Router these route definitions can be setup as hierarchal relationships to obtain scenarios such as a master child relationship of views.  

    In the final CJS product I will provide a number of DSL modeling tools to help simplify the layout of screen routes as well as command injection which will emit meta data utilized by framework at runtime. 

    My main focus of late has been on control-view overrides where I am replacing the built-in control-views with custom views.  In particular I am currently focusing on replacing the table control with the Kendo-UI Grid/Pager control.  Once I am able to do this I think the HTML client will gain a lot more usability that it currently has. 

    CJS will utilize 90% of the MSLS script and decouples from JQM allowing for broader usage scenarios of the HTML client.  

    Although this approach is minimally intrusive it does see some small changes to the existing msls.js script as such it may be too customized for your needs.  

    Here is a sample of 3 screen directives on a single page...

    As you will see in this short video, there is still lots more work that needs to be done but it's coming and it will work.

    As I said at the beginning, this is still not ready for prime time, not yet at least.

     

    Cheers

    Johnny


    Johnny Larue, http://www.softlandingcanada.com

    Monday, December 2, 2013 5:58 AM
  • Very cool.  Johnny, can you contact me offline at mwherman at parallelspace.net.  Thanks.

    Xpert Search Agents for Microsoft web sites: http://www.parallelspace.net/MicrodeX

    Monday, December 2, 2013 6:59 AM