velir / jabberwocky

Jabberwocky

Overview

Jabberwocky is Velir's answer to the age-old adage: don't repeat yourself (We too, like to keep things DRY). It's a collection of loosely coupled modules intended to help speed up development on the Sitecore platform... and just generally make developer's lives easier while doing it.

Much as Helix has done for Sitecore solution architecture, Jabberwocky was also built to help push developers into the pit of success. It's opinionated in that it has a set of base libraries that it works well with, but it doesn't force you to use anything you don't want to.

What's in the box?

Jabberwocky comes built-in with accelerators for the following technologies:

• Dependency Injection via Autofac
• Sitecore Renderings using MVC
• ORM models with Glass Mapper
• Integrated Performance & Profiling tooling with MiniProfiler
• Transient Error Handling strategies with Polly

Quickstart

If you just want to get up and running with everything, you can install the meta-package from NuGet (coming-soon):

Install-Package Jabberwocky.Library

Otherwise, you can pick and choose which packages you want to use in your solution. The minimum requirements for version 2 of Jabberwocky are:

• Sitecore 8.2 (initial release)
• .NET 4.5.2

Documentation

You can find the documentation for Jabberwocky here: https://jabberwocky.readthedocs.io/

Docs are in the process of being updated for version 2, so look out for the changes!

jabberwocky's Issues

GlassViewModel should support rendering parameters

The GlassViewModel should be updated to include some sort of accessor for a strongly-typed Rendering Parameter associated with the current rendering.

Consider creating a new GlassViewModel<TDatasource, TRenderingParameter>

With this change, we must also allow for injecting the TRenderingParameter type into the constructor of the GlassViewModel, so that it is accessible for use from within the constructor.

PR #23 - Review and refactor

PR #23 provided a hotfix for an issue with LifetimeScope resolution in the AutofacProcessorFactory.

While serviceable, the exception handling within the MvcLifetimeScopeProvider is not pedagogically correct; we should eliminate spurious exceptions, and instead short-circuit on the condition that would ultimately cause known exceptions to be thrown.

Fix SitecoreService registration to not throw when SitecoreContext is not available

Update nuget package for Jabberwocky.Glass

Need to rev Jabberwocky.Glass to incorporate changes made in PR #26

AutofacProcessorFactory does not support PerRequest scoped resolution

The AutofacProcessorFactory will attempt to use the root container when creating a child lifetime scope. Because of this, the factory is unaware of any tagged or nested lifetime scopes created by the MVC or WebAPI dependency resolvers - thus the factory is unable to support PerRequest dependency resolution.

The factory should be updated to attempt to create a child scope from any existing lifetime scopes, before falling back to the root container.

Review AesHmacCryptoService IV generation

When using AES (in CBC mode), the initialization vector should adhere to the following:

• Random
• Unpredictable
• Not secret (optional)

This should be fixed so that:

• It should be randomly generated
• IVs should not be reused across messages
• It should be added to the message payload as a partial string, co-located with the hash

After review, the current implementation suffices. The prepended nonce (randomly generated, spanning one block) serves this purpose.

Allow for modifying GlassViewModel datasource resolution

By default, Sitecore (8+) will use the following strategy to resolve the DataSource for a given rendering:

1. Explicit DataSource specified (in the Datasource field)
2. Nested DataSource (specified by the Rendering.Item property)
3. Sitecore Context Item (page item)

Step 2 may be unexpected for many people used to pre-8.0 resolution logic (steps 1 & 3), so it may make sense to be able to suppress this behavior on a case-by-case basis.

Sitecore currently exposes the following property to allow you to opt-in/out of this functionality globally via: <setting name="Mvc.AllowDataSourceNesting" value="true"/>.

If this is a common enough scenario, we may want to consider adding this new functionality.

Current design notes:

1. Inherit default behavior (for nesting) from Sitecore
2. Declaratively opt-in or opt-out (depending on inherited behavior) on each ViewModel via an attribute

Analyzers are not working

Due to a bug in the diagnostic IDs, the code analyzers are not working.

Do not add value to cache if callback returns null

In the BaseCacheProvider, if the callback in GetFromCache() returns null, should we skip the Cache.Add() method?

GlassAdapterFactory types should support base method calls

The GlassInterfaceFactory pattern currently supports falling back to base implementations of members, but only if the member is marked 'abstract'.

In order to support scenarios where we can re-use existing base logic as part of our derived implementation, we should consider allowing for base member calls from within an explicitly implemented member.

Some things to consider:

• Do we only want to support direct base member calls, or ...
• Do we want to add support for specifying an explicit base implementation to use (possibly bypassing the direct inheritance chain)?
• What are some pros/cons of the second approach?
  • Pro: Much more flexibility for reusing and composing template-based logic
  • Con: High potential for mis-use; quite possibly (probably?) an anti-pattern

Some design notes:

• Base member call can be implemented as a function on the BaseInterface abstract class,
  • Should it be a generic function, and return a strongly-typed GlassInterfaceFactory interface type, or
  • Should it return a new proxy of the current Type, and expose all methods/properties?
• If we implement arbitrarily-nested (ie. specific template type) base member calls, then we would need a generic function that specifies the specific template type to use for the implementation.

Jabberwocky 2.0.1 referring to DynamicProxy2 instead of DynamicProxy

We have downloaded Jabberwocky 2.0.1 to use with Sitecore v8.2 Update 5 . Jabberwocky 2.0.1 is looking for Autofac.Extras.DynamicProxy2.RegistrationExtensions.InterceptorsPropertyName which is ideally part of old Autofac . Ideally this should be Autofac.Extras.DynamicProxy.RegistrationExtensions.InterceptorsPropertyName. Could you pls help with the package that uses latest Autofac .