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,501
|
Comments: 51,070
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. Building a serverless secured dead drop - one day from now

There are posts all the way to May 30, 2024

RECENT SERIES

  1. re (33):
    28 May 2024 - Secure Drop protocol
  2. Recording (13):
    05 Mar 2024 - Technology & Friends - Oren Eini on the Corax Search Engine
  3. Meta Blog (2):
    23 Jan 2024 - I'm a JS Developer now
  4. Production postmortem (51):
    12 Dec 2023 - The Spawn of Denial of Service
  5. Challenge (74):
    13 Oct 2023 - Fastest node selection metastable error state–answer
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats
}