On Monday 22 March 2010 13:26:12 Josef Reidinger wrote:
Implementation of notification is up to you (you can use db which we have on ws or files etc..). and then solution comes in different way how to handle when you know that problem exist.
This moves module specific know how into the status module. It needs to be maintained twice then.
1) simple know what each problem is and handle it in status module, easy to implement solution not so easy to extend, especially by external vendors
This isn't even easy to implement, as the status module needs to know how to query for exactly what in a foreign module - and if these modules change, the status module needs to be adapted too. This will sooner or later get inconsistent and messy.
2) each ui controller which can have problems in ws has methods problems which return array of rendered contents for status notification. So it can include also link to fix it and other usability improvements -
Why should this go into the ui controllers? Its the backend that knows about the status of the module or its configuration.
to be universal, you need to store name of controller, so you know which controller you must ask. (or you can simple ask all ui controller and don't need any notifications)
This "get the correct status" approach should become so generic that we should
not need to touch it anymore just to hook in any other module. Just think of
custom modules from software vendors. If they need to change our code to hook
in their modules it could damage even more.
But if we provide a generic framework everybody could easily include his
custom module to the status information.
The question now is, what is the best way to do it?
I like the idea that every module that responds to the method "status" could
will be integrated into the status info (see "status" as a symbol, we can of
course change that name). Thats a pretty simple way to offer thirt parties a
way to include their module status and a clean an generic way for ourselves.
And it even follows the basic concept of REST.
Ciao,
Daniel
--
J. Daniel Schmidt