I'm fairly new to nod-red oder nodejs in generel. But I think with time I got a decent understanding.
At the moment I'm using node-red-dashboard to give my home automation a nice touch and easy controlling interface.
All my devices communicate via MQTT and I organize my rooms (for example) with different tabs in node-red.
Maybe it's just a missunderstanding of mine, but how do I use the same mqtt-connection (or db connection, etc.) throughout different tabs? I've configured a new one for each tab and can see in the log, that individual connections are made for each tab.
The connection from another tab is not shown inside the nodes on another tab.
Maybe you can point me in the right direction.
Cheers,
Patrik
In the mqtt-broker configuration node's edit dialog, there is a select box where you can pick the 'scope' of the node. It defaults to the tab you're currently on, but if you change that to 'global', the config node will be available on all tabs.
Related
I'm generating networks and importing them into Cytoscape using cyREST.
I have a lot of extra information available about each node, more than can be fit into node labels. I would like the user to be able to click on a node and bring up a detail panel with this additional info. Is there any feature of Cytoscape, or an existing plugin that can do that?
There is no easy way from within CyREST to do that, although you could encode that information in a single text column and then use the 'tooltip' visual property to provide a way for a user to get the information on a mouseover. Beyond that, you would need to provide an app to integrate with your CyREST application. Several apps do exactly what you are describing (e.g. look at StringApp for an example)
-- scooter
I need a help to communicate from my container single-spa to loaded angular app ( child ). when user click on parent app ( spa-container ) option, that should communicated to child application to change the mode.
it will not happen very frequently. But not able to find a way to communicate from container to loaded angular application.
there is a detail given by spa itself : spa-communication detail but not clear and there is no detailed steps. any one help me?
I'm one of the maintainers of single-spa.
We tend to be light on our opinions in the documentation about how to implement communication between modules because there are a lot of ways to implement it and each comes with pros/cons. In the situation you described it sounds like you might want to explore option #3 from the link you posted.
Custom Browser events
In the parent you fire custom events on the window. API on MDN.
Quick example
// in the parent (usually called the single-spa config or root-config in the documentation)
const event = new CustomEvent("myEvent", {favoriteMovie: 'StarWars'})
window.dispatchEvent(event)
// in the child (or registeredApplication)
window.addEventListener("myEvent", myEventHandlingFunction)
function myEventHandlingFunction(e) {...}
That should at least get you started, there are other options for communication as well and this particular approach isn't going to be the best solution in every situation.
It's also worth noting that customEvents don't work in IE11 unless you include a polyfill.
I have been extensively using a custom protocol on all our internal apps to open any type of document (CAD, CAM, PDF, etc.), to open File Explorer and select a specific file, and to run other applications.
Years ago I defined one myprotocol protocol that executes C:\Windows\System32\wscript.exe passing the name of my VBScript and whatever argument each request has. The first argument passed to the script describe the type of action (OpenDocument, ShowFileInFileExplorer, ExportBOM, etc.), the following arguments are passed to the action.
Everything worked well until last year, when wscript.exe stopped working (see here for details). I fixed that problem by copying it to wscript2.exe. Creating a copy is now a step in the standard configuration of all our computers and using wscript2.exe is now the official configuration of our custom protocol. (Our anti-virus customer support couldn't find anything that interacts with wscript.exe).
Today, after building a new computer, we found out that:
Firefox doesn't see wscript2.exe. If I click on a custom protocol link, then click on the browse button and open the folder, I only see a small subset of .exe files, which includes wscript.exe, but doesn't include wscript2.exe (I don't know how recent this problem is because I don't personally use FireFox).
Firefox sees wscript.exe, but it still doesn't work (same behavior as described in my previous post linked above)
Chrome works with wscript2.exe, but now it always asks for confirmation. According to this article this seems to be the new approach, and things could change again soon. Clicking on a confirmation box every time is a big no-no with my users. This would slow down many workflows that require quickly clicking hundreds of links on a page and, for example, look at a CAD application zooming to one geometry in a large drawing.
I already fixed one problem last year, I am dealing with another one now, and reading that article scares me and makes me think that more problems will arise soon.
So here is the question: is there an alternative to using custom protocols?
I am not working on a web app for public consumption. My custom protocol requires the VBScript file, the applications that the script uses and tons of network shared folders. They are only used in our internal network and the computers that use them are manually configured.
First of all, that's super risky even if it's on internal network only. Unless computers/users/browsers are locked out of internet, it is possible that someone guesses or finds out your protocol's name, sends link to someone in your company and causes a lot of trouble (possibly loss too).
Anyway...
Since you are controlling software on all of the computers, you could add a mini-server on every machine, listening to localhost only, that simply calls your script. Then define host like secret.myprotocol to point to that server, e.g., localhost:1234.
Just to lessen potential problems a bit, local server would use HTTPS only, with proper certificate, HSTS and HPKP set to a very long time (since you control software, you can refresh those when needed). The last two, just in case someone tries to setup the same domain and, for whatever reason, host override doesn't work and user ends up calling a hostile server.
So, links would have to change from myprotocol://whatever to https://secret.myprotocol/whatever.
It does introduce new attack surface ("mini-server"), but should be easy enough to implement, to minimize size of that surface :). "Mini-server" does not even have to be real www server, a simple script that can listen on socket and call wscript.exe would do (unless you need to pass more info to it).
Real server has more code that can have bugs in it, but also allows to add more things, for example a "pass through" page, that shows info "Opening document X in 3 seconds..." and a "cancel" button.
It could also require session login of some kind (just to be sure it's user who requests action, and not something else).
The title of this blog post says it all: Browser Architecture: Web-to-App Communication Overview.
It describes a list of Web-to-App Communication techniques and links to dedicated posts for some of them.
The first in the list is Application Protocols, which I have been using for years already, and it started to crumble in the last year or so (hence my question).
The fifth is Local Web Server, which is the one described by ahwayakchih.
UPDATE (this update follows the update on the blog post above mentioned)
Apparently I wasn't the only one thinking that this change in behavior was a regression, so a workaround has been issued: the old behavior (showing a checkbox that allows to remember the answer) can be restored by adding these keys to the registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge]
"ExternalProtocolDialogShowAlwaysOpenCheckbox"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"ExternalProtocolDialogShowAlwaysOpenCheckbox"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Chromium]
"ExternalProtocolDialogShowAlwaysOpenCheckbox"=dword:00000001
I am using TabBar in my application where I need to get Input in first tab and show
output based on some calculation on other tab.
I am able to get input in first tab but when I click on second tab, my state is lost. I am not sure if I have to make it a Stateful widget at root level.
I am relatively new in Mobile App. Can someone help me out here?
EDIT:
Now I am able to achieve what I said above, but when I am trying to access the list of items from first tab, it throws null exception in second tab?
I solved the above problem using AutomaticKeepAliveClientMixin as described in the answer below.
I think what you may be after is AutomaticKeepAliveClientMixin. I always add that to my screen widgets within TabBarView. This way when a user enters data into fields in one tab and navigates to other tabs and back the data is still there as you would expect.
Then when the user performs an action like "save" I deal with state management (BLoC etc).
You may want to use architecture for managing and sharing states. There are many approaches to manage state:
InheritedWidget to pass app state down the widget hierarchy
Scoped model library to hold app state and notify Widgets of Updates
Redux library to manage app state and update Widgets
Business Logic Components (BLoC)
Check out this article. Check this GitHub repository with different architecture examples
I'm a bit confused whether or not I should make the links on my website that point externally target="_blank". Does this practice negatively affect the usability of your site (i.e. breaking the "back button trail")? Is it commonly found annoying by most users? Is it acceptable in some situations but not others?
I want to make an enjoyable user experience for all of my sites and would hate to do something that annoys my users. What is your experience/advice on the matter?
Most people will say to leave it out, all for very good reasons.
Most people will not tell you this: watch how different people browse using their computer. Sit down for an hour with an average user: a teacher, a piano player, a retired Vet, a stay-at-home mother, or a mechanic. Watch how people who are disabled browse.
You will discover that you should not:
Open new windows (it is highly confusing)
Have menus disappear immediately after leaving them (requires fine motor control)
Use excessive numbers of links on a page (also confusing)
Provide too many features and options
Use Flash animation
Be overly clever
You will discover that you should:
Be clear and concise
Be simple
Keep the user on the same page
Avoid frustrating the end user at any cost
Create an extremely responsive website
And much more.
I've read plenty of usability documentation suggesting that end users resent being forced to open a link in a new window. I tend to agree, if I want a new window I will right click and select whether I want the same window, new tab, or new window.
However, the marketing types believe that opening an external link in a new window will keep the end user on your site because they will eventually close the new window and wind up back on your site.
EDIT: Best information I've read on this subject is in Steve Krug's book "Don't Make Me Think" (website).
MHO: just link it. If I want to open the link in a new window, I can do it myself.
Leave the target attribute out and let your users decide if they want to open the link in a new window. If you want to warn the user that the link will take them away from your site, you can implement a page that makes it clear (US Government sites do this for instance).
I agree that as a user, I prefer to have the choice as to whether or not I open a link in a new window. Unfortunately, many users don't realize that they have that choice, and will lose your website when they click a link to an external site. I tend to err on the side of caution and make external links open in new windows, but it depends on your audience, really.
Here is a nice write up for not opening links in a new window/tab from Smashing Magazine. Essentially, it is better to give users control over link behavior than to decide for them.
Usability guru (?) Jakob Nielsen suggests not opening new browser windows (It's 10 years old though).
Quote:
Opening up new browser windows is like
a vacuum cleaner sales person who
starts a visit by emptying an ash tray
on the customer's carpet. Don't
pollute my screen with any more
windows, thanks (particularly since
current operating systems have
miserable window management). If I
want a new window, I will open it
myself!
Designers open new browser windows on
the theory that it keeps users on
their site. But even disregarding the
user-hostile message implied in taking
over the user's machine, the strategy
is self-defeating since it disables
the Back button which is the normal
way users return to previous sites.
Users often don't notice that a new
window has opened, especially if they
are using a small monitor where the
windows are maximized to fill up the
screen. So a user who tries to return
to the origin will be confused by a
grayed out Back button.
And, every rule has an exception: He suggests document like PDF or DOC that are opened in the browser should be opened in new windows, to avoid confusion.
It's worth mentioning that target isn't valid in XHTML anyway.
I think it depends on the situation. For a simple website with just a few links like about us, contact, services etc., I will not open new window. It is easy for the user to know which page they are at and which page they have just looked at. For a site that has a listing summary page which links to hundreds or even thousands individual listing page. I would prefer to open new window for each listing. It allows the users to compare service/price.... on each opened page. Plus the user doesn't have to click the "back" button to return to the summary page and wait for the same page to load again.
It depends, typically for links to additional content on your site, I would not use the _blank. Anytime I link to off-site content I use the _blank to keep a page open for my site. That way when the user is done on the external site they see my site again.
With modern browsers this usually opens a new tab. I expect this behavior, but usually I control click to get a new tab/window when I want to keep my place.
That being said, for a web application, I'd always leave the target attribute off so the user can decide to open a new window or not.
What people hate is opening links in a new window and not knowing that it's coming. For each external link, go ahead and use target="_blank", but add an icon that suggests you're opening a new window. Wikipedia's double square icon is a good example of this, so you can just grab that from them and capitalize on the literacy that users already have there.
What's great about a 'new window' icon is that users then have the option of opening in a new tab instead, which isn't so obtrusive. I'd also say that many of those vehemently arguing against your proposed approach are looking at it strictly from an aesthetic/usability standpoint, and not in terms of business requirements or the functionality of your own application.
If you think that you or your users stand to gain from keeping users on your site and opening external links in a new window, you get to make the final call on that. Just be respectful about it.
You need to consider what users are doing in your window, when deciding how links should behave. If I could potentially lose a lot of work by navigating to another page, then I might want links to open in new windows, or give me an option to cancel.
For example, if I'm composing a message in Gmail, most of the links show a confirmation dialog, so I don't accidentally lose my work. And the links on top, which go to other applications like Calendar, open in new windows. I think this is a good example to follow.