Extending actions

[live627]

Motivation

The goal is to reduce reliance on static properties for actions requiring special behavior.

---

Interface Definition

Below is the interface for defining action-specific behavior (ActionInterface). Method names probably could be improved:

interface ActionInterface
{
	/**
	 * Checks if this action allows guest access even when guest access is disabled.
	 *
	 * @return bool True if access is allowed, false otherwise.
	 */
	public function isRestrictedGuestAccessAllowed(): bool;

	/**
	 * Determines if this action can be logged in the online activity log.
	 *
	 * @return bool True if the action can be logged, false otherwise.
	 */
	public function canBeLogged(): bool;

	/**
	 * Identifies whether this action qualifies as a "simple action."
	 *
	 * @return bool True if the action is simple, false otherwise.
	 */
	public function isSimpleAction(): bool;

	/**
	 * Checks whether this action requires XML mode to be enabled.
	 *
	 * @return bool True if XML mode is required, false otherwise.
	 */
	public function isXmlAction(): bool;

	// Additional methods can be added here as needed.
}

Deprecations

1. integrate_pre_log_stats (modifying Forum::$unlogged_actions)

   • Deprecated: Modifying global $unlogged_actions via hooks.
   • Replacement: Implement ActionInterface::canBeLogged() to manage logging at the action level.

2. integrate_guest_actions (modifying Forum::$guest_access_actions)

   • Deprecated: Adding guest-access actions via hooks.
   • Replacement: Use ActionInterface::isRestrictedGuestAccessAllowed() for guest access control.

3. integrate_simple_actions (modifying $simpleActions, $simpleAreas, $simpleSubActions)

   • Deprecated: Managing "simple actions" dynamically through hooks and global arrays.
   • Replacement: Implement ActionInterface::isSimpleAction() for explicit control.

4. integrate_simple_actions (modifying $extraParams, $xmlActions)

   • Deprecated: Using hooks to flag XML actions or manage extra parameters.
   • Replacement: Use ActionInterface::isXmlAction() for defining XML requirements.

Updates to integrate_actions

• Current Behavior: String-based method references in the $actions array will continue to work as they currently do.
• New Feature: Actions can now specify class references, such as Actions\SomeClass::class, if the class implements the ActionInterface.

This addition provides a smooth transition to the new approach while maintaining compatibility with existing logic.

Backward Compatibility Impact

No backward compatibility issues are expected here. The old logic based on hooks and global properties will remain functional. Developers can incrementally adopt the new interface without requiring immediate changes to legacy code.

Request for Comments

Please share your thoughts or additional suggestions.

Question

Should we add a method for default action selection in the admin panel? This method would allow an action to specify itself as the default option for related settings in the admin panel.

[jdarwood007]

I would change isXmlAction to something like returnType and define a few constants

const RETURN_TYPE_HTTP = 0;
const RETURN_TYPE_XML = 1;
const RETURN_TYPE_JSON = 2;

This would allow us to define that we have multiple types that can be easily modified.

[Sesquipedalian]

I like what I'm seeing here!

[live627]

These actions cannot use the new approach because they are simple callbacks that piggyback off other actions. any reason that they do not use their own objects? The only reason I can think of is that they are easter eggs and therefore require hunting around.

[live627]

I would change isXmlAction to something like returnType and define a few constants

const RETURN_TYPE_HTTP = 0;
const RETURN_TYPE_XML = 1;
const RETURN_TYPE_JSON = 2;

This would allow us to define that we have multiple types that can be easily modified.

This is a good start, but is a limiting design. There are more MIME types to use, so something like the Strategy pattern might be a better fit

[jdarwood007]

I'm open to whatever you think works best. I am mostly thinking that limiting it to just Xml acction prevents us from migrating to JSON (and still supporting XML for BC), indicating other output formats like js/css/wav/etc. We don't need to implement the entire mime-type spectrum though.

[live627]

Right. We just need three classes: HTML, XML, JSON. A mod will be able to add more, like JSON+LD or whatever.

[jdarwood007]

Well we don't even need json right now since we don't have it in our code. It will just set up the extendability of it for when we do.

[live627]

the likes interface uses json. I only discovered that after digging around after your suggestion of return types.

[jdarwood007]

So we do have some. Well that changes my plan to introduce json later. We can then work on replacing our XML-based responses with json objects, which should simplify/improve some js logic.

The simple actions you mentioned you are unsure what to do, are easter eggs as you suspected.