Manage Custom Buttons in UI

Post Reply
bkonia
User
Posts: 119

Manage Custom Buttons in UI

Post by bkonia »

Currently, we can create custom buttons in code using the ListAction class in the Page_Load event. We also have the ability to add custom HTML in the List_Options event, and of course, we can process the results of ListAction buttons in the Row_CustomAction event. This is all great, and very powerful, but when you have lots of custom buttons on many pages, it becomes an enormous amount of code, which is difficult to maintain. Since PHPMaker is a UI-based product, and since most applications require button operations beyond the simple Add/View/Edit/Delete, I'd like to propose that PHPMaker provide a button editor within the UI.

This button editor could be located in a new tab next to the Table tab. So you'd have the following tabs: Fields / Buttons / Table / Custom Code. The button editor UI would be similar to the Menu Editor:

  • Each row would represent a button.
  • A row would contain the following columns:
    • Button name (for referencing it in code)
    • Button text
    • Icon
    • Allow. This would include predefined functions like IsLoggedIn() and IsAdmin(). The user could also enter a custom function.
    • Method. The user could select POST, AJAX, Redirect, or Modal.
      • If the user selects POST, it would enable the Confirmation Message column.
      • If the user selects AJAX, it would enable the Success column.
      • if the user selects Redirect, he could enter a URL (relative or fully qualified) to redirect to when the button is clicked. The URL could include parameters in its query string with placeholder variables that would be replaced by values from the current row. For example, SomePage?id=%id would redirect to SomePage, passing the id of the current row in the query string. The redirect would occur without displaying the confirmation message.
      • If the user selects Modal, it would function the same as Redirect except instead of redirecting, it would open the URL in a modal.
    • Select. This would be either Single or Multiple and only relevant to POST or AJAX buttons. It would correspond to the ACTION_SINGLE and ACTION_MULTIPLE options in the ListAction class.
    • Success. The name of the JS callback function for AJAX buttons.
    • Confirmation Message
    • Action
      • For POST and AJAX buttons, the user would be able to enter the code that executes when the button is clicked. Thus, it would be analogous to the Row_CustomAction event.
      • For Redirect and Modal buttons, the user would enter the URL, including the optional query string with placeholders, as described above.
  • In addition to the columns listed above, there would be a second set of columns where you could specify on which page types the button should be displayed (Add / Edit / View / List / Preview / Grid)
  • Finally, we should be able to control the order in which buttons appear, by moving the rows up and down, and optionally move buttons into groups. Again, much of this could function like the menu editor, where you can move menu items around and group them

mobhar
User
Posts: 10296

Post by mobhar »

In my humble opinion, all of those requirements have already be handled by Row_CustomAction + Page_Load, and/or ListOptions_Load + ListOptions_Rendered + Row_CustomAction server events under List Page. You can even add your business-logic in that server events dynamically through that Code Editor.

I don't think using UI for that can implement our own business-logic dynamically. Imagine if you want to add your own business-logic from that UI. How? Then you still need to write the code from Code Editor section. So, why must create the similar feature that actually already existed?

The only thing that should be improved for ListAction class is to add a new param in order to handle input from end-users; which is usually handled via Modal Dialog. That is similar to your recommendation below:

bkonia wrote:

If the user selects Modal, it would function the same as Redirect except instead of redirecting, it would open the URL in a modal.

But this is actually not for input URL only. But, it can be anything (more than just URL), so that the value that derived from Modal dialog, can be passed again to the Row_CustomAction server event.

Just my two cents.


bkonia
User
Posts: 119

Post by bkonia »

mobhar wrote:

In my humble opinion, all of those requirements have already be handled by Row_CustomAction + Page_Load, and/or ListOptions_Load + ListOptions_Rendered + Row_CustomAction server events under List Page. You can even add your business-logic in that server events dynamically through that Code Editor.

I'm well aware of those functions and use them constantly. The problem is it's inconvenient to have to write code to add buttons. It would be much easier, more convenient and more organized to have a button editor in the UI. By your logic, the Menu Editor, Permissions Editor and various other PHPMaker UI tools shouldn't exist, since we can replace those UI components with manually written code. In fact, by your logic, PHPMaker itself should be a PHP framework, not a UI-based development tool, since all its UI functionality could be replaced with code.

I don't think using UI for that can implement our own business-logic dynamically. Imagine if you want to add your own business-logic from that UI. How? Then you still need to write the code from Code Editor section. So, why must create the similar feature that actually already existed?

I never suggested using the button editor UI for business logic. In fact, I specifically described its Action parameter as follows: For POST and AJAX buttons, the user would be able to enter the code that executes when the button is clicked. Thus it would be analogous to the Row_CustomAction event.

The purpose of the button editor would be to simplify and streamline the process of creating and managing buttons. Naturally, each button would be associated with either a URL (for redirect actions), or code (business logic) that would execute when the button is clicked. Besides making it easier to render the buttons, this approach has the advantage of keeping all the button settings in one place, rather than having to manually add code for each button in multiple events.

When PHPMaker was first released many years ago, it was a simple CRUD tool, mostly used to create data grids for internal use. Over the years it has grown into a full-fledged development tool which people like me use to develop commercial, consumer-facing web applications. Thus, features like custom buttons are no longer optional. Custom buttons are now a standard part of ANY web application. It's no longer enough to just have buttons for simple CRUD actions. We need to be able to create custom buttons as easily as we can create menu items.


Post Reply