Oren Eini

CEO of RavenDB

a NoSQL Open Source Document Database

Get in touch with me:

oren@ravendb.net +972 52-548-6969

Posts: 7,546
|
Comments: 51,161
Privacy Policy · Terms
filter by tags archive
time to read 1 min | 84 words

Because Binsor is strongly typed, you need to specify the imports for all the types you are using. It can get quite long, at times, because you are usually crossing the entire application, so basically every namespace you can think of is there.

I don't like that, it should be clear what is going on, and the imports should go elsewhere where they don't distract me. So I did it.

You can now write:

import namespaces from defaultImports.boo
#real code here
time to read 2 min | 300 words

A word of advice, if you are not using an IoC, you don't have the problem of defining components, you have the one before that, of dependency management. I am talking here what happens after you embrace IoC, what the next pain points are.

Having the configuration in a single place, being able to define both the shape of the application and its configuration is really nice. It makes a lot of things very easy. Until you want to send allow the user to extend a single facet of the configuration, but not allow them (or not expose them) to the full configuration.

You would want to define your components in a single place, and their configuration in another. To supply all the required configuration, and let the end user override them.

That is usually the place where we setup bridge to a more traditional configuration approaches, which isn't really pleasant. I just added to Binsor to do this across files, so I can use the following syntax to define and override configuration.

Main file:

def DefineComponent():
	component "email_sender", ISender, EmailSender
	
	component "email_sender2", ISender, EmailSender:
		Host = "example123.dot.org", To = ( "Lauren" )

	component "email_sender3", ISender, EmailSender
Extensibility file:
import file from Main.boo

DefineComponent()

extend "email_sender":
	Host = "example.dot.org", To = ( "Kaitlyn", "Matthew", "Lauren" )

extend "email_sender2":
	Host = "example.dot.org", To = ( "Kaitlyn", "Matthew", "Lauren" )

extend "email_sender3":
	@startable = true
	@tag1 = "important", tag2 = "priority"
	lifestyle Pooled, InitialPoolSize = 10, MaxPoolSize = 100
	configuration:
		hosts(list, item: host) = ["rhino", "orca"]

Combine that with the Windsor's resource system, and you get an embedded configuration, externally configurable.

I find it very sleek.

time to read 1 min | 115 words

Okay, I intended to post about this in more details, but I want to wrap up this day, I added support for native facilities in Binsor. By native I mean facilities that expect to be configured by Windsor XML configuration. Since I am mostly the only one that is writing Binsor based facilities, this has been a problem when people wanted to use the standard facilities.

You can see the syntax here, very Yaml like, I think :-)

I am going to post soon about how I managed to get this syntax to work.

Facility("loggerFacility", LoggingFacility, 
	loggingApi: "Log4net", 
	configFile: "Config/log4net.config",
	NestedConfig: {
		something: "foo",
		bar: "nar"
		}
	) 

FUTURE POSTS

  1. Partial writes, IO_Uring and safety - about one day from now
  2. Configuration values & Escape hatches - 4 days from now
  3. What happens when a sparse file allocation fails? - 6 days from now
  4. NTFS has an emergency stash of disk space - 8 days from now
  5. Challenge: Giving file system developer ulcer - 11 days from now

And 4 more posts are pending...

There are posts all the way to Feb 17, 2025

RECENT SERIES

  1. Challenge (77):
    20 Jan 2025 - What does this code do?
  2. Answer (13):
    22 Jan 2025 - What does this code do?
  3. Production post-mortem (2):
    17 Jan 2025 - Inspecting ourselves to death
  4. Performance discovery (2):
    10 Jan 2025 - IOPS vs. IOPS
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats
}