Hi Wayne,
Sorry I didn't get back to you earlier, I've been pretty busy...
Global trigger listeners are the easiest part, good that you chose them as your starting point!
One option would be resolving the listeners et al right away like you say but I'd prefer to resolve them as lazily as possible, to allow them to fulfill their own dependencies (in fact that's what the current QuartzFacility does). So the AddGlobalTriggerListeners() and such methods would only register stuff, not resolve them.
--
Mauricio
On Thu, Jul 15, 2010 at 9:30 AM, Wayne Douglas
<wa...@isit.gd> wrote:
Hi
So, i started thinking about doing this and so inside QuartzFacility.cs I started by adding the following stubs:
#region fluent
///<summary>
///</summary>
///<param name="listeners"></param>
///<returns></returns>
public QuartzFacility AddGlobalTriggerListeners(List<string> listeners)
{
return this;
}
///<summary>
///</summary>
///<param name="listeners"></param>
///<typeparam name="T"></typeparam>
///<returns></returns>
public QuartzFacility AddGlobalTriggerListeners<T>(List<T> listeners) where T : ITriggerListener
{
return this;
}
#endregion
And so, right away I have questions!! Should I be building up a configuration as in BuildConfig or should I be looking at
resolving these services and adding them to the quartz scheduler from here? As I type this I know i need to add these services
to the QuartzNetScheduler from here. Maybe if you could confirm that. And also, just confirm that I am starting in the right
place and this is where the fluent API is expected to live?
Sorry for being a pain, this is my first dive into fluent API and OS dev :)
w://