Skip to main content

UI Development Framework of choice

Permanently deleted user

Hi Everyone, 

Is there a recommended ui kit that can be used to develop custom UI for geocortex html5 apps? I see partial kendo ui and dojo being used. But what is the best compatible framework recommended for developing custom UI. 

I tried bootstrap JS for some layout work and it ended up messing up styles in geocortex. If there is a reference UI toolkit and a style guide it would immensely help with the development. 

Thanks in Advance.

 

0

Comments

7 comments

Date Votes
  • Kevin Penner

    Have a look at the SDK which describes in detail how to create custom views  using our framework. If you have any questions, please ask! The SDK ships with the viewer template and can be deployed straight into a virtual directory and hosted for quick interaction.

     

    0
  • Permanently deleted user

    @mlangley - a blast from the past - how are you!

    @kpenner - jetlag getting better of you for early start ; )

    0
  • Permanently deleted user

    Thanks for your response kevin. 

    The SDK samples are good to get the general concepts but not enough when building custom UI components. The doco indicates to use liquid-layout framework where possible.  

    I am developing a custom ui which has a form and a results grid. It would be really easy to build this layout responsively using a bootstrap/foundation type framework. What I am looking for is what is the recommended libraries/framworks to use for developing say a Grid control or a form layout, or even a calendar widget. 

    Maybe there is nothing like that and we have to experiment with different UI frameworks to see which doesn't clash with Geocortex UI framwork for building custom UI components?

     

     

    0
  • Permanently deleted user

    Matt, David

    We don't have a list of "recommended" UI frameworks/toolkits for HTML5 development so you might need to try out different ones until you find a good fit for your project. Having said that, we have had success in the past integrating various Kendo UI components into the HTML5 viewer (e.g. Charts) and our professional services devs have added custom kendo grids to GVH for some of their projects. Kendo is very well documented, it is based on JQuery (which is already included/supported in GVH) and there are a lot of resources and samples out there to get you started.

    Hope this helps,

    --Alejandro

     

    0
  • Permanently deleted user

    @Alejandro - forgive me if this is a dumb question, but did Latitude basically come up with their own MVVM javascript framework for GVH?

     

    The reason I ask is that I'm finding zero information online for any of the data binding that is described in the Admin/Dev guide and the sample modules.  For example the basic 'data-binding' directive doesn't seem to match the way any other framework like Kendo or Bootstrap - they use directives like 'data-bind' and don't seem to have an equivalent to 'template-for'.

     

    The reason I ask is that I'm struggling to to find sufficient documentation on the JS framework that Latitude uses, in order to do the things I need.  The samples cover the basics, but not much beyond that.  As an example, I would like to know if there is an equivalent to the Kendo 'data-option-label' for a combobox so I can add a default message at the top of the combobox list.  This is just one example - is there full framework documentation available?  It would make our development much faster/easier.

    Peter.

    0
  • Permanently deleted user
    That's actually a really good question, and the answer touches on questions in this thread by @Matt and @David.   We did indeed build our own MVVM framework, and it's based on patterns and practices that we developed in our Silverlight viewer (as well as in viewers prior).   Ultimately, we want custom developers to be able to choose whatever UI frameworks and toolkits they see fit. In fact, that was part of the decision to build the underlying framework ourselves: It means we can provide scaffolding and direction for people to get started in the viewer with, and it means we can do so without binding them to some external UI framework choice they had no say in. Choosing a framework like Angular or React can be a big, critical decision for larger projects. Our opinion is that we should leave that choice to you, the developer!   One thing that perhaps isn't made clear enough is that while we provide out of the box facilities for lightweight data-binding and templating, using these is optional. With a bit of knowledge about how the viewer manages UI components and their lifecycles, it's fairly straightforward to integrate custom widgets (e.g. jQuery, dijits, et cetera). I'll follow up in this thread with a quick overview of custom UI development in the viewer, in case it can be of use to anyone.   We recognize that there is a lack of in-depth, conceptual documentation around the custom development experience. This is something we are actively addressing. To that end, we've been identifying and enumerating a set of new development examples to produce, along with the conceptual materials that developers need most.   We welcome any and all feedback on what kinds of documentation materials and concepts would be most beneficial. Please feel free to use this thread, or start new ones for any development-centric topics you have, including requests for samples.   @Matt and/or @David, an explanation of the way the viewer manages UI elements (views) may be useful. Understanding how the pieces connect and what their lifecycles are may give you a good starting place to start building custom UI components. As mentioned above, I'll follow up in this thread with some info in case it's of some use. You can build custom UI components with the built-in facilities, other frameworks, jQuery, or a mix of all of these approaches.   @Peter, the "data-binding" attribute you refer to is our own. If you haven't already, you can find examples of data-binding in the "SamplesViewer" project that ships with the viewer, as Kevin points out. That project contains a number of examples that cover a fairly broad set of scenarios. A good approach to getting started is to use the QuickStart module as a sandbox, with the SDK Samples as reference points. There is framework level API reference, linked from the SamplesViewer (top right corner), but currently the only conceptual materials live in the Admin and Dev guide and the SDK Samples themselves.  
    0
  • Permanently deleted user
    A hypothetical UI component "ScaleInputBox" might have the following components:    - ScaleInputBoxView.html: The HTML template that the viewer will create and add to the DOM in the region specified in configuration.  - ScaleInputBoxView.ts: The code-behind that has any and all UI-centric code, e.g. handling the "enter" key being pressed and asking the view model to perform a zoom.  - ScaleInputBoxViewModel.ts: Contains data and business logic for the component, e.g. the current scale value, and a method to zoom to it.  - ScaleInputBoxModule.ts: Contains configuration or low level command/event implementations.    Also:  - common.css: CSS rules, common to all form factors, from small devices like phones, up to large devices like desktop workstations.  - small.css/medium.css/large.css: Optional, size-specific stylesheets. Correspond roughly to phones, tablets, desktops. Compiled in and automatically added to the DOM when a module loads.  - language.json.js: Key/value strings pairs that are compiled into the output code. These are aggregated into "locale files" and can be translated later.   The QuickStart has most of these components organized and ready to go. By the time the viewer loads it up, you're left holding the following:   - The View Markup: A piece of live HTML markup, created from your template and placed in the DOM for you. - The View: A class representing your component's UI behaviour, with a reference to the markup's DOM node ("this.root"), a reference to its data and business logic (view model). - The View Model: A class representing your component's state and business logic, with the ability to invoke and respond to viewer-wide "commands" and "events".  - The Module: A class representing your component's lower level concerns, e.g. implementing non-UI commands, managing configuration, pulling in dependencies, et cetera.   At this point, what you do with these pieces is up to you. You've got a DOM node, and some code with a reference to it, along with a place to put component specific styles and strings. With this knowledge in mind,    This is the point where our framework tries to step away: You're handed the aforementioned pieces and away you go. Aside from occasionally "activating" and "deactivating" your view, the framework largely gets out of the way. At this point, developers are free to use these objects as they see fit. We've tried to provide the basic building blocks of well-organized applications, while enforcing a degree of separation of concerns.   Tips:   Views have a well-defined lifecycle, with certain functions called at certain times:       - "attach": Called when a view is "attached" to a view model. This is called for you by the framework, unless you're creating views programatically.     - "added": Called when the view is added to the DOM.     - "removed": Called when the view is removed from the DOM. Use when cleaning up custom DOM stuff.     - "activated": Called when the view is "activated": Made visible or otherwise "active" by the user or some other component.     - "deactivated": Called when the view is "deactivated": Made non-visible or otherwise "inactive" by the user or some other component.      You can implement these in your view's class to tap into the lifecycle.     Internally, we follow some fairly straightforward rules when it comes to UI development:       - Any code that has to touch the DOM manually (rather than data-binding) should go in a view.     - Handling of user events like clicks and presses go into views.     - Views generally don't manipulate DOM outside of their root.     - Views generally don't look at the DOM outside of their root, e.g. they don't make assumptions about their parentNode.     - Views have reference to their root "this.root". All DOM querying and manipulation should be relative to this root. For example:  (".some-class", this.root); // <- second arg constrains the query.     - Avoiding IDs is good practice. Since they are unique to a page document, they can prevent having multiple instances of a component (or template!) on a page.     - Leverage data-binding whenever possible (either via the builtin system or via some other framework). DOM code is expensive.     - Keeps concerns separate! Business code and UI concerns are typically best kept separate, particularly when building large systems and/or reusable components.        Hopefully this yields some sort of useful info or insight. Please feel free to ask any specific questions about data-binding or MVVM UI construction in general.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post