> instead of simply being able to change the code, you need to find the exact hook or configuration to get the behavior you want.
I don't think that this is a bad thing. This is the purpose of a framework. To extend its functionality. If I wanted to re-write everything (or change the generated scaffolds) then I'd skip the framework and use libraries directly.
I'd like to point out the biggest problem with scaffolding: Let's suppose I use scaffolding to generate a scema / database table in phoenix, along with all the bells and whistles. I'm happy; instant code. I customize all the scaffolds as I like (i.e change html layouts, fix the schema/migration for fks, fix the queries, improve forms etc). I'm happy; everything works as I like. After 1 hour I notice understand that my table is missing a field. I'm sad. Now I've got two equally sad options:
* Delete everything that phoenix has generated for me, drop the schema, re-generate the scaffold (with the new field) and re-apply all my customizations or
* Add the field myself by adding a migration, adding it to the schema, fixing the tests, adding it to changesets, fixing the templates, fixing the queries and praying I haven't forgotten anything.
Now I'm very sad.
What would happen in that case (forgot a field in the database) in Django? Add the field to the model and re-run the migrations. That's it. Happy days!
> You can migrate (or not) at your convenience
Yes, I know that the views are still there but my understading is that they won't be generated anymore (so the steer is to not use them anymore, at least for new code). However, my main argument was that Django is better at holding your hand to produce acceptable code even if you are not experienced with the framework nor you have mentoring. The fact that now you have even more options (i.e you can use views if you want and think you need them) strengthens that argument.
If you need to change it, you would add it to the migration, schema, and then in the necessary templates. Some fields are private, read-only, etc. so you would change your templates accordingly. Some fields you want to change via a button press, others via a form, and so on. The whole point is that you can evolve the generated structure based on your needs.
> (i.e you can use views if you want and think you need them)
I was mostly speaking about existing applications. New applications have a clear path forward.
I don’t think this strengthens your argument the way you think. I _bet_ Django also has features that were used in the past and are no longer favored now, but still supported for backwards compatibility. This is in no way a phenomenon exclusive to Phoenix.
If your argument is that a configurable framework is easier than code gen for beginners, I agree. But that said, you don’t seem to be acknowledging the fundamental tradeoff which cuts both ways. Ultimately it depends on how close you want to stay to the paved path. I’ve built enough web products at this point that I’d rather have auth primitives than a configurable framework as the latter will be way more complicated than necessary to meet my needs.
For me it comes down to keeping business logic out of my framework. The logical extension of the framework + hooks model can be seen in something like Drupal. You can get amazing volumes of functionality launched quickly, but the UX is ERP-like in its rigidity. Obviously Django is not like this in the large, and the auth/admin stuff are much higher power-to-weight ratio than anything in Drupal, but it’s an interesting case study in looking at the implications of drawing different logical boundaries between framework and application.
I don't think that this is a bad thing. This is the purpose of a framework. To extend its functionality. If I wanted to re-write everything (or change the generated scaffolds) then I'd skip the framework and use libraries directly.
I'd like to point out the biggest problem with scaffolding: Let's suppose I use scaffolding to generate a scema / database table in phoenix, along with all the bells and whistles. I'm happy; instant code. I customize all the scaffolds as I like (i.e change html layouts, fix the schema/migration for fks, fix the queries, improve forms etc). I'm happy; everything works as I like. After 1 hour I notice understand that my table is missing a field. I'm sad. Now I've got two equally sad options:
* Delete everything that phoenix has generated for me, drop the schema, re-generate the scaffold (with the new field) and re-apply all my customizations or * Add the field myself by adding a migration, adding it to the schema, fixing the tests, adding it to changesets, fixing the templates, fixing the queries and praying I haven't forgotten anything.
Now I'm very sad.
What would happen in that case (forgot a field in the database) in Django? Add the field to the model and re-run the migrations. That's it. Happy days!
> You can migrate (or not) at your convenience
Yes, I know that the views are still there but my understading is that they won't be generated anymore (so the steer is to not use them anymore, at least for new code). However, my main argument was that Django is better at holding your hand to produce acceptable code even if you are not experienced with the framework nor you have mentoring. The fact that now you have even more options (i.e you can use views if you want and think you need them) strengthens that argument.