Jump to content
Esther E.

IC5: UI Extensions, Part II

In our  previous blog entry, we described the UI Extension and its overall capabilities. Today, we'll talk about how to use this new tool to extend content forms and menus.

Could contain: Page, Text, Business Card, Paper

Form Fields

A popular modification request is to add fields to a Content Item, such as a Topic. All UI extension classes contain the following methods:

  • formElements
    Returns an array of form elements that will be added to the form.

Note: Unlike other UI Extension methods, the first parameter of this method can be NULL, if you are creating a new item.

  • formPostSave
    Allows you to process the fields that were added in the formElements method. Note that this method is triggered after the form is saved.

Note: This method has the same function as the ContentListener method onCreateOrEdit, but we've added support for it here as well to avoid the creation of multiple classes, and to keep related code in the same place.

 

Element Placement

By default, all new form elements will be inserted at the end of the form. However, there are times that you may want to insert your fields into specific positions within the form. You can use the new FormAbstract::setPosition() method to specify where the element should be inserted.

Let's look at an example.

public function formElements( ?BaseItem $item, ?Model $container ): array
{
	return [
		'my_new_field' => new Text( 'my_new_field', $item ? $item->new_field : null, true )
	];
}

The above will append a Text field called "my_new_field" at the end of the Topic form.

public function formElements( ?BaseItem $item, ?Model $container ): array
{
	$field = new Text( 'my_new_field', null, true );
	return [
		'my_new_field' => $field->setPosition( Topic::$formLangPrefix . 'tags', Topic::$formLangPrefix . 'mainTab' )
	];
}

By using setPosition, I've placed the new field after the "tags" field, on the main tab in the form.

 

Extending Content Menus

In this blog entry, we introduced our new approach to building menus. With UI extensions, you can add your own items to Item and Comment menus using the following methods:

  • UIItem::menuItems
  • UIComment::menuItems

We will discuss nodes and their menus in a future blog entry.

 

Extending Item Badges

Similarly, you can use the UI Extension to add badges to the item header. The UIItem::badges() method returns an array of badges and/or icons to be appended to the badge display.

 

This concludes our discussion of UI Extension features related to Items and Comments. In our next blog entry, we'll discuss Nodes and what additional methods are available.

Comments

Recommended Comments

So you're saying the initial topic could for a particular forum have a dedicated field for data entry? Would this field data be displayed inline in the body of the post after submission or would the field value be a column for the forum (searchable/filterable)

IE Technical forum you could have a discrete field "Software Version"  - will the field also include all the various types of fields like in other areas: 

Could contain: Page, Text

Link to comment
Share on other sites

22 minutes ago, Ocean West said:

So you're saying the initial topic could for a particular forum have a dedicated field for data entry? Would this field data be displayed inline in the body of the post after submission or would the field value be a column for the forum (searchable/filterable)

IE Technical forum you could have a discrete field "Software Version"  - will the field also include all the various types of fields like in other areas: 

Could contain: Page, Text

This is for 3rd party devs to allow their applications to add fields to content forms. This is not something in the ACP.

Link to comment
Share on other sites

51 minutes ago, Aeomin said:

If formPostSave triggers after form is saved. How would custom validation work?

Custom validation is typically declared as a callback when you add the field to the form. How are you currently doing this?

Link to comment
Share on other sites

4 hours ago, Esther E. said:

Custom validation is typically declared as a callback when you add the field to the form. How are you currently doing this?

For simple ones, using existing functionality. Some complicated ones I just use hook. The goal for validation is not saving data if it didn't pass. So callback isn't ideal as it is not some kind event chain I can break.

Link to comment
Share on other sites

1 hour ago, Aeomin said:

For simple ones, using existing functionality. Some complicated ones I just use hook. The goal for validation is not saving data if it didn't pass. So callback isn't ideal as it is not some kind event chain I can break.

That's what the callback is for, specifically for validation so that it won't save. Sorry, I'm not really following what it is that you need to do that isn't already doable.

If your code is adding the field, then you have full control over the callback that is used. There's no chain.

Link to comment
Share on other sites

36 minutes ago, Esther E. said:

That's what the callback is for, specifically for validation so that it won't save. Sorry, I'm not really following what it is that you need to do that isn't already doable.

If your code is adding the field, then you have full control over the callback that is used. There's no chain.

ah I miss read it. I thought it was going to be along the line with listener.

Link to comment
Share on other sites

@Esther E. Based on what I'm reading, we won't be able to alter the current form fields, only add to them. Is that correct?

 

For example, I have a custom modification that hides some fields when submitting a new Event in the Calendar app. The client wanted those fields to be available only to certain groups. That's not something we can do using UI Extensions, and we can't overload anymore any methods. 👀

 

Another example in the marketplace is this one instead:

It has the option to require the user to enter a message, and even require a minimum number of characters.

With UI Extensions I won't be able to update this modification since I can't access the existent form fields.

Edited by teraßyte
Link to comment
Share on other sites

47 minutes ago, teraßyte said:

@Esther E. Based on what I'm reading, we won't be able to alter the current form fields, only add to them. Is that correct?

That's correct, but you can always use Javascript and/or CSS to hide fields.

Link to comment
Share on other sites

5 minutes ago, Esther E. said:

That's correct, but you can always use Javascript and/or CSS to hide fields.

Unfortunately, that won't work:

  • CSS is not an option because it would hide the fields for everyone, not just specific members/groups. In any case, they'd still be there in the output.
  • Javascript would allow hiding the fields based on some extra JS variables in the output. Again, they'd still be there in the output.

Since the fields are in the output, a person with some knowledge or a bot can still fill them in without trouble. Removing them completely, and not processing the values when the form is saved were requirements for the modification. (Don't ask me why it needs to be like that, but that was the request.)

 

Being able to easily extend all forms and adding new fields to them is nice, but being unable to alter the other fields is a severe limitation.

Link to comment
Share on other sites

1 hour ago, teraßyte said:

Javascript would allow hiding the fields based on some extra JS variables in the output. Again, they'd still be there in the output.

In theory you could remove them entirely using JS, not just hide them. 

1 hour ago, teraßyte said:

Being able to easily extend all forms and adding new fields to them is nice, but being unable to alter the other fields is a severe limitation.

As Matt has said in previous entries, there are things that you will no longer be able to do, and that's intentional. 

You will be able to do most things, but not all. 

That said, I can think of some ways to do what you're asking, but let's wait until we have all the dev tools announced and then I'm happy to discuss. I don't want to start giving suggestions about things I can't show you in full. 

Link to comment
Share on other sites

11 minutes ago, Esther E. said:

In theory you could remove them entirely using JS, not just hide them. 

Well, yes, I could remove them. But if the field is missing, the value is not submitted, and the backend might throw errors about some array keys not existing or some other problem. That's why I think it's important to be able to alter the form fields directly rather than relying on CSS/JS "tricks" to hide or remove them.

 

13 minutes ago, Esther E. said:

As Matt has said in previous entries, there are things that you will no longer be able to do, and that's intentional. 

You will be able to do most things, but not all. 

That said, I can think of some ways to do what you're asking, but let's wait until we have all the dev tools announced and then I'm happy to discuss. I don't want to start giving suggestions about things I can't show you in full. 

Yeah, I've been really holding back on saying too much for now. (Really! I had to say it twice.) But, from what I've read, my problem is that I can't do most of the things I need. 🤷‍♂️

Fingers crossed. 🤞

Link to comment
Share on other sites

11 minutes ago, teraßyte said:

Yeah, I've been really holding back on saying too much for now. (Really! I had to say it twice.) But, from what I've read, my problem is that I can't do most of the things I need

For what it's worth, I too have a few clients who have modified the event form (I can think of 3 right off the bat, but there are probably more). And I already have a pretty good idea how I'll handle that.

Hope that helps a little? 

Link to comment
Share on other sites

3 hours ago, teraßyte said:

CSS is not an option because it would hide the fields for everyone, not just specific members/groups

You can still run the group check and include the necessary js/css files, or set the JS variables only when it’s needed.

Link to comment
Share on other sites

8 hours ago, Daniel F said:

You can still run the group check and include the necessary js/css files, or set the JS variables only when it’s needed.

I was thinking more of hiding the fields by adding some rules to custom.css, but yeah, I guess including a separate CSS file would work, too.

 

That wasn't the point though:

12 hours ago, teraßyte said:

Since the fields are in the output, a person with some knowledge or a bot can still fill them in without trouble. Removing them completely, and not processing the values when the form is saved were requirements for the modification. (Don't ask me why it needs to be like that, but that was the request.)

10 hours ago, teraßyte said:

Well, yes, I could remove them. But if the field is missing, the value is not submitted, and the backend might throw errors about some array keys not existing or some other problem. That's why I think it's important to be able to alter the form fields directly rather than relying on CSS/JS "tricks" to hide or remove them.

 

Link to comment
Share on other sites


×
×
  • Create New...