I am in the initial phases of designing a reporting system. deployment will take place in phases.[ul]phase 1: frame work, GUI, critical reports. phase 2: important reports phase 3: useful reports phase 4: additional reports[/ul]you get the idea.

I had the thought that "plug-in" reporting would be very ideal, this way I wouldn't need to alter my existing assemblies just to add 1:n reports. I found this article on MSDN which onlines how to add plug-ins for logical stuff [http://msdn2.microsoft.com/en-us/library/ms972962.aspx]. but i don't see how the gui could be added.

in it's simplest form: LLBL for DAL my code for BLL my code for controllers (reports, GUI,...) X number of report plug-ins.

my thought for the GUI is to load all the plug-ins, have the user select which reports to generate. each report would have it's own GUI with the input options specific to that report. the reports are different enough that I think this is a better option than creating a single generic GUI and then hiding/displaying controls.

the 1st GUI will be a web app, but i want to leave it open for desktop, webservices, and the like. How would i go about incorprating GUI controls/interfaces into the plug-in? so the framework knows to get the gui from the plug-in.

it's still the early phases so if any one has comments, critiques or insights. I am more than will to discuss.

jmeckley wrote:

How would i go about incorprating GUI controls/interfaces into the plug-in? so the framework knows to get the gui from the plug-in.

it's still the early phases so if any one has comments, critiques or insights. I am more than will to discuss.

I didn't look at the reference you sent... but this sounds like a place for UserControls and a PlaceHolder control. You could have a user control for each report and add them to the place holder as needed.

BOb

yes, I definately want to go with user controls (ascx) for the web gui. I guess my question is: do I include the user control within the plug-in? I suspect the answer is no, becuase if I include a web GUI then I will also need to include other platform GUIs as well. that defeats the purpose of decoupling. If I don't include it in the plug-in I either need to create it at design time or generate a user control at runtime.

if at design time then I will need to modify my GUI with every plug-in, thus defeating the point. I'm not sure where to begin if I generate it at runtime. how would I know what control type to use, how to validate the data, etc.

1 option for validation is just to do a post back, validate the input within my report object and postback any errors that occur. pretty much avoiding all asp.net validation.

The report itself should contain information about how it can be modified, but should leave it open to the presentation layer to decide how to show it to the user. If appropriate, you can create a standardized set of classes or interfaces to represent modification points, such as

• Field/Column List
• Groupings
• Sort Order
• Predicates. Your reports would contain, as an example, a property called "AvailableSortColumns" which would contain a list of "Field" classes that the user may sort the report by. The GUI would present the list to the user, then return selected fields back to the report at runtime. You'll have to decide whether this is doable for your environment, but for most standard reports this should be a start.

Jeff

jeff, I think I understand where your going. that wasn't my original intension for the plug-in. I really like your idea, but it's outside the scope of what I require.

with going too far off topic. This many options would create a problem for the majority of the end-users (tenured, non-technical staff). I also think using the terminology "framework" may not be the best choice of words.

By framework I mean a single access point to select, filter and view reports. Not a framework like MS Ent Lib, or something like that.

I think I'm going to pass on report plug-ins for now. while this would be very cool, it's beyond my expertise and available time.

Well, creating reports as plugins is a good idea; I've done it myself to great effect. It's not too hard, but it is a bit more of a pain setting of the environment to create the reports as the reports themselves are, by design, decoupled from the rest of your environment. Still, not too bad...

However, if you need to be able to allow the end user to filter, sort, or group the reports you can either pop the UI from the report itself, or provide a standardize interface like I mentioned which will take a significant amount of time and will definitely affect how you create the reports themselves.

Jeff

jeff, I have a feeling your programming expreince and skill far exceeds mine

some background info on how this will work. use CR for .Net as the reporting engine. push data from BL to report. export report to stream as PDF. display PDF report. if a user wants to save/print they can.

reports are design my either myself or my supervisor. users are given access to reports they require. select a few input paratmeters and click a button to view the report.

I think the big hang up for me is how to design the GUI so communication can occur between user input and report plug-in. It seems a generic interface would be the way to go. However that's not really an option with my end-user base.

jeffreygg wrote:

pop the UI from the report itself

do you mean scan the report object for these items and dynamically build the GUI based on this?

I part of the puzzle I haven't decided on yet is what types of objects to pass. do I 1.)collect simple types from the GUI and construct predicates in the BL? OR, 2.) contstruct the predicates in the GUI and pass an IPredicateExpression to the BL?

I lean towards option 1.

Well, if you're not interested in spending the time to build out a whole generic framework for input options (sort, filter, group, etc) just so you can expand into other presentation technologies later, then just add a reference to System.Windows.Forms from within the report itself and launch a custom dialog. The dialog can be hard-coded - it doesn't need to be dynamically created - and will just ask the user for the necessary info which the report will use to finish generating itself.

Jeff

<Edit> Just missed your last...Yea, I would go with option #1. More flexibility and you'll have a lower risk of coding yourself into a corner with IPredicates in the GUI.