Implementing custom assets that look very different

Development
1

I want to add a custom asset that looks very different from the default FarmAssets. I want to exclude many of the default fields and add several custom fields. I saw that custom assets always extend FarmAssetType which includes a lot of default fields which I’m trying to exclude.

Any suggestions for how to achieve this, or is this a bad idea and I should avoid this?

1 Like
2

Hi @gmagnusson - can you list the fields you do not want to include? Each may have different considerations that I can shed some light on.

Generally speaking, though, you may be better off hiding certain fields than trying to exclude them entirely. It is possible to customize the display of the asset’s View and Edit tabs using configuration YML, which could achieve what you are looking for without modifying the defaults.

There are other options, but it may require a lot of detail to talk through them, so I’ll start with that. :slight_smile:

3

The fields I’m looking at now are:

  • Flags
  • Parents
  • ID tags

I might think of something else to tomorrow.

Their existence does not offend me, so maybe just toggling their visibility is exactly what I need. I didn’t realize that was an option.

My primary goal is to simplify the entry form so the intended use case for my asset is clearer for users that are new to FarmOS.

1 Like
4

Ah yea, those fields (Flags, Parents, and ID tags) are all core components and not easy to remove (possible, but may cause other headaches for you).

I think visually hiding the fields is the better way to go for your needs.

Another idea would be to build “Quick Forms” which are vastly simplified forms for data collection, which then save data to standard assets/logs, but the user doesn’t need to go that deep if they don’t want to.

Guide: Quick forms | farmOS

2 Likes
5

I was considering Quick Forms, and I really like that concept, but it does not feel right for this use-case.

What is the right way to hide these fields using a yml config? I’m poking around the documentation and source code but have not found it. Is this maybe a simple Drupal concept? (I don’t have much experience with Drupal development in general).

I created a custom module farm_oyster_lease.
In config/install/asset.type.oyster_lease.yml I have:

langcode: en
status: true
dependencies:
  enforced:
    module:
      - farm_oyster_lease
id: oyster_lease
label: Oyster Lease
description: ''
workflow: asset_default
new_revision: false
third_party_settings:
  farm_location:
    is_location: true
    is_fixed: true

Is this the config file you referred to, or is there a separate config file I can add to customize the view/edit form?

1 Like
6
  1. Enable the field_ui module (via /admin/modules or $ drush en field_ui)
  2. Navigate to Administration > Structure > Asset types
  3. In the “Operations” column, click the arrow drop down and select “Manage form display” or “Manage display”

“Manage form display” will show all fields, let you reorder them, hide them, modify the form widget that is used for each, etc etc - these all affect the form that is accessible from the asset’s “Edit” tab. “Manage display” will do the same, but for the way fields are displayed in the “View” tab.

When either of these pages are “Saved”, it will create a “configuration entity” (one for the form display for the given asset type, and one for the “view” display). These config entities can be exported to YML files and installed by your module.

One way to get this YML is to enable the “Configuration Management” module (eg: $ drush en config) and navigating to Administration > Configuration > Development > Configuration synchronization. Then click the “Export” tab, then the “Single item” tab. This allows you to export all the various configuration entities from the system as YML. The “Configuration type” dropdown will let you see all the types of config. The two configurations described above are “Entity form display” and “Entity view display” types.

Those two configuration types are great because they give you full control over the display of the entity form and view for each entity type. There are some disadvantages to using that config, however, which is why we actually DON’T include it in any of the farmOS core/contrib modules that we maintain. The main flaw of the config is that it changes depending on what modules are installed - eg: if a module adds a field to all asset types, then all of a sudden you need to update your config to include that. Since we (maintainers of farmOS and contrib modules) can’t know what modules are installed we can’t easily provide that config reliably. So we use other mechanisms. This is one of the more complicated areas of farmOS module development, for better or worse. If you plan to distribute your module to others, you may want to consider whether or not its worth including this config, or figuring out another approach.

1 Like
7

Thanks for the quick and detailed responses. I’ll give this a try and see how it goes.

1 Like