Closed (fixed)
Project:
Rules
Version:
6.x-1.x-dev
Component:
Documentation
Priority:
Critical
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
10 Mar 2009 at 12:48 UTC
Updated:
21 Feb 2010 at 11:45 UTC
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 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 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 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 commentedMoving documentation to separate issue and marking this as fixed.
Comment #10
mitchell commentedComment #12
mitchell commentedFixing my spelling error.