Indigo Web Server plug-in architecture (alpha 1)

Posted on
Tue Aug 31, 2010 8:36 am
jay (support) offline
Site Admin
User avatar
Posts: 16776
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Indigo Web Server plug-in architecture (alpha 1)

That's not possible since those URLs aren't modified at runtime - they are static URLs as defined in the control page editor. Does going through prism while on your local network really add that much load time?

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Tue Aug 31, 2010 8:47 am
jay (support) offline
Site Admin
User avatar
Posts: 16776
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Indigo Web Server plug-in architecture (alpha 1)

BTW, it is a reasonable feature request, though, so I'll add it to the feature request list. :D

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Tue Aug 31, 2010 9:21 am
jay (support) offline
Site Admin
User avatar
Posts: 16776
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Indigo Web Server plug-in architecture (alpha 1)

Some more good news - if you put a relative URL in the text field in the control page editor, it works, with one caveat: it doesn't work in Indigo Touch. Touch doesn't know what to do with the relative path. We'll add that in our next update to Touch. If you are only using browsers, though, you should be good to go - just enter the relative path to your plugin (/weather/static/LWCWeb/index.html) in the URL field in the control page editor.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Tue Sep 07, 2010 8:31 am
travisc offline
User avatar
Posts: 346
Joined: Sep 07, 2010
Location: Toronto, Canada

Re: Indigo Web Server plug-in architecture (alpha 1)

Hi Guys,

I've been playing a little bit with this plug-in feature and I have a question. I'd like to create an iOS web app which offers an interface similar to Indigo Touch. There's a few reasons why:

One is to bypass the Bluetooth slowdown bug that Apple just doesn't seem to want to fix. This is brutal sometimes and Indigo Touch just crawls.
http://www.perceptiveautomation.com/userforum/viewtopic.php?f=13&t=5961&hilit=bluetooth

And the other is more of a personal preference. I've got a great interface based on iui that I used with my linux system before I started using Indigo. I'd like to port it over to Indigo so everyone can use it. I could easily port it using perl and Sean's Automogator, but that's probably more work than the average user would like to invest, so I'd like to try and use the Indigo plugin architecture.

My iphone interface was heavily based on ajax and did everything without reloading the page. I see this is the same with the default indigo web interface. I can see the browser does a get request to http://ip_address:8176/_getupdatedcontrols to get a list of the device changes. This request returns the full html of the page element that changed. It creates the html as per the _pageelem_response.xml file located in the template folder.

Now finally the question...
Can I also use the _getupdatedcontrols request to return updated html for my own _pageelem_response.xml file located in the plugins/template folder? Or will I have to duplicate all that functionality in my plugins reqhandler.py file?

Thanks,
Travis

Posted on
Tue Sep 07, 2010 9:36 am
matt (support) offline
Site Admin
User avatar
Posts: 20539
Joined: Jan 27, 2003
Location: Texas

Re: Indigo Web Server plug-in architecture (alpha 1)

Hi Travis,

travisc wrote:
Can I also use the _getupdatedcontrols request to return updated html for my own _pageelem_response.xml file located in the plugins/template folder? Or will I have to duplicate all that functionality in my plugins reqhandler.py file?

_getupdatedcontrols is hard coded to use the _pageelemlist_response.xml and _pageelem_response.xml Cheetah templates, which are then hard coded to use the Indigo table or graphical HTML. Since you want to use your own HTML, you'll need to duplicate the getupdatedcontrols functionality inside your plugin, which will then use copies of the Cheetah XML templates that point to your own HTML files. It should be pretty straightforward though -- mainly just copy/pasting the getupdatedcontrols function and making copies of the template files, then tweaking them to point to your own HTML files.

I would not recommend editing the original functions or template XML files, since those will get overwritten then next time you run the installer (if we have made any changes to the file).

Image

Posted on
Tue Sep 07, 2010 10:19 am
travisc offline
User avatar
Posts: 346
Joined: Sep 07, 2010
Location: Toronto, Canada

Re: Indigo Web Server plug-in architecture (alpha 1)

Hi Matt,

Ok great that's what I needed to know. Sounds simple enough. I'll get started tonight and get back if I have any questions.

Thanks!

Posted on
Fri Dec 10, 2010 2:09 pm
Perry The Cynic offline
Posts: 783
Joined: Apr 07, 2008

Re: Indigo Web Server plug-in architecture (alpha 1)

Will plug-ins written to these rules continue to be supported in Indigo 5, or will we be gently encouraged to rewrite to the new plug-in APIs? Will the new interface be so much better that we'll want to anyway? Or do you see the "old and new" ways coexisting indefinitely?

Cheers
-- perry

Posted on
Fri Dec 10, 2010 3:45 pm
jay (support) offline
Site Admin
User avatar
Posts: 16776
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Indigo Web Server plug-in architecture (alpha 1)

We're moving their physical location into a new Indigo plugin bundle that will be much more user friendly when it comes to installing additional functionality (plugins, scripts, images, etc). IWS Plugins will still continue to use the same basic directory structure, cherrypy and the cheetah template engine (we might upgrade those to newer versions). We haven't yet determined if we're going to require them to use the new python object model or whether we'll support the older-style object access as described by the current plugins.

So, bottom line - if your plugin doesn't rely heavily on access to Indigo objects, then the change (if any) will be small. An example of this would be the LWC Indigo Web Server Plugin. If we require switching to the new object model from the current access methods, it would only have to have one line changed. This is what the current plugin uses to update the variable value:

Code: Select all
cherrypy.server.indigoDb.VariableSetValue(cherrypy.server.indigoConn, "VariableName", "Value")


This is what it would look like using the new object model:

Code: Select all
indigo.variable.setValue(varReference, "Value")


Don't want to get into any details yet, but that gives you a sense of how things will change. If, however, you're extensively asking Indigo for data, then the changes might be more substantial. Still probably not huge, but more than just a line or two.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Fri Dec 10, 2010 4:30 pm
Perry The Cynic offline
Posts: 783
Joined: Apr 07, 2008

Re: Indigo Web Server plug-in architecture (alpha 1)

Thanks. That sounds workable. I'll doodle around a bit to get the rust off my Python skills. :-)

Cheers
-- perry

Posted on
Fri Dec 10, 2010 4:51 pm
jay (support) offline
Site Admin
User avatar
Posts: 16776
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Indigo Web Server plug-in architecture (alpha 1)

The Variable Plugin is pretty well documented in the reqhandler.py file but it probably is missing some of the built-in method definitions (and it's functionality isn't really useful in 4.x), so check out some of the others for a more complete picture of what else you can do in them. There was never any real documentation on IWS plugins - we're correcting that with an abundance of developer documentation for 5.0.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Who is online

Users browsing this forum: No registered users and 5 guests