Freelinking UI [#634332]

A Freelinking UI would be a separate module (or project) from Freelinking to expand on the admin page to put plugin override and plugin creation powers in the hands of site administrators.

The idea is to create an interface that allows the build-out of plugins from scratch, or override plugins and save the changes to the database. This sounds like the model Views uses, which implies the use of Chaos Tools. This has the added advantage of giving us a lot of swishy power, and providing exportables.

Comments

Comment #1

Grayside commented 1 December 2009 at 17:11

Because this would be dependent on a database, it should possibly be packaged in the same project as #637842: FL3 DB Functionality Through Separate Project.

It might be worthwhile to consider some FL3UI options that could be incorporated into FL3 "Core" on a variable_set/get basis. For example, overriding plugin weights is something I could see site builders wanting without needing to otherwise override or create new plugins.

In this specific case, the full Freelinking UI would probably end up on a separate page and exclude weights for ease of integration with Freelinking.

Comment #2

arhak commented 2 December 2009 at 03:39

and exclude weights for ease of integration with Freelinking

I didn't get it,
what?

Comment #3

Grayside commented 2 December 2009 at 06:33

The post was a little confusing on that point. Basically, Freelinking "Core" should have an interface which overrides the weights specified by the individual plugins.

Comment #4

arhak commented 2 December 2009 at 20:42

@#3 sure about that?

it sound reasonable, once you consider a plugin defined its weight knowing its precedence, but not every plugin developer will be aware of the remaining existing plugins (they might be several of them)

the UI should assume those weights as "suggestions", the final call is on the hands of the Drupal's guru configuring it, right?

Comment #5

arhak commented 2 December 2009 at 20:48

for instance, whenever I'm weighting a custom module (hook install) I leave a comment stating why
(e.g. ensure before modules X, Y, Z bug after modules A, B, C)

actually I have a helper mod which allows me to be more declarative
I just call a helper function requesting it to be installed after a list of modules

but the same problem arise, I don't know every module there is, and the weight I chose might enter in conflict with some weird module that might be tweaking the same stuff my module is

therefore, leaving a comment with the list of modules toke into account is kind of documentation in case such a conflict arise, and the solution would be to manually change its weight in the system table or use the Utility module to get UI support for changing module's weight

won't you be interested in letting UI to change the plugins' weights?

Comment #6

Grayside commented 3 December 2009 at 05:17

We are talking at cross-messages here, let me step back. Module weight and plugin weight are different things.

In -dev, you can now specify something like 'weight' => -10 in your plugin definition. This affects the sort order of the plugin in all locations, including the order in which plugins are processed in filtering the text. This has greater significance once multiple plugins can share the same syntax (#647940: Syntax Definition by Plugin).

My point here (in which I successfully contradicted myself once) is:

Using the Freelinking UI to define a new plugin naturally includes defining a default weight for that plugin.
Freelinking "core" should get an interface in which you can drag-and-drop override whatever weights the plugins specify.

Comment #7

arhak commented 3 December 2009 at 16:30

Module weight and plugin weight are different things.

yes, of course, I was taking that as an example

plugin's weights => filter's priorities
modules's weights => hook's priorities

the same as module's weight was not thought to be changed via UI, maybe plugins might wan't to keep weights re-sortable
if not, it would be just a matter of disabling their weight widget in the UI while leaving enabled those plugins defined via UI

Comment #8

Grayside commented 3 December 2009 at 16:58

You are worried about plugins that have a compelling reason for the weight the developer set, yes?

I am not planning to pursue a Weights UI for a while yet, until the use of weights in practice becomes clear. Breaking #650386: Plugin Weights UI into a separate issue.