Kendo UI components concerns

Posted by romain.pennes@foederis.fr on 02-Jun-2015 08:26

Hello,

Since you aquired Telerik, I believe you plan on changing Rollbase HTML form inputs so that it uses kendo UI components.
We have heard that their may be a release this summer which changes Rollbase look and feel by integrating Kendo UI components instead of today's bootstrap components.

As of today, we use many jQuery JavaScripts in our pages in order to manipulate fields (show / hide them depending on the context for instance). In order to do this, we use jQuery to retrieve components who are named "rbi_F_...." or "rbi_L_...." which is the name assigned by Rollbase to tables cells who contain form inputs.

Also, we interact directly with certain form inputs by using their integration name which is set in the "id" and "name" properties of each HTML inputs.

When you finally integrate Kendo UI to Rollbase, do you know if their may be changes to the names / ids being used in form inputs, table cells, tables etc.?

If their are indeed changes of the sort, can you give us some information on to what is going to change exactly, because this would mean our applications will not be functional anymore if we are not prepared for this changes.

Kind regards,

Romain.

All Replies

Posted by Santosh Patel on 03-Jun-2015 01:16

I would like to understand the use case where you needed to access the form element container (rbi_F_ and rbi_L_).

Rest assure that the method to refer form inputs via id and name as integration name is not changing. However, Kendo UI does put a wrapper around the HTML element to provide styling of their own, which means to make visible changes to  some form elements (say picklist which would be kendo dropdownlist) you will need to use Kendo APIs exposed on that element.

e.g. $('[name=statePicklist]') would be what you are using now to get the picklist and change values.

with Kendo dropdownlist wrapper, this would change to $('[name=statePicklist]').data('kendoComboBox').select(...)

To summarize, form elements id and name are not changing with the Kendo integration. Neither are any of the documented methods to access such elements (rbf_getSectionBy...). We also are trying to minimize the changes to such elements in the undocumented part but some places may require restructuring to move towards a cleaner and easy to access solution.

Posted by Gian Torralba on 03-Jun-2015 12:22
Hello,

Please see the quoted text below regarding the integration with Kendo UI.

"The Kendo UI integration is part of a larger effort called New UI which is planned to be released for 4.0. However, Kendo UI is only part of the equation.

The big picture is this:

1. Existing customers will be able to use both the New UI and the existing UI (We call it Classic UI). They will be able to run their applications without breakage in the Classic UI. In the New UI, their mileage may vary depending on the kind of customizations they have done.

2. The New UI uses Kendo UI as you mentioned but also Bootstrap V3. Bootstrap V3 is not compatible with V2, which is the version that is in use in Classic UI. That may affect customers in general and from what you are mentioning below it’s likely to affect this customer.

3. The New UI has a different structure and is responsive. It does not use (as much) tables, table cells, ect…. for example where we used to have some and
elements we now have Bootstrap row and columns.

4. We have tried to preserve some of the IDs as much as possible, but even when you can access the element by ID, you may not be able to apply the same logic to the element in New UI than in Classic UI. A good example is the time control (details below).

5. We are preserving custom header/footer and custom sidebar functionality in the sense that a customer will be able to customize New UI using similar techniques that they used in Classic UI (Using Jquery, JavaScript and CSS overrides).

6. We are improving how customers can override CSS rules. We have separated what rules we intend customers to override vs fixed ones.

7. We are adding some built-in themes. Some of the customizations may not work well in some themes (particularly when they hardcode colors).

All in all, we hope that we made the right compromises between bringing up new technologies, functionalities and a more modern UI while maintaining enough backward capabilities.
We hope that having the 2 UI mode will provide a nice migration path to the customers. Obviously, it would interesting to find out from them where there are difficulties and where we can smooth them. Please let us know.

Regards, Thierry".

Let me know if you need more information on this.

Thanks,
Gian
Posted by Thierry Ciot on 03-Jun-2015 12:56

The Kendo UI integration is part of a larger effort called New UI which is planned to be released for 4.0.  However, Kendo UI is only part of the equation.

