Edit wiki page
You do not have sufficant permissions to edit or create the wiki page.
=================== Protocol 14.02.2008 =================== Because of speed considerations in the dash board project overview page we rediscussed the way data is provided for the dashboard. Decisions ========= Signal push mechanism --------------------- We decided to use a push mechanism for signals, which means, that the signals provide the data associated with them in the signal. The data will be provided in a documented structure, containing all data, which is cheap to fetch on the first hand. The data struct associated with a signal should be obvious by its name, so it will be easy for the user to find documentation about a signals data. We may also provide this information in the list of emitted signals in the module, together with the name of the data struct and ensure this way, that only and exactly this data is passed together with the signal. For all data, which is not cheap to fetch the provided data struct provides some kind of interface to access this data. This may be methods on the struct, or magic properties which perform the lazy fetching transparent to the user. Dashboard use case ------------------ In case of the dash board this means that the dashboard has no data available on the first call to display, but only shows a list of the projects. If modules in one project fetch their data, they send some signal (like dashboadUpdate) containing the data to be displayed for the module in the dashboard. The dashboard cashes this data and displays it on the next request. There are two major reasons for this strategy: - We use the signal push mechanisms consistently in the whole application and do not pull data with signals. - The dashboard is the central entry point for each user for each project. If we would refetch the data on each request, we would need to instantiate all projects with all their modules, so that they may possibly react on this signal. This also would be hard to cache, because we would need to clear the cache on each signal from that project, because we can't reimplement ANY module logic in the dashboard. Reasoning --------- The decision for this has several reasons: 1) A unified push mechanism makes it easier for new developers to understand the architecture. 2) Signals are not common to use to fetch data, instead it is common to attach data to signals. 3) The single struct object associated with a signal is easy and effective to document. So it will be obvious for new developers which data is available.