v6.0.0

v6.0.0 builds upon the work from v5.0.0 with its own set of breaking changes.

High level changes

Breaking

• Elements are now Subcomponets
• Subcomponent meta data now has a Level
• Renamed ItemType to ViewType in rendering logic

Other

• The Default View Path Helper logic has been moved to an abstract class. This is to help developers who would like to modify certain aspects of the view path helper system without having to rewrite the whole class.
• Section has been moved to MetaData and a selection of methods have been added to support developers who need to use this;
  • HasSection - returns a bool if Section has a value
  • IsSection - returns a bool if Section meets a specific criteria. There are 3 overloads to support this

In-depth Breaking Changes

Goodbye Elements, hello Subcomponents!

The biggest breaking change is Elements are now called Subcomponents. Elements as a term was a little too vague. Subcomponents will hopefully convey that they exist only to be a part of something else. This isn't the same as a component which can be rendered within another component. If that nested component can existing as its own separate thing then it's still a component.

All tag helpers and logic for Elements has been updated too.

Subcomponents now have a Level

Generally speaking a Subcomponent won't really care about the level but if the subcomponent has components within it like a Grid implementation then the level should be passed through. This may also be useful if you're creating a nested menu using the drop-subcomponent tag helper.

ItemType renamed to ViewType

The name item type or {ItemType} was a little too generic. This was renamed to {ViewType} in the token replacement. As with v5 if you do not wish to break your views down by type this can be omitted by renaming it from the view path pattern in the config.

v5.0.0

This is biggest release in a while containing many breaking changes and a few new features.

High-level changes

• Added new IElement type
• IModal no longer inherits IComponent
• ComponentMetaData and related functionality has been moved to the web projects
  • Rhythm.Drop.Web.Infrastructure will contains the abstracts and interfaces
  • Rhythm.Drop.Web will contain the implementation typically used by end-user
• Modal, Component and Element now have separate Meta Data
  • A new MetaData base class was added
  • A new CollectionMetaData base class was added to support MetaData which exists within the context of a collection (e.g. Elements and Components)
• View Path Helper now uses MetaData and supports a new replacement token {ItemType} this optionally allow developers to separate Components, Modals and Elements
• Configuration for Components has moved from Rhythm:Drop:Components to Rhythm:Drop:Rendering as this config now is for more than just components
• Added drop-element and drop-elements tag helpers
• Package dependencies now supports within the current major version

In-depth Breaking Changes

IModal no longer inherits from IComponent

IModal isn’t really a IComponent. It kind of is but it kinda isn’t. A modal is special kind of component but the original reason for extending IModal from IComponent was to make rendering easier. With the inclusion of IElement it feels like now is the right time to decouple these things.

From a rendering perspective it could also lead to some weird scenarios where technically drop-component or drop-components can render a collection of IModal or a single IModal. If they exist why have drop-modal and drop-modals?

This also means that any views for IModal objects will need to use ModalMetaData instead of ComponentMetaData and the accessor property for the Modal will change from Component to Modal.

Hopefully none of your custom IModal implementations have a property called Middle otherwise you could end up with line in your razor files like this:

@Model.Modal.Middle

ComponentMetaData and MetaData now in web projects

MetaData is only used by web facing functionality. As it stood in the Models project it was fine but didn't make as much sense as putting this in the web projects.

This will mean a breaking change to the _ViewImports.cshtml file.

Replace:

@using Rhythm.Drop.Models.Components

With:

@using Rhythm.Drop.Web.MetaData

This is the namespace where the generic type versions live for;

• ComponentMetaData
• ElementMetaData
• ModalMetaData

In addition the extension methods for things like IsEven(), IsRootLevel(), etc are no longer extension methods and below to the object itself. Some functions like HumanReadableIndex are now a read only property instead of a function.

ViewName has also been removed from the meta data directly.

Configuration changes

Now we have multiple types of renderable item instead of just IComponent the configuration has been updated to reflect this. The Components configuration has been moved from Rhythm:Drop:Components to Rhythm:Drop:Rendering. This still supports the DefaultTheme and ViewPathPattern.

The default ViewPathPattern has changed from:

/Views/DropComponents/{Theme}/{ViewName}.cshtml

To:

/Views/Drop/{Theme}/{ItemType}/{ViewName}.cshtml

The old behavior can still be replicated by changing your path back to the old default value. With an additional part to the default URL and separate types of renderable items it made sense to not only shorten the path but remove "components" too from the initial base folder name within Views.

To support the new {ItemType} replacement token there is a new configuration property ItemTypes. Which controls the path slug for Components, Elements and Modals. This can be configured if you need to change any of these things.

View Path Helper

View Path Helper previously took two parameters view name and theme. This has been replaced by an abstract MetaData parameter which is used to determine the theme, view name and item type.

Package Dependencies

Prior to v5 any dependencies within Rhythm.Drop which were Rhythm.Drop packages were based on the current version or higher. For example:

Rhythm.Drop.Web (>= 4.1.0)

This didn't make any sense as breaking changes would often prevent this dependency from working out. Going forward all packages will ship with a cap at the current major version. For example:

Rhythm.Drop.Web (>= 5.0.0 && < 6.0.0)

This is thanks to code from the Umbraco CMS project.

v4.1.0

• Minor breaking changes to DropLinkTagHelperRendererBase to make it easier to extend and renamed some method names to match intent.
• Code cleanup
• Additional unit tests for functionality written in v4.0.0 release

v4.0.0

This release is rework of image tag helpers.

Major changes

• Breaking: Removes <drop-image /> as a tag helper
• Breaking: Renamed RenderMode to LoadingMode
• Adds picture[drop-model] tag helper to always render a tag as picture
• Adds img[drop-model] tag helper to always render a tag as an img
• Adds picture[drop-model] > img tag helper to control the markup of the img within a picture[drop-model] tag helper

See the Tag Helper documentation on how these new versions work.

v3.0.0

Introduces breaking changes to the rendering system by abstracting the IHtmlHelper dependency into IRenderingHelper. IViewPathHelper was also rolled into this code for the default implementation.

This release also fixes a bug with DefaultDropLinkTagHelperRenderer which did not respect inner tag helper content if already set.

v3 also introduces tests around the default Tag Helper Renderers to ensure consistent output.

v2.2.0

Adds in support for Implicit Using statements. If your project uses this feature you can now AddRhythmDrop to your app without needing an additional using statement.

v2.1.0

Introduces a "Section" property for rendering component/modal tag helpers. This allows the developer to provide a specific area the component/modal is rendered. This was added to the following tag helpers;

• drop-component
• drop-components
• drop-modal
• drop-modals

Developers can access this in the ComponentMetaData class as a Section read only property.

v2.0.0

All changes from v2.0.0-beta1 and a few additional breaking changes.

Breaking changes

• Include/Exclude Attribute are now renamed Set/Remove Attribute in ILinkBuilder implementations

IImageBuilder changes

• Most "Add/And" (e.g. AddSource) methods are shift to their own interfaces now

v2.0.0 Beta1

This release sees a rework of factories with many breaking changes.

Breaking Changes

• IComponentMetaDataFactory was moved to the Web packages
• IImageBuilderFactory and ILinkBuilderFactory were completely removed in favor of directly injecting IImageBuilder and ILinkBuilder into the DI container.
• IImageBuilder and ILinkBuilder were also moved out of the Infrastructure package and into their own separate package Rhythm.Drop.Builders. This was done so these builders can support web and non-web based logic if needed.

ILinkBuilder specific changes

• Logic in ILinkBuilder and its methods was consolidated into a single class instead of spread across multiple concrete classes.
• Removed WithLabel under ILinkBuilder this to discourage varying paths to get to the same thing (e.g. WithLabel() -> AndUrl() was the same as WithUrl() -> AndLabel()). However for extension methods both scenarios would need to be considered.
• Logic for AndLabel, Include/Remove Attribute and Add/Remove Class was moved to generic interfaces to help with future extension method writing to utilize these methods with duplicating code.

Misc

• Add RhythmDropBulider for Web were given a "Web" name (e.g. AddHelpers is now AddWebHelpers)
• RhythmDropBuilder is now in the Rhythm.Drop package.

v1.0.1: Initial release

This is the first full release. Including all changes from pre-releases.

Install via NuGet.

Note: v1.0.0 was skipped as it was sent to NuGet too soon.