Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.This would allow cool things like separate interfaces for modules that wanted more complex or simpler UI's.
For example, Ubercart could have a UI just for managing a store, while comment notifications could be added to nodes with a simple check box on node type forms. Simpleviews is also a good example of another module using the API of Views.
Comments
Comment #1
mitchell CreditAttribution: mitchell commentedAbstract UI into UI API
I have a new idea on how to use Rules as a notifications framework using services module. I'll go into more detail about this idea soon, but for now, I'm marking this as critical for many reasons:
- People think of Rules (the engine, the UI, and the module integration) all as one package.
- The GUI is good, but it's holding this module back. The more specific the UI, the better. A general UI is cool to start with and standardize with, but not for practical application. edit: *not for programmatic application
- Our rules need to be configurable & able to be switched on/off right from the environment where they are about to trigger the rule.
Comment #2
fago>I have a new idea on how to use Rules as a notifications framework using services module. I'll go into more detail about this idea soon, but for now,
That sounds interesting... ;)
>- The GUI is good, but it's holding this module back. The more specific the UI, the better. A general UI is cool to start with and standardize with, but not for practical application.
Indeed. I'm going to ensure rules is working fine with "foreign" UIs. I also think of writing some basic documentation about how to implement another UI - so things play nice together.
Do you mean by that doing a rules and rules_ui module? As mentioned in the BOF I've built all into one module is the UI is now lying in include files nevertheless - so there is only hook_menu left... But perhaps having a separate module makes still sense.
Comment #3
mitchell CreditAttribution: mitchell commentedAnother UI example is path aliasing. Content Profile could include a default rule set for automatic aliasing, and then also provide a UI for overrides on the node/edit/[node:type] pages. The configuration form could reside in Content Profile's settings pages.
Marking as postponed: I don't think this is feasible for 1.0, so I made another issue to discuss that: #414176: Create a 6.x-1.0 release.
Comment #4
fagoThere shouldn't be much work to do and something like "a new UI module" shouldn't change after 1.0, so I plan do it before.
For "foreign UI"s I think of creating a handbook page, which explains that a bit.
Comment #5
fagoOk, I moved the UI into its own module. Please test it by using the dev snapshot.
Comment #6
fagohttp://drupal.org/cvs?commit=190776 - I've just improved rules to show a warning when one edits a custom rule provided by another module. Although foreign modules may still set the rules to 'fixed' - then it cannot be changed through the rules UI.
Setting to documentation, as the only thing missing now is a docu page.
Comment #7
mitchell CreditAttribution: mitchell commentedAn example would probably be better in the short term rather than documentation.
Comment #8
fagoProbably yes, but currently I don't have time left for writing another UI nor do I see where one would be needed. So I'm going to document it.
However feel free writing an example :)
Comment #9
mitchell CreditAttribution: mitchell commentedMoving documentation to separate issue and marking this as fixed.
Comment #10
mitchell CreditAttribution: mitchell commentedComment #12
mitchell CreditAttribution: mitchell commentedFixing my spelling error.