Problems with jqDropList and jqListBoxEx

[dcorsus]

When I try to build some pages using the JQuery controls, the two mentioned JQ controls give errors because they use a reference to Global.HomeSeerAPI.Pair like this

Public items As List(Of Global.HomeSeerAPI.Pair)

Can this be fixed or am I doing something wrong because now I can't use these 2 in HS4 native plugins.

Dirk

[dcorsus]

ah, it seems that HomeSeerApi.dll is present in the homeseer root directory and adding a reference to it works. Is this the correct way or should this definition be updated NOT to rely on HS3 definitions?

[jldubz]

You should not be using anything from the HomeSeerAPI.dll in your HS4 plugins. If you are using JQuery controls in an HS4 plugin, we cannot offer you any support, and some HS4 features may not work as expected. We will deprecate this API at some point, and you will no longer have access to it. This DLL is only there to provide backward compatibility support for HS3 plugins. Please do not use JQuery controls in your HS4 plugins.

[dcorsus]

@rjhdakota @jldubz

Given that all HS3 PIs are supposed to work under HS4, I'm not sure how you can state the you will not give any support to JQuery issues. I believe you are stuck with it, perhaps as long until HS5 shows up and there is NO MORE HS3 PI support. Perhaps I wasn't clear that I don't want to use/include HomeSeerAPI.dll either but there is a reference in the scheduler definitions that needs a simple fix.

Secondly, I can understand that going forward the preferred way is Bootstrap, but in that case at least provide minimally the same functions you supported in HS3 and preferably, have more to offer. Having all of us PI authors rewrite large portions of our code for NOTHING OR LESS is insane!

[rjhelmke]

Just be be clear, you of course can use JQuery, Bootstrap uses it and we do use it in HS4. However, we are not supporting the clsPageBuilder class in the HS4 UI. This class has a bunch of built in controls that are based on an older version of JQuery. HS4 uses Jquery 3.2 which does not work properly with the older JQuery. So you cannot use the pagbuilder jquery controls on a page that references the newer jquery. If you want to create some new controls based on jquery 3.2 you are welcome to and will continue to include jquery in the build. I assume this question comes from developers who want to use existing HS3 code with HS4. If not, then I strongly suggest you create html files for your feature pages and use the new templating.

[dcorsus]

Can you then at least provide the same functions to the PageFactory like a listbox, hints when you hove over... It would also be great if you could provide a function just to add html created by a PI into a page created through PageFactory something like InsertHTML (inString as String)

[dcorsus]

Clarification question: are we allowed to use scheduler in our imports? If yes, that where the reference to HomeSeerAPI is, and if we can use it, can you fix it.

[jldubz]

@dcorsus

You can. You have to use a liquid tag in your HTML page to call a method in your plugin and build the controls using PageFactory in the method and then return a string. This is demonstrated in part in the sample plugins in HSPI.GetTriggerOptionsHtml()

There are select lists and input boxes for you to use in the JUI.Views namespace https://github.com/HomeSeer/Plugin-SDK/tree/master/Jui/Views

---

Clarification question: are we allowed to use scheduler in our imports? If yes, that where the reference to HomeSeerAPI is, and if we can use it, can you fix it.

No. You should not be using Scheduler in your plugin unless you absolutely need to be using old class definitions. I have been rewriting the Z-Wave plugin and have not had any need to include Scheduler or HomeSeerAPI and am having no problems processing all of the existing data and performing conversions and upgrades as necessary.

[dcorsus]

I use the liquid tag but I was more thinking about say a settings page where you may want to have some (non-dynamic) information added, perhaps some text or a paragraph of something.

So no Scheduler huh, how do I do a listboxex?

[dcorsus]

How do I use hints when I hover my mouse over it, not used anymore in the "Mobile First" design philosophy?

[jldubz]

I use the liquid tag but I was more thinking about say a settings page where you may want to have some (non-dynamic) information added, perhaps some text or a paragraph of something.

I do not understand why static content cannot be placed right into the HTML page directly. Why is this not an option for you?

As far as settings, you should be using the standardized JUI page framework to ensure that basic configuration (NOT FIRST TIME SETUP) is accessible to all users no matter the client they are using. The entirety of the built-in settings component is built on JUI. You can see an example of this in the sample plugin https://github.com/HomeSeer/Sample-Plugin-VB/blob/master/HSPI.vb#L86

Again I will point you to the JUI views namespace to look at the available controls you can use. A "listbox" is a window style control and doesn't have a direct equal in web design, but you can create a radio select group or checkbox select group which does exactly the same thing. These can be created using JUI with the ESelectListType.RadioList style for a SelectList or by creating a ViewGroup that includes a bunch of ToggleViews with their style type set to EToggleType.Checkbox

How do I use hints when I hover my mouse over it, not used anymore in the "Mobile First" design philosophy?

If you are asking for this functionality through JUI, this is something on the roadmap for the future, but you are already able to do this using HTML. When it comes to feature pages, you have to choose between using JUI and not getting all of the bells and whistles available to web dev or coding in HTML and having more flexibility with what you are able to do. JUI was never designed to be as robust as or act as a replacement for clsPageBuilder.

[dcorsus]

I guess I didn't grasp the concept of the "first time setup" when I used your example to create a settings page (without html file), purely using pagefactory functions. It is those really easy to make pages that I'm referring to, I want to keep it simple. clsBuilder WAS EASY(ier)! Unless you can point to a simple drag/drop full integrated tool for creating screens, at this point I feel I went back 15 years, changing something, copy/paste from other examples to see what it would do; rinse and repeat. In HS2 I could use visual studio to create great aspx pages, dragging/dropping and connecting events to code, where did that simplicity go?

I hear what you are saying but I need to point out that some of the objectives that the HS team has been advocating why to go to HS4 become very fuzzy, especially when you re-read your previous post.

a/ the SDK is supposed to make it EASIER for developers, so now re-read you post through the eyes of an amateur programmer .... easier? b/ the UI is supposed to make it more ergonomically, not just mobile first. You've seen the very angry reaction of the first batch of PI authors wrt why complex config pages need to follow this proposed new UI concept, why spend all the effort to end up with LESS ergonomically usable screens, and all of this has nothing to do with bootstrap, jui, jquery or whatever it is called, they are a means to an end.

So my humble recommendation is that you continue to add simple but powerful functions to the SDK so amateur developers will find it easy and make sure the UI serves the user not the form of mobile-first.

[jldubz]

So my humble recommendation is that you continue to add simple but powerful functions to the SDK so amateur developers will find it easy and make sure the UI serves the user not the form of mobile-first.

And everyone on the development team here at HomeSeer agrees. You have to understand though that the robustness you are asking for does not appear over night. clsPageBuilder was built over a span of years to get to where it is today. This SDK is open-sourced so that we can accelerate the development of these simple and powerful convenience functions that you and many others are asking for. I personally have so many I want to write up and know will make everyone's lives easier, but there are other priorities right now that involve the core functionality and the stability of the new platform.

The UI is not designed to be "mobile first" and it never has been. It is being designed to fit modern, responsive, web design standards which are built so that the UI works on mobile, tablet, and desktop environments using a design once, run anywhere principle. We have built the plugin SDK so that you can take advantage of this with minimal effort and required education on the topic. Our market studies show the new UI direction is more intuitive and comfortable for new users. Albeit, a little bit limited in functionality in places for some of our power users, but that can be remedied in time as we continue to develop this SDK using your feedback.