Announcement

Collapse
No announcement yet.

I miss the old PageBuilder stuff

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #61
    Originally posted by rjh View Post
    Are you doing a JUI status page or a feature page? The intent was that the sample plugin would have everything you need to you don't have to jump through hoops. If we are missing something I want to get it updated.
    I'm building a feature page. The sample plugin doesn't give me any examples of how to do this:

    Originally posted by shill View Post
    I've got a guided setup process and need some of the info from a previous step before I can populate a list to choose from in a subsequent step; how do I dynamically change the contents? I can't just put the PluginFunction tag in there because it fires on load...
    I've made slow, slow progress at the expense of an entire weekend(!!!) at trying to figure this out, and I finally got it to work by:

    1. Creating a SelectListView in code after the postback is fired
    2. Properly trimming the output with stuff like this:

    RegularExpressions.Regex.Replace(juiSelect.ToHtml.Replace("" "", "'").Replace(Environment.NewLine, ""), "\>\s*\<", "><").Replace("""", """")

    Should I not be using Jui controls on feature pages? (when I tried to just use a select control, it didn't render, so clearly there were some classes or other items missing)

    Shouldn't the Jui controls "ToHtml" function produce something I can use with "divtoupdate"? (which, btw, isn't a thing anymore, it's the default behavior, but listing it as a "page command" earlier also sent me down a rabbit hole of wasted time).

    In general, how should we be dynamically rendering guided process feature pages?

    The example pages show the use of a jQuery Ajax call, but it appears we need to use AjaxPost if we want to have the page commands handled automatically. How do we handle errors in that case?

    Comment


      #62
      I personally have not used the stepper yet, but JL has a few times so I asked him to chime in.


      Originally posted by shill View Post

      I'm building a feature page. The sample plugin doesn't give me any examples of how to do this:



      I've made slow, slow progress at the expense of an entire weekend(!!!) at trying to figure this out, and I finally got it to work by:

      1. Creating a SelectListView in code after the postback is fired
      2. Properly trimming the output with stuff like this:

      RegularExpressions.Regex.Replace(juiSelect.ToHtml.Replace("" "", "'").Replace(Environment.NewLine, ""), "\>\s*\<", "><").Replace("""", """")

      Should I not be using Jui controls on feature pages? (when I tried to just use a select control, it didn't render, so clearly there were some classes or other items missing)

      Shouldn't the Jui controls "ToHtml" function produce something I can use with "divtoupdate"? (which, btw, isn't a thing anymore, it's the default behavior, but listing it as a "page command" earlier also sent me down a rabbit hole of wasted time).

      In general, how should we be dynamically rendering guided process feature pages?
      website | buy now | support | youtube

      Comment


        #63
        shill

        I've been working on trying to standardize the use of steppers in some way, maybe even add them into the JUI package for easy use through code, but it is proving to be rather time consuming to ensure proper flexibility for you. I have generalized what I have been doing for the Z-Wave plugin as much as possible and wrote up a little help article to walk you through how to cleanly implement a step-by-step process for users:
        https://docs.homeseer.com/display/HSPI/Process+Steppers

        The sample plugins demonstrate everything that you are asking for here. The https://github.com/HomeSeer/Sample-P...d-process.html page includes all of the necessary HTML, and you can find all of the code to handle relevant communications handling in the PostBackProc method of HSPI https://github.com/HomeSeer/Sample-Plugin-VB/blob/master/HSPI.vb#L223

        I highly recommend you also read through the MDBootstrap documentation as some of the components require initialization using javascript before they will be rendered correctly. For example, select lists must all be initialized with
        Code:
         $('.mdb-select').materialSelect();
        See https://mdbootstrap.com/docs/jquery/forms/select/

        We cannot guarantee any functionality using the old AjaxPost function and, although might point you to it for reference, cannot offer support in its use or behavior. As demonstrated in the documentation, you should be implementing your own AJAX handlers to work with your HTML feature pages the way you need it to. You can use whatever data format you are most comfortable with like JSON. w3schools has some great articles that cover everything you need to know to get your page working the way you want it to.

        https://www.w3schools.com/js/js_json_intro.asp
        https://www.w3schools.com/js/js_ajax_intro.asp

        If you want any more standardization or a closer experience to the old PageBuilder stuff, you will have to wait until something is implemented in JUI, or, if you can't wait, you can help contribute to this development effort by participating on the Plugin SDK GitHub page, committing code, and submitting pull requests etc.
        - JL West
        HomeSeer Software Engineer
        sigpic

        Comment


          #64
          So this is even more frustrating to hear.

          According to Rich, AjaxPost is "the key" (and I'd never heard of it, so it made sense it must be something new). But according to you, it's "old" and "not supported".

          Originally posted by rjh View Post
          The key is the AjaxPost call as it includes your plugin name and page. If your calendar code includes the Ajax call, adjust it as below. Note that this call works the same as it did in HS3 and you can also return HTML that updates divs.

          Code:
          AjaxPost(data,"HomeSeerSamplePlugin/sample-blank.html");
          When I look at the Chromecast "manage-hubs" page, it uses AjaxPost, but "add-hub" uses $.ajax. None of the samples show ANY examples of dynamically updating anything more than a simple text string, and why would I reinvent the wheel if the logic of AjaxPost already handles the page commands, which has been a big part of the discussion in this thread, but apparently is no longer a viable, supported method?

          So you can see why this has been confusing, and from the 5 pages of discussion, it's clearly not just me. (And considering a number of plugin developers might have picked up programming skills specifically for writing the plugin they needed for themselves, I do feel for them on this learning curve; I've been doing this for 29 years and have at least some experience in all the languages required to get this done and it's a challenge for me to put it all in context.
          Last edited by shill; January 9, 2020, 04:03 PM. Reason: I can't do math, apparently.

          Comment


            #65
            Let me clarify, we are not going to ensure that our AjaxPost will work with your plugin in the future. We reserve the right to make changes to it. If you like what it does, you can simply copy it and change the name. Then you can do what you want with it. Note that its VERY simple, it just calls $.ajax and parses the response as an array of commands. I would create my own function so I can add any command I want in any format that I like. The one we have handles a simple string return or an array of commands that do things like update a div. The source is in the page_command.js file, its a small function.

            Originally posted by shill View Post
            So this is even more frustrating to hear.

            According to Rich, AjaxPost is "the key" (and I'd never heard of it, so it made sense it must be something new). But according to you, it's "old" and "not supported".



            When I look at the Chromecast "manage-hubs" page, it uses AjaxPost, but "add-hub" uses $.ajax. None of the samples show ANY examples of dynamically updating anything more than a simple text string, and why would I reinvent the wheel if the logic of AjaxPost already handles the page commands, which has been a big part of the discussion in this thread, but apparently is no longer a viable, supported method?

            So you can see why this has been confusing, and from the 5 pages of discussion, it's clearly not just me. (And considering a number of plugin developers might have picked up programming skills specifically for writing the plugin they needed for themselves, I do feel for them on this learning curve; I've been doing this for 26 years and have at least some experience in all the languages required to get this done and it's a challenge for me to put it all in context.
            website | buy now | support | youtube

            Comment


              #66
              Originally posted by rjh View Post
              Let me clarify, we are not going to ensure that our AjaxPost will work with your plugin in the future. We reserve the right to make changes to it. If you like what it does, you can simply copy it and change the name. Then you can do what you want with it. Note that its VERY simple, it just calls $.ajax and parses the response as an array of commands. I would create my own function so I can add any command I want in any format that I like. The one we have handles a simple string return or an array of commands that do things like update a div. The source is in the page_command.js file, its a small function.
              Thanks. And I do appreciate the extra clarification, the steppers article, etc. It's just a LOT to take in, and to be quite honest, communication from HST isn't coming across as "we know this is a lot", it comes across as "come on guys, this is simple - why don't you just RTFM?". (I know, gross paraphrasing, but it sums it up pretty well.)

              The key that I'm taking away from this is "do it yourself", and "you better know JavaScript if you want to do anything useful in a plugin page". That last part is the biggest surprise I suspect.

              Comment


                #67
                The original idea here was that we would allow the pages to be generic web pages and to us this opens up a ton of flexibility for the developer. The old page builder stuff was non-standard, a bit buggy, and just a nightmare to maintain. Why re-invent the wheel here? The net is loaded with sample code that you can use and there are a ton of docs.

                Now I can see that many of you might not be web developers so this may not be something you want to even deal with, I get that.

                We have discussed maybe creating some kind of framework to assist but we are bit overloaded at the moment. It would be ideal if some of you maybe started something in Github that we can all add to.

                I am happy to answer any questions and assist as much as I can.

                Note that I started using Pinegrow to create bootstrap pages when we started this project and that was a big help. The HS pages in the html folder can be an excellent source of code snippets for HTML and javascript.

                Originally posted by shill View Post

                Thanks. And I do appreciate the extra clarification, the steppers article, etc. It's just a LOT to take in, and to be quite honest, communication from HST isn't coming across as "we know this is a lot", it comes across as "come on guys, this is simple - why don't you just RTFM?". (I know, gross paraphrasing, but it sums it up pretty well.)

                The key that I'm taking away from this is "do it yourself", and "you better know JavaScript if you want to do anything useful in a plugin page". That last part is the biggest surprise I suspect.
                website | buy now | support | youtube

                Comment


                  #68
                  Originally posted by shill View Post
                  "you better know JavaScript if you want to do anything useful in a plugin page". That last part is the biggest surprise I suspect.
                  +1

                  Comment


                    #69
                    Originally posted by shill View Post
                    When I look at the Chromecast "manage-hubs" page, it uses AjaxPost, but "add-hub" uses $.ajax
                    shill where did you find that (Chromecast)?

                    Comment


                      #70
                      You only need to know how post a form and we give you the code for most of the code you need. I have some generic functions in the included HTML files that simply post everything from any form. After the post you can simply refresh the page so you don't need to even return anything. I really don't feel that this is much. We give you all the code you need in the current pages.

                      But if you are stuck on something, just post and I will do my best to help.

                      website | buy now | support | youtube

                      Comment


                        #71
                        Originally posted by rjh View Post
                        We have discussed maybe creating some kind of framework to assist but we are bit overloaded at the moment
                        May be you get some vacation or PhD student to do that?

                        Comment


                          #72
                          I highly recommend you also read through the MDBootstrap documentation as some of the components require initialization using javascript before they will be rendered correctly. For example, select lists must all be initialized with
                          I understand the document.ready event as being the trigger for materialSelect() when the page is originally built. What event is raised following an Ajax postback response for the case where a select view is being replaced by an updated select view in the specified div? Is there an event that is raised when a div is updated?

                          Comment


                            #73
                            Originally posted by alexbk66 View Post

                            May be you get some vacation or PhD student to do that?
                            I agree with alexbk66 here. This should not be our problem. All the necessary tools/frameworks/documentation should be provided for the developers. I have the feeling we need to spent way too much time on this. The time vs revenue was not really high, but this the step to HS4 makes it even lower :-(

                            Comment


                              #74
                              Originally posted by kriz83 View Post
                              I agree with alexbk66 here. This should not be our problem. All the necessary tools/frameworks/documentation should be provided for the developers. I have the feeling we need to spent way too much time on this. The time vs revenue was not really high, but this the step to HS4 makes it even lower :-(
                              The idea of HS4 SDK was to make our life easier. But it turns out to be opposite. I created pretty solid framework for HS3 plugins, but now it's a waste and I have to start again.

                              Comment


                                #75
                                I get the frsutration on this thread. HS4 sounded like an incremental update but it's not. It's a total rewrite of the UI which impacts every bit of the product including our plugins.

                                To the end user, sure it's a new interface. To the devs, a steep learning curve...

                                ​​​​​​I agree with the strategy to abstract the code from the the HTML. I also agree with the approach to use published standards, for example bootstrap, which I'd never heard of before getting involved with HS4 (I am not a pro dev).

                                For me, it's an old dog learning new tricks. Luckily I revel in the weeds so it's all just exciting. I do get the pain though.

                                ​​

                                Comment

                                Working...
                                X