Hi, Further to the issue in
http://www.devexpress.com/Support/Center/p/CQ66692.aspx
there is a significant catch to the solution proposed - the "container" reporting class that wraps the actual report class needs to be persistent for the XAF reports system to see it. While I can see that it may be necessary (although a little cumbersome) to create a reporting class, it becomes very ugly if that class has to be a singleton stored in the database - in many systems, you may well find that the database contains more tables for "dummy" reporting classes than actual domain classes. This is an extemely common problem and I would strongly suggest that it requires a more acceptable solution.
I would note that this is not dissimilar to this issue
http://www.devexpress.com/Support/Center/p/CQ52410.aspx
although for views, the requirement is less common so the solution is less onerous.
It seems that the common problem here is the requirement to create a temporary class that composes a number of domain classes into a specific "view".
So, my suggestion is to allow XAF to support such classes for viewing and reporting without the need for them to be persistent. E.g. assuming that they are usually empty data containers (not dissimilar to a DTO) with no meaningful relationship to the domain classes they contain, XAF could just create the class on the fly without insisting on loading them from the data store.
Jascha
We have closed this ticket because another page addresses its subject:
Core - Provide the capability to display several Views side-by-side and change them without recompiling the application (something like "Dashboard")
Hello,
We analyzed possible ways to support this behavior and decided to split this suggestion into two new suggestions:
- "Reports: Allow using several business classes as independent datasources in XAF Reports in the End-User Designer" at http://www.devexpress.com/issue=S30936
- "XAFCore: Provide a capability to show a couple of Views at once one near together and customize this list at runtime (something like Dashboard)" at http://www.devexpress.com/issue=S30937
Thanks,
Dan
Hi Dan,
Extremely pleased you have got round to this feature. IMO it is one of the most common requirements that XAF does not currently address. Funnily enough, I have implemented a XAF dashboard framework (unsurprisingly called "Dashboard") that sounds like what you are proposing.
FWIW, my take on this is that you could add this feature by creating the concept of something like "domain views" that allow XAF to render hetergeneous data. Being able to inject a domain view layer between presentation and domain model would give us very useful additional functionality. An approach that comes to mind as to how you might provide such a feature:
Add a domain view base class that XAF handles rather like it currently handles domain objects. These views could be rendered by XAF reports. Domain view descendents could be composed of properties much like domain objects where those properties could be basic types or instances or lists of other domain views, domain objects or, perhaps, XP Views (or a XAF wrapped equivalent). So, an Outlook Today domain view might be composed something like:
class OutlookToday : DomainViewBase
{
Collection<Appointments>
Collection<Tasks>
Collection<Messages>
…
}
where Collection could be similar to an XPCollection / CollectionSource.
XAF ccould handle domain views much like it currently handles domain objects with the key differences and features:
Domain views are inherently non-persistent (i.e. no table is required in the db and they may well not be "XPO" classes)
Domain views are readonly (i.e. no toolbar actions relating to writing/editing are visible)
Domain views are available as singleton navigation items (i.e. straight to a detail view), *with* the option to open the view either in the main window or as a popup detail view window (definitely in the win ui, possibly in the web ui?)
Detail views rendering domain views should have an auto-refresh feature with a toolbar action that has model-driven choices like Auto Refresh:
Never
Every Minute
Every 5 Minutes
Every 10 Minutes
…
Another extension that might help in this respect would be to add a new detail view item type that references another view so that a view can be composed of sub views. This would not be of much help for reporting but would provide a model-driven abiltity to create and maintain dashboards. In this case, an Outlook Today domain view might be composed something like:
<DetailView ID="OutlookToday_DetailView">
<Items>
<EmbeddedView view="Appointments_ListView" Caption="calendar" …>
<EmbeddedView view="Tasks_ListView" …>
<EmbeddedView view="Messages_ListView" …>
…
</Items>
<Layout…>
</DetailView>
We would need the ability to specify controllers for such compound views so that they could have logic associated with them and I guess that may not fit well with the current architecture that assumes a current object.
I'll leave it there before I get too carried away proposing something that you have probably already decided to do another way!
HTH,
Jascha
Hello Jascha,
Thanks for such a detailed explanation.
Indeed, I forgot to add details about the implementation, as we currently imagine it, and I will add a few lines now.
Currently, I vote for your second approach, because the "Reporting" and "Dashboard" features have different needs. For example, usually a Report includes information about a company, which is included into the report's header or footer. But this is definitely unnecessary in a "Dashboard". As we see it now, it's unlikely, that you will have exactly one and the same couple of separate DataSources for both a dashboard and a report. Again, usually you will have a lot of different reports, and only several dashboards.
Anyway, I will provide more details about a possible implementation, and I suggest that we continue this conversation in the XAF Newsgroup, if necessary (I will add a link to it into our suggestions).
Thanks,
Dan