Yep, I've thought about it. It is posiible to subscribe for event
before installing new configuration and tailor it as flow of component
registrations and unsubscribe ufter conf is loaded.
But this approach is more likely a dirty hack then honest solution.
Other solution that i can think about is
Konstantin,
That's an interesting problem :)
What do you want to do when a plugin containing invalid configuration
is registered?
Container's events are actually not hacky - most facilities (incl.
these comming out of the box)
subscribe to, and act upon container events.
There's no way to reject
I do not like to reject plugins. The purpose is to reuse castle
configuration system but limit the scope that can be configured.
Plugin config should contain only components configurations and
properties anything else should be ignored.
Plugin contains implementation of some interface lets call it
Notice you can unregister component only if no other component depends
on it.
Also there's no way to unregister a facility, that's why if you want
to safely
'test' what a plugin provides, an additional test container seems to
be the way to go.
On 25 Mar, 12:59, Konstantin
Although what I imagine you really want is:
context.Put(lstCustomer, lstCustomer);
You must have a great imagination because
that was the solution.
Thanks for figuring it.
--
You received this message because you are subscribed to the Google Groups
Castle Project Users group.
To post to
windsor xml configuration is designed to configure how the container
operates. it sound's like you want to define how a single plug-in
operates. For that I would use a custom configuration handler. similar
to how Monorail has it's own configuration section independent of
windsor. This will give
I've found a solution (the code is very draft, it is just to proof an
idea).
class PluginConfigInstaller : IWindsorInstaller, IInterceptor
{
private readonly IEnumerablestring _componentIds;
private readonly IResource _resource;
public
Now I understand what you are saying. Having just started with
Castle, it didn't sink in until I just played with what you said.
Thanks.
--
You received this message because you are subscribed to the Google Groups
Castle Project Users group.
To post to this group, send email to
Hi all,
Ken Egozi has decided to pass on the MonoRail leadership, as he is currently
unable to contribute the time that MonoRail needs to stay up to date and
relevant.
The PMC has voted, so it is official that John Simons will take the lead.
Many thanks to Ken for his work on MonoRail, it is
firstly, thank you both for your quick replies; your answers confirmed
my suspicion.
Krzysztof,
There actually was no reason why I was using a factory method in my
code. I've finally gotten an opportunity to introduce a DI container
into the code base at work, and I was evaluating the
Hello,
I have the following situation:
public class License
{
[BelongsTo]
[ValidateNonEmpty(Please select a version.)]
public virtual ProductVersion Version { get { return version; } set
{ version = value; } }
}
ProductVersion is a simple class, with Id and Name.
The versions must be chosen
Congrats John,
On Fri, Mar 26, 2010 at 1:00 AM, Jonathon Rossi j...@jonorossi.com wrote:
Hi all,
Ken Egozi has decided to pass on the MonoRail leadership, as he is
currently unable to contribute the time that MonoRail needs to stay up to
date and relevant.
The PMC has voted, so it is
James - you should've asked whether I knew about this :)
John has already contributed hugely to the project, and I'm sure that it is
going for a bright future.
I will be doing less, but off course not ditching altogether.
In a way I still contribute to MR, by working on a potentially huge
13 matches
Mail list logo