The big picture is this:

  1. You will be able to use both the New UI and the existing UI (We call it Classic UI).  You will be able to run your applications without breakage in the Classic UI.  In the New UI, your mileage may vary depending on the kind of customizations you have done.  
  2. As an admin you will have a flag to turn new UI for admin users only so that they can evaluate how the application behaves under New UI without affecting non–admin users. When satisfied you will be able to turn new ui ON for all users.

  3. The New UI uses Kendo UI as you mentioned but also Bootstrap V3. Bootstrap V3 is not compatible with V2, which is the version that is in use in Classic UI.  That may affect you too.

  4. The New UI has a different structure and is responsive.  It does not use (as much) tables, table cells, ect….  for example where we used to have some <tr> and <td> elements we now have Bootstrap row and columns.  

  5. We have tried to preserve some of the IDs as much as possible, but even when you can access the element by ID, you may not be able to apply the same logic to the element in New UI than in Classic UI.  A good example is the time control where in new ui it is a single input but in classic ui it's 2 text inputs.

  6. We are preserving custom header/footer and custom sidebar functionality in the sense that you will be able to customize New UI using similar techniques that they used in Classic UI (Using Jquery, JavaScript and CSS overrides) but for all reasons listed here the actual content may not work well or not at all.

  7. We are improving how you can override CSS rules.  We have separated what rules we intend customers to override vs fixed ones.

  8. We are adding some built-in themes.  Some of the customizations may not work well in some themes (particularly with hardcoded colors).

  9. We are using font awesome.  This should help a great deal in terms of being able to customize the icon (size and colors for example) using CSS rules. You can check http://fortawesome.github.io/Font-Awesome/examples/ to get a feel of what you can do.

  10. We are adding custom Jquery events to facilitate and improve customization.  For examples,  rbs_sectionExpanded' or rbs_sectionCollapsed or rbs_ui_resized is raised when layout manager has finished resizing 

All in all, we hope that we made the right compromises between bringing up new technologies, functionalities and a more modern UI while maintaining enough backward capabilities.

We hope that having the 2 UI modes will provide a nice migration path for you  

Obviously, we are interested in finding out where there are difficulties and where we can smooth them.  Please let us know.

Regards,

Thierry Ciot.

Posted by romain.pennes@foederis.fr on 04-Jun-2015 05:13

Hello,

Thank you for your answers.

We are thrilled to hear about the idea of now having two UI modes (Classic UI vs New UI).

Most of our customers have admin users, and we would like to make the change from Classic to New UI customer by customer (which means having the admin users on the Classic UI as well for some time).

Will we be able to chose for a whole customer (admins and non-admins users) to be in Classic or New UI?

Also, we really like the choices you are making on the new UI to give up on the current HTML structure mainly composed of HTML tables and move towards a more modern web application.

All around this is great news for us,

Can't wait to try it.

Kind regards,

Romain Pennes.

Posted by Bill Wood on 04-Jun-2015 05:25
WRT:
  >>>> Will we be able to chose for a whole customer (admins and non-admins users) to be in Classic or New UI?

Yes -  the normal behavior is for all users to use the new UI.   The feature where only Admins can see the Kendo UI is a feature to allow testing prior to rolling over all users.   (Many people that have multiple Customer zones can also test and tweak the new UI in a non-public dev zone entirely and not affect other customer zones. When happy they can promote the application normally as a new version) 
Posted by Thierry Ciot on 04-Jun-2015 09:29

Thanks for the positive feedback.

>> Will we be able to chose for a whole customer (admins and non-admins users) to be in Classic or New UI?

Yes the New UI flags I was referring to above are at thetenant level only (Customer object)

In other words, it's not at an application level it's at the customer/tenant level.

Thierry.

Posted by Robert McDonald on 04-Jun-2015 13:39

Romain,

I'm glad to hear you are excited about the UI improvements we are making.  We feel that now is the time to make them and we are trying to minimize the disruption to our existing customers.   Since it is not feasible to maintain two UI paths forever, the switch we are adding will be removed and the new UI will be the only one that is available.  We are currently thinking that 6 mos. is a suitable time to allow our customers to make the changes that will be needed to ensure compatibility.  I know that you may have a unique situation, so If you have any questions or concerns about this timeframe, please feel free to reach out to me offline and we discuss.

Posted by Thierry Ciot on 05-Aug-2015 13:11

To avoid confusion when new release comes out, I just wanted to provide an update on this as we have changed how this is working based on various feedback:

We are giving customers more flexibility in migrating to the new ui.

Thierry.

Summary:

  1. Existing customers (including trials) and Master/Root customer: They stay on the old UI
  2. New customer signups post new release: Unconditionally on the New UI without an option to go back to the classic UI.
  3. ISV case:
  1. Existing stay on Classic UI
  2. New will be on New UI with an option to go back to Classic UI using preferences

Details:

Common options for Root & existing customers who stay on classic UI after the update

Setup > Administrative Setup > Preferences   shows up options to selectively enable New UI

  • Only for me (current admin user): Enables an admin to try out the New UI only for him without affecting other users in the customer/system.
  • For specific users (including admins and regular users): Enables an admin to enable the New UI for a number of specific users
  • For everyone: This option enables the New UI for the entire tenant: This should be chosen when it has been established that the application is working fine in New UI and that all users are good to use the New UI.
This thread is closed