What is the status of this?
It seems like the latest version of LeptonX seem to lack the login link when in "mobile mode". It is not under the hamburger menu either.
If you (on a device that supports it) zoom out so you get the non mobile view, you can login and then if you return to the mobile view, you will se the account icon in the mobile nav menu.
It seems like the LeptonX Navbar has now been updated to replace that hideous large icon in the middle with the typical hamburger menu to the right which is a good improvement. But with only four icon spots available, please don't use one of them for Settings, which might be something that most users change perhaps once if even that. Please instead put that in the hamburger menu and instead lets us have the other spots for what is app specific.
If you login it is even worse, now 2 out of 5 icons are used for something that could be under the hamburger menu
From what I know, there is no way you can modify this either than downloading source code for LeptonX and customize it yourself?
Thanks.
On a side note, where can we track changes / roadmap for LeptonX?
Is the dynamic-env.json file even used for NON Docker setups?
From what I can see in environemnt.prod.ts, ABP relies on NGINX being setup und running and responding to /getEnvConfig but how would that happen unless you are using Docker (or configure nxinx manually). This however from what I can see is never mentioned in the docs nor the files nginx.conf or dynamic-env.json. There also now does not seem to be an option to not create support for Docker Compose so I imagine those files will always be there, along with this
remoteEnv: { url: '/getEnvConfig', mergeStrategy: 'deepmerge', },
Assuming the above is true, I think it should at least be clearly mentioned that the remoteEnv requires Docker/Nginx. Or I am wrong which would probably be better for everyone :)
The docker-compose.yml build paths seem to be wrong making the image build not working (unless you have built the images before). Problem seem to be that if you execute the run-docker script in the docker-compose folder (which I assume most would), it wont find the dockerfile.local files, or rather, the dockerfile.local files wont find what they need.
For it to work, you would need to change the build for relevant images from (for API) to something like this. This of course assumes that the release/publish folder already exist
build:
context: ../../
dockerfile: src/ImproWise.COIN.HttpApi.Host/Dockerfile.local
To
build:
context: ../../src/ImproWise.COIN.HttpApi.Host
dockerfile: Dockerfile.local
This problem is kind of masked if you run the build-images-locally script first as that would mean the images were already available, but I believe that this should still be changed so that the docker-compose can run on its own (at least assuming the publish folder is there but that is perhaps a more reasonable expectation).
Thanks.
It seems like the template creates the wrong path to DBMigrator Dockerfile.local in the YAML
coin-api: image: improwise/coin-api:latest container_name: coin-api hostname: coin-api build: context: ../../ dockerfile: src/ImproWise.COIN.HttpApi.Host/Dockerfile.local
db-migrator: image: improwise/coin-db-migrator:latest container_name: db-migrator build: context: ../../ dockerfile: src/COIN.DbMigrator/Dockerfile.local
It seems like the docker compose is setup to create and use a Redis image even when redis is in fact not used in the project. Might not be a problem locally but could be if you deploy to something like Azure and creates a Regis container thinking it is needed when it is not. Maybe this should at least be highlighted in some way as it is probably a good idea to include the redis image as well in the base setup.
On a side note, I was a bit surprised to learn that for new ABP 9 projects, redis does not seem to get installed or configured unless you add the Public Web site, is this true and if so, is that a change from previous or has it always been like that?
I think using a script is more convenient than using Visual Studio, but I'll take a look.
Yes, agreed, but with the "Docker" file being there, it would be good if it was setup for VS. Not sure if that file is actually ever used or just the Docker.local?
The Docker files (ie not Docker.local) are not recognized by Visual Studio, probably because they are not added to the project in the correct way. This means that the Docker functionality in Visual Studio isn't there for publishing etc. as to VS, there exist no Docker files. While you can of course to this yourself, I think it would be nice if it was setup correctly from start, not sure how much extra work it would mean though to get it working with Docker Compose etc.
