[Proposal] Field types & column types naming

[tabacitu]

Priority: low low low

I think a very intuitive way to name the field and column type would have been using the column names used in Laravel migrations.

We need to keep the names we have now for backwards-compatibility, of course, but we could create these new fields, too, as aliases of existing fields.

PROs:

• easier to understand what each field type represents
• dead-simple to generate CRUDs from migrations (we would just place a field/column with the same name as in the migration), either as a setFromMigration() method (alongside setFromDb()) or to have the fields and columns written one-by-one; generating CRUDs from migrations should be simpler than from DB, because there's only one migration type;
• consistency in naming with other Laravel parts;

CONs:

• not a big fan of the names for migrations...

What do you guys think? Pasting the table with all the names below so it's easier.

Command	Description
$table->bigIncrements('id');	Incrementing ID (primary key) using a "UNSIGNED BIG INTEGER" equivalent.
$table->bigInteger('votes');	BIGINT equivalent for the database.
$table->binary('data');	BLOB equivalent for the database.
$table->boolean('confirmed');	BOOLEAN equivalent for the database.
$table->char('name', 4);	CHAR equivalent with a length.
$table->date('created_at');	DATE equivalent for the database.
$table->dateTime('created_at');	DATETIME equivalent for the database.
$table->dateTimeTz('created_at');	DATETIME (with timezone) equivalent for the database.
$table->decimal('amount', 5, 2);	DECIMAL equivalent with a precision and scale.
$table->double('column', 15, 8);	DOUBLE equivalent with precision, 15 digits in total and 8 after the decimal point.
$table->enum('choices', ['foo', 'bar']);	ENUM equivalent for the database.
$table->float('amount', 8, 2);	FLOAT equivalent for the database, 8 digits in total and 2 after the decimal point.
$table->increments('id');	Incrementing ID (primary key) using a "UNSIGNED INTEGER" equivalent.
$table->integer('votes');	INTEGER equivalent for the database.
$table->ipAddress('visitor');	IP address equivalent for the database.
$table->json('options');	JSON equivalent for the database.
$table->jsonb('options');	JSONB equivalent for the database.
$table->longText('description');	LONGTEXT equivalent for the database.
$table->macAddress('device');	MAC address equivalent for the database.
$table->mediumIncrements('id');	Incrementing ID (primary key) using a "UNSIGNED MEDIUM INTEGER" equivalent.
$table->mediumInteger('numbers');	MEDIUMINT equivalent for the database.
$table->mediumText('description');	MEDIUMTEXT equivalent for the database.
$table->morphs('taggable');	Adds unsigned INTEGER taggable_id and STRING taggable_type.
$table->nullableMorphs('taggable');	Nullable versions of the morphs() columns.
$table->nullableTimestamps();	Nullable versions of the timestamps() columns.
$table->rememberToken();	Adds remember_token as VARCHAR(100) NULL.
$table->smallIncrements('id');	Incrementing ID (primary key) using a "UNSIGNED SMALL INTEGER" equivalent.
$table->smallInteger('votes');	SMALLINT equivalent for the database.
$table->softDeletes();	Adds nullable deleted_at column for soft deletes.
$table->string('email');	VARCHAR equivalent column.
$table->string('name', 100);	VARCHAR equivalent with a length.
$table->text('description');	TEXT equivalent for the database.
$table->time('sunrise');	TIME equivalent for the database.
$table->timeTz('sunrise');	TIME (with timezone) equivalent for the database.
$table->tinyInteger('numbers');	TINYINT equivalent for the database.
$table->timestamp('added_on');	TIMESTAMP equivalent for the database.
$table->timestampTz('added_on');	TIMESTAMP (with timezone) equivalent for the database.
$table->timestamps();	Adds nullable created_at and updated_at columns.
$table->timestampsTz();	Adds nullable created_at and updated_at (with timezone) columns.
$table->unsignedBigInteger('votes');	Unsigned BIGINT equivalent for the database.
$table->unsignedInteger('votes');	Unsigned INT equivalent for the database.
$table->unsignedMediumInteger('votes');	Unsigned MEDIUMINT equivalent for the database.
$table->unsignedSmallInteger('votes');	Unsigned SMALLINT equivalent for the database.
$table->unsignedTinyInteger('votes');	Unsigned TINYINT equivalent for the database.
$table->uuid('id');	UUID equivalent for the database.

[MarcosBL]

My 2 cents: I understand and see the posibilities of having this name schema (for example for the numeric fields), and that would do a +1 to the feature

BUT I really think we have a MVC issue here, those names are great for database schemas, but not really enought for daily "presentation" of form fields, for example maybe you use a varchar text for storing an IP address, but a "addField" varchar for that would need a lot of custom attributes for it to validate. Same goes for an image cropper, that in the end is just a text field, but needs a lot of frontend customization.

So support for a setFromMigration would be nice as an adition, but I think the long term is having a lot of custom components; not a component per attribute of course, read-only, etc, but image croppers, master-detail views, markdown/wysiwyg editors, etc...

Please excuse my bad english :disappointed:

[AbbyJanke]

What @MarcosBL said. Those names are great for databases as those are the column types. But i think for the "addField" we should use what is closer to HTML's "input" types.

[tabacitu]

Thanks for the input, guys, you make a good point. Let's keep them in mind when we make new fields, but renaming them to fit this pattern... let's drop that like it's hot.

Cheers!