I’m not thinking about changing a lot of things in the Mandarin generators. I’ll add some features to the routing macros to make them more customizable. But that’s probably it.
Regarding forage, I’m very happy with the current API. But I need to add tests.
I still need to add support for many to many relationships somehow, between Forage and Mandarin.
But mainly my goal is to make things stable and well tested so that ir can be used in production. Mandarin is very safe to use, because it’s mostly generators which generate “normal” phoenix files. Forage is another question, because it’s the project that actually runs some code at runtime…
It would be great to add an extended description of what this package really does and what’s the use case. I’m a bit confused. My use case is that I have an existing DB and I’m putting a read-only RESTful API on top of that (with a little help from phx.gen), but I would also like to have an admin interface for modifying the data. Can mandarin help me? I find myself doing hacks so that the generators do not overwrite my schemas and controllers. I might go with creating a separate schemas for mandarin but this requires manual work.
I’m not fully convinced about the idea of using generators. If I need any customization, then I can’t re-generate the admin panel. What if mandarin gets a major bump and I’d like to update my admin panel? Seems that I would have to start from scratch.
If I understand this right, mandarin “just” provides better generators then the default Phoenix ones, right? If so, why do I have to include it in prod build? Or maybe that’s not the case?
There are some places that require renaming from the old name: for example here and here.
There seems to be a bug when a schema references another one and the id can be null. Not sure if all the relationship are preloaded, but in this line I get an error: nil.id/0 is undefined.
I’ve tried torch as well - the advantage of mandarin is that it works with Ecto 3.x.
I wanted to give ExAdmin a try, but it’s not actively maintained and the deps are pinned to pretty old versions.
In the end, I think I would find it more useful to have a library of generic views/templates/helpers so that I can throw any struct at it and render it (possibly exclude some fields) or build something in just a few lines of code.
Back to Mandarin after a long time away… What is the recomended approach to testing a package that mostly dumps text int your Phoenix apps? I don’t think unit tests or integration tests are easy to write for this… Do people just use manual testing? Anyone has any tips?
I need to document forage better and expand on the readme to explain what the generated files do. It’s true that the generator dump a lot of code into your files, but doing that instead of using clever macros makes everything much more extendable (even if a little harder to understand due to the raw volume of code you have to read).
Thank you very much to share this app. I would like to use it but when I run mix ecto.reset, I have the following error:
10:05:25.545 [info] create table employees
** (Postgrex.Error) ERROR 42804 (datatype_mismatch) foreign key constraint "employees_department_id_fkey" cannot be implemented
Key columns "department_id" and "id" are of incompatible types: uuid and bigint.
For 10. on your Readme, I used
mix mandarin.gen.html Admin Function functions name:string --binary-id
since 10 is the same than 8
Add a `Function` resource: `mix mandarin.gen.html Admin Department departments name:string`
To make it work, I had to delete the file bureaucrat.ex in deps/mandarin/mix/ (I also deleted the folder bureaucrat) because I had the following error:
== Compilation error in file lib/mix/mandarin.ex ==
** (CompileError) lib/mix/mandarin.ex:1: cannot define module Mix.Mandarin because it is currently being defined in lib/mix/bureaucrat.ex:1
(stdlib) erl_eval.erl:680: :erl_eval.do_apply/6
**could not compile dependency :mandarin, "mix compile" failed. You can recompile this dependency with "mix deps.compile mandarin", update it with "mix deps.update mandarin" or clean it with "mix deps.clean mandarin"**
Hey, when do you estimate that this project will be production ready?
I think there is a bigger demand than we think when it comes to admin generators, especially a standardized one that becomes a default recommendation. This would be positive in many ways, as in several contributors, more knowledge spread around and of course a great product.
I wish I could contribute but I don’t think I have the elixir experience yet to be useful, but I will fork and test the repo when I get home from work and try it out for feedback purposes
I don’t really have an estimate for when I have the docs done. Mandarin is mostly ready for production use now. You can create an admin backend using the generators and pretty much never touch the code (except to add authentication and authorization to the pipeline and things will work. The problem is that appart from the “tutorial” in the example repo there are no docs.
But even worse is the fact that Forage doesn’t have 100% code coverage yet, and docs are also pretty sparse. There’s also the problem that Forage web doesn’t yet support disjunction (the OR operator) in queries yet, but that’s not very important in my opinion.
Hm… I don’t know if thde demand for admin generators is that big. I think people would prefer an admin framework that worked based on DSLs and macros. Mandarin has been criticised for generating a lot of code, when much of it could be simplified with. The controller could be something like this:
defmodule App.Admin.Employee do
use Mandarin.Controller, resource: App.Admin.Employee
# with defoverridable functions, of course
It’s actually much more work to generate a file with the controller code. I’m doing it because I believe it’s easier to customize if all code is explicit (and you’ll want to customize it sooner or later…).
Just trying to get some feedback Has anyone actually tried this admin interface in a user-facing app, even if for an internal app? I’ve been quiet for a long time but I’m thinking on going back to it (I have a project that might use this)
Nope, not yet, never got around it. Was wondering between this one and a few others but I am more open to try some of what they call them today “low-code” or “no-code” internal app builders (of which there’s a lot).