Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code completion for Items, Things etc. #7

Closed
ThomDietrich opened this issue Jun 19, 2017 · 4 comments
Closed

Code completion for Items, Things etc. #7

ThomDietrich opened this issue Jun 19, 2017 · 4 comments

Comments

@ThomDietrich
Copy link
Member

ThomDietrich commented Jun 19, 2017

Looking at the gifs it seems like Items are not yet known by the IDE. That's probably a feature intended. Are you going to add them by scanning the items files? A connection to the REST API would be an interesting approach (to also cover PaperUI generated Items). The connection to the REST API would also be needed for #8

@kubawolanin
Copy link
Collaborator

There's an entry in my notes that I wanted to move here :)

Separate view for all items (leverage REST API?)

Eclipse SmartHome Designer has a section with all items listed in a column.

We could create a new vscode view for it when working on openHAB files:
https://code.visualstudio.com/docs/extensionAPI/extension-points#_contributesviews

@kaikreuzer
Copy link
Member

Eclipse SmartHome Designer has a section with all items listed in a column.

It is not "all" items, it is only items defined in item files - and this is a major issue now that we also have items stored in the database (which were created through Paper UI).
So the only clean way to get the full item list is indeed to use the REST API.

Now I wonder: If we need a connection to the REST API of the runtime for this feature and for #8 and maybe others - wouldn't it make sense to make this the ONLY connection, meaning: not having to rely on a samba share for file access? This is a path that I started in the discussion of eclipse-archived/smarthome#1402.

Would VS Code be able to deal with such "REST-provided resources" or does it require them to be on the local file system (sorry if this goes off-topic, feel free to move it to a new issue)?

@ThomDietrich
Copy link
Member Author

ThomDietrich commented Jun 19, 2017

Exactly my point. We should try to include the REST API as much as possible 👍

The REST API as the ONLY connection sounds interesting and should be considered in the long run to include e.g. rules created via the Experimental Rule Engine and whatever else might arise. More important in the moment is probably to get a first working and complete (tbd) feature set into the VS Code editor (and not repeat the errors of the Paper UI and the whole database vs files fiasco...).

Would VS Code be able to deal with such "REST-provided resources" or does it require them to be on the local file system (sorry if this goes off-topic, feel free to move it to a new issue)?

Far from off topic. This question needs to be answered. Without a connection to some openHAB interface the editor will not be fun in the long run. Also see #8 and #9

@MHerbst
Copy link

MHerbst commented Jun 19, 2017

wouldn't it make sense to make this the ONLY connection, meaning: not having to rely on a samba share for file access?

@kaikreuzer I absolutely agree. If everything (items, rules, sitemaps and even log information #9) would be accessible via REST API we could also access these information remotely via myopenhab.

kubawolanin added a commit to kubawolanin/openhab-vscode that referenced this issue Jul 7, 2017
Added "Copy State" context menu for Items.
Removed ongoing "Find References" feature.
General code cleanup.
Added Item code completions - Closes openhab#7

Signed-off-by: Kuba Wolanin <hi@kubawolanin.com> (github: kubawolanin)
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants