-
Notifications
You must be signed in to change notification settings - Fork 105
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
Missed 'servers' in 'full example' section #30
Comments
Thanks for noticing this and shame on me; the issue is fixed now. |
@artemkonev
|
Hi, @hongzhidao , |
This object is subject to possible change in the future, so we'll keep it this way. |
@artemkonev |
Thanks, @hongzhidao, I'll consider adding this to my roadmap for the future. |
Hi, @artemkonev @VBart
BTW, does the official UNIT plan to support the dashboard? |
Dashboard is a good idea and Unit control API suits well here. However there are no plans to create one right now. Are you going to open source your dashboard? It would be nice to see, and we can mention it in the docs or in a blog post. |
|
Yes. Soon will be released. Thanks for your suggestion. |
Hi. @VBart @artemkonev There are some questions I faced.
I'm not sure if it's right to calculate the
a. CORS
It's easy to use Note that this server does not have any application environment, I tested it in my local server. This is based on |
Looks good!
Probably just an overview. I'm not sure that multiple screen/pages are needed right now. Everything can be showed and edited on just one page without switching (which can distract).
You shouldn't stick to JSON structure of the API. It's just an internal detail. UI can have completely different organisation, if it suits better.
There are also problems with copy'n'paste from editors. Sometimes it may corrupt the certificate somehow. I'd suggest to implement ability for file uploading and drag'n'drop as well.
That's because the UI and Unit API are served from different hosts. Do you think that will be a common case?
I agree. What authorization methods do you think Unit should support out of the box?
Is it a problem to handle this error? I think "requesting every bit" for the "pass" option - isn't a good way to handle it. Also this doesn't work with PHP targets. And you also lose atomicity. Parts of config may be changed by other software or users between your requests. It's better to request the full JSON from /config/ and then parse it and extract different parts.
That violates the REST principles that we try to stick.
The core part is the JS. Everything else is just a way how it can be served and it would be nice, if nginx will be not needed at all in the future. And it's not needed right now if you're using web UI locally for development for example. Also one more note, unrelated to the above. It seems currently it's not possible to add listeners and routes, or routes and apps or just multiple routes at the same time. Each time when adding something, you have to click "Submit" and apply changes, which can result in inconsistent state of the configuration. You have to collect all the changes made by user until he decide to apply them. |
This inspired me. On the client-side, there is only one JS object stored.
It's better to support both ways.
I'm not sure. I prefer to keep Unit API unchanged and put
I guess in real-world this dash will be deployed in the local network (I mean the
OK. Please take a look at the first try. hongzhidao/nginx-unit-dashboard.
The following are my thoughts.
Other.
|
Hi.
It seems the
servers
was missed.The text was updated successfully, but these errors were encountered: