Modifier system explained

Release 5 of Dlayer.com included my new modifier system, since then I’ve mentioned the system a few times but I haven’t gone into any additional detail concerning how it works.

The modifier system is responsible for all the communication between the different designers, anytime a user changes user data that could affect another piece of user data the modifier system is called, it checks the change requests and then based on the results makes silent changes by calling modifiers, currently there is only one modifier but more will be added as required.

One of the core goals for Dlayer is full control of every attribute and element, this isn’t just a hollow promise, even if a template is being used by numerous pages the user should be able to edit the template without concern that any dependant data will be destroyed.

This is a very difficult goal to achieve, especially as Dlayer gets more complicated, both via inter communication and as the number of tools increases. As it stands today I’ve not met the goal, three tools (split vertically, horizontally and resize) are disabled if data is potentially going to be destroyed, and one (border) calls the modifier system, as I update the Template designer I’ll get closer to meeting the goal.

In Dlayer pages are created from templates, templates are used to define core items that need to appear on each page, obvious examples being the header, menus and the site footer, there will typically be a low number of templates for a website with many pages being based on each template.

If a user edits an active template by managing the border of a template block the usable size of the template block will change. As a consequence, content items could be affected directly by either being too large for the block or indirectly by the layout being altered. When a change happens in the Template designer the modifier system is called, it checks all content for items that could be affected and then calls the modifier system against each of them to see if a change needs to be made, if a change is required the content items will be modified before the change is made to the template.

When checking to see if content items needs to be altered the system doesn’t just check to see if a content item will no longer fit, it will also check to see if the content item was originally the same size as the page block and also check to see if the content item was smaller than the page block by less than the change size, in both cases the previous proportions will be maintained when the content items size is altered.

The modifier system will alter the width of a content item leaving any existing borders and padding intact, shortly it will be updated to prioritise changes to the margin values (position) before altering the width.

When content grouping tools are added the modifier system will be updated to respect a group, currently it operates in individual content items.

Modifier system

For the last week I’ve been working on the modifier system for Dlayer, it is one of the base systems that modifiers data in one module based on changes made in another. I’m building one modifier initially, container width, I’ll be adding more as I add new tools and enable the currently disabled tools.

Why do I need a modifier system and what does it do?

Everything in Dlayer relies on something else, for example, a page needs a template, a content item needs to go into a page block and a page block is directly related to a template block in the template that the page is based upon.

I’m trying not to force users to work a specific way or stop them going back and forth, for example, it will be possible to alter a template after you have created and populated one or more content pages with content.

If a user changes a template, for example they add a border to one of the blocks, the width of that block has to be updated to take into account the new border. There could then be any number of content items on pages that due to the width change now no longer sit in their block correctly or flow correctly.

This is where the modifier system comes in, if after a tool has processed there is a possibility that some content needs to be reviewed a request is sent to the base modifier system, it then asks one or more modifiers to check all the content to see what needs to be done and then process the changes.

My goal is that for the majority of the requests the modifier system can and will work out what needs to be done, in cases where user intervention is required changes will be made to as much data as possible and then notifications will be sent to users telling them about content or other items which they need to review themselves. I figure it is better to process 9 out of 10 requests and inform the user about the last 1 than stop the 9 requests happening because of 1.