HTTPRequest Plugin - v0.1.0

[Boolean263]

Hi all! I've started fiddling around with writing EventGhost plugins to try and give back to the wonderful community that's made EventGhost such an awesome tool.

My first plugin is HTTPRequest. It's a fairly straightforward wrapper around Python's requests library to allow you to spawn HTTP requests as EventGhost actions. It's my hope that it will be useful to others. It's also to help me learn the conventions of plugin writing, so I'd appreciate any constructive feedback you have.

Version 0.1.0 - 2017-08-18

• The format of eg.result has changed! Now it's just the requests.Response directly.
• Switched from httplib to requests. The API and configuration haven't changed (much), but the result format has as noted above.
• Expands EventGhost variables in the "host:port" and "uri" fields. Can optionally also do so in the "body" field.

Disclaimer: I've only really used it with HEAD requests so far. (I created this plugin to send a dummy request to my NAS drive to wake it up from its sleep mode.)

Source code and full documentation: Boolean263/EventGhost-HTTPRequest on GitHub

Releases: will be attached to this forum post.

[Luca Brasi]

Hi,
thanks for sharing!
I managed to get notifications to telegram bots with your plugin in a couple of minutes. Great!
I noticed two things while checking it out. The plugin will not work if I copy it into a script. Don't know what is going wrong here. And I noticed that I can't bring in eg.globals into the plugin. They will not work when the action is run. Normally globals will get into the config fields like this: {eg.result}

[kgschlosser]

Releases: will be attached to this forum post once the forum lets me.

I believe the magic number of posts you have to have before you can do this is 10. I would have to go and look. but that that is how the forum basis who can and cannot add files to attachments. (keeps the bots from posting naughty things)

[Boolean263]

Hi,
thanks for sharing!
I managed to get notifications to telegram bots with your plugin in a couple of minutes. Great!
I noticed two things while checking it out. The plugin will not work if I copy it into a script. Don't know what is going wrong here. And I noticed that I can't bring in eg.globals into the plugin. They will not work when the action is run. Normally globals will get into the config fields like this: {eg.result}

Hi there! Sorry about the delay in replying, I didn't get an email that anyone had responded to my post.

I'm glad you're enjoying the plugin so far! It's good that you were able to incorporate it so seamlessly into your telegram stuff. That's the sort of thing it was made for.

What do you mean by "copy it into a script"? The plugin is meant to stand on its own. If it's installed properly, you should be able to make a call such as

Code: Select all

foo=eg.plugins.HTTPRequest.sendRequest(u'example.com', uri=u'/')

from a "Python Script" action to get the results of the request in the variable foo. If you need something more complex than that, then you should probably be calling httplib directly.

To rephrase my question, what is it that you're trying to do? Maybe I can help you figure it out.

Thanks again!

[Boolean263]

I believe the magic number of posts you have to have before you can do this is 10. I would have to go and look. but that that is how the forum basis who can and cannot add files to attachments. (keeps the bots from posting naughty things)

That makes sense. It also means people have to find and read the source code, which means they know I'm not giving them a plugin that does something nasty instead.

Is distributing plugins via the forum the preferred way to go? Or would it be better if I made a "releases" directory in the github project?

[Luca Brasi]

What do you mean by "copy it into a script"?

I tried to rightclick "copy as python" because I was to lazy to figure out how to do it directly in the script
I wanted to pass text variables to the plugin which didn't work. So I made it work with requests now. It doesn't work with ssl though at the moment. Some error message appears. I had to switch it off.

[kgschlosser]

Is distributing plugins via the forum the preferred way to go? Or would it be better if I made a "releases" directory in the github project?

at the moment the preferred thing to do is to make a topic in the plugins section of the forum with the name of the plugin file. the first post in the topic would have the name and version as well as a description of the plugin. followed by how to use it and any examples if you wanted to give. it is also good practice to list any changes that have been made between versions. something like the following

Added: Action to parse json responses
Changed: How SSL information is handled
Fixed: Reporting of errors

the .egplugin format is the best to attach to the post. this can be created very easily if you are using EG 0.5. in the add plugins dialog if you right click on a plugin you will be given the option to export the plugin. this will package the plugin into the .egplugin file.

If for some reason you are forced to make a change to the plugin that will break backwards compatibility with a previous version it is always nice to inform the user of this change in very large very bright colored text this way it will not get missed. It actually is more for the benefit of you then the user this way you don't get support requests because they didn't read before they installed. by making it so obvious and something they can't miss.

[kgschlosser]

I wanted to pass text variables to the plugin which didn't work.

He/She is a new plugin developer. I do not think they know about parsing variable names. this has to be set up in the code. you will usually see a check box in the action to disable the parsing if it is supported. if there is no way to disable it then there is a pretty good chance that there is no parsing available.



I will explain how to use this feature for the plugin developer.

there is a mechanism in place that if used in conjunction with a text entry control in the action configuration dialog will allow the user to enter {some_variable_name} in the control and when the action gets run it will locate that variable and return the contents of the variable instead of a literal string that was entered.

The largest use of it is if you want to take the data that is returned from one action and enter it into another action. any data that is returned from an action gets put into a variable called eg.result. so if your action was to follow the user would be able to enter {eg.result} in the field and have the checkbox to parse checked and the information will automatically get transferred.

how this is used is you will commonly add an extra control to the configuration dialog that is a check box to enable or disable the parsing of the text. The code below is pseudo code for an example of how to set it up.

Code: Select all

class SomeAction(eg.ActionBase):
    def __call__(self, param1, parse_param1=False):
        if parse_param1:
            param1 = eg.ParseString(param1)
        
    def Configure(self, param1='', parse_param1=False):
        panel = eg.ConfigPanel()
        param_st = panel.StaticText('Param 1')
        param_ctrl = panel.TextCtrl(param1)
        parse_st = panel.StaticText('Parse Param 1')
        parse_ctrl = wx.CheckBox(panel, -1, '')
        parse_ctrl.SetValue(parse_param1)

        param_sizer = wx.BoxSizer(wx.HORIZONTAL)
        param_sizer.Add(param_st, 0, wx.EXPAND | wx.ALL, 5)
        param_sizer.Add(param_ctrl, 0, wx.EXPAND | wx.ALL, 5)

        parse_sizer = wx.BoxSizer(wx.HORIZONTAL)
        parse_sizer.Add(parse_st, 0, wx.EXPAND | wx.ALL, 5)
        parse_sizer.Add(parse_ctrl, 0, wx.EXPAND | wx.ALL, 5)

       panel.sizer.Add(param_sizer, 0, wx.EXPAND)
       panel.sizer.Add(parse_sizer, 0, wx.EXPAND)

       while panel.Affirmed():
           panel.SetResult(
               param_ctrl.GetValue(),
               parse_ctrl.GetValue()
           )

[Boolean263]

at the moment the preferred thing to do is to make a topic in the plugins section of the forum with the name of the plugin file. the first post in the topic would have the name and version as well as a description of the plugin. followed by how to use it and any examples if you wanted to give. it is also good practice to list any changes that have been made between versions. ...

Cool, thank you for the tips! I figured it was something like that, but second-guessed myself when I couldn't attach the file to the post. 4 more posts and I'll be able to fulfill my destiny! Or something.

I will explain how to use this feature for the plugin developer.

Thanks for that explanation as well! That's a handy feature that I didn't know existed. I'll definitely need to add that.

And finally, thanks for the PM to educate me on the Requests library! That looks really handy. I'll almost certainly be using that in future versions of my plugin. It'll change the eg.result format, but like you said, big red text will make sure everyone knows.

I appreciate all your help and feedback! And thanks again to Luca for taking a chance on my plugin. (:

[kgschlosser]

@Boolean263

If there is anything you need to know send me a PM if ya want. If i do not have the answer I will work with ya to find one. I am very diligent at doing that. I am pretty sure others will agree with me on that. EG has a whole lot of really cool things built into it that simplify the whole plugin creation process.

I have been working on a plugin creator script for python well it creates the basic outline of the plugin i have been adding onto it from time to time i might have a poke at it again and add some more to it.

[Boolean263]

Thank you both again for your feedback! I've used it to create a new version of the plugin, up now on github.

I've added automatic variable expansion to the "host:port" and "uri" fields, and added an option to do the same in the "body" field. I've also switched it over to use requests, which is easier to use.

The format of eg.result has changed. Now it's a requests.Response object, not a custom dict. The nice thing about that is one can just use {eg.result.text} to get the response content. (Though I guess one should technically check if {eg.result.status_code} is 200 first.)

Let me know if this version is any better, and/or if there's more I can do to improve it.

[kgschlosser]

this is a little FYI for those that didn't know this can be done. but you can pass python expressions between the curly braces {} so if you want to do a simple check for a status code to determine what to actually use for the text then the correct way when passing the variable into another text control would be

Code: Select all

{eg.result.text if eg.result.status_code == 200 else ""}

[kgschlosser]

@Boolean263

you like requests better?? it is far easier to use. take most of the legwork out of http in python

[Boolean263]

you like requests better?? it is far easier to use. take most of the legwork out of http in python

I do! It's pretty handy. Better than what I came up with for httplib. (: Indirectly, it's also taught me to look for what other useful modules come with EventGhost, so I can leverage them in my plugins.

[kgschlosser]

well if you install python 2.7 x32 on your system. and install the PyCharm IDE you will have the ability to browse the available python packages. if you find one you could possibly use then install it into python 2.7. then go into the installation folder for python 2.7 \Lib\site-packages folder. this is where the packages get installed to. you can copy the package and paste it into you plugin folder. now it will be packaged in the .egplugin file. this way if you need a specific package for your plugin to work you can ship it with your plugin.