Blog posts by Mattias Bomelin

Business Foundation field attributes

Thu, 19 May 2016 20:45:26 GMT

Creating a meta field for a BF class of type string will by default result in a db column nvarchar(50). Changing the meta field type to LongText will result in the same.

After consulting the documentation (read decompiler) we learn that an attribute is also needed to actually change the db column type.

The MetaClass.CreateMetaField() function allows to input an AttributeCollection. Adding the attribute LongText with the value “true” to the collection will result in a db column of type ntext.

It's also possible to use the properties from my previous post about validators as attributes when creating meta fields. The meta class validator XML will then be extended with the validation information from the attributes and some of them will also be used when createing the db column.
For example using MaxLength for a string field type will change the default db column nvarchar(50) to nvarchar(x) as well as adding the MaxLength attribute to the validator XML.

Some validator properties have inconsistent naming in the meta field creation process in case you’re wondering why not all validator properties work. For example the validator property 'ValidationExpression' for File field types is represented in the meta field attributes as 'NameRegexPattern', and the validator property 'IsMultiValue' is called 'MultiValue' in the meta field attributes.

Happy coding ;)

Btw, I got questions on the image in my first blog post. It's from an old goat stable in the middle of nowhere in the northern parts of Sweden.

Being an e-commerce geek I think todays image is really fun. It was a delivery to me from a swedish office supplies company who didn't mind reusing boxes from their incoming deliveries (wonder where they've hidden those in the catalog, I looked but couldn't find it). Even for a company within the 'adult' segment, where one of the most common usp's is anonymous deliveries, it would be outrageous making a delivery like that!

Business Foundation Validators

Mon, 16 May 2016 09:53:42 GMT

First off, what is Business Foundation (BF)?

BF is basically a meta system where you can define an entity type and its properties. But it doesn’t stop there, the main differences between BF and the “regular” meta system in Commerce are that you can define relations between your meta classes, and that there’s a management UI you can extend and modify without changing any code. Sounds easy, but unfortunately not very well documented.

The management UI basically consists of views for displaying the data and forms for editing the data. Whenever an entity is saved, using the UI or using the api’s, the data is validated using a set of configurable properties and validators. So why implement you custom validation when it's right there in front of you, and used both by CM and all your application code.

Every meta class is represented in the mcmd_MetaClass table where the class level data is stored.

The field XSValidators contains XML data defining how the fields in a meta class should be validated. For each field you may define the validator implementation to use along with some validator specific properties.

Below is a partial sample from the Contact meta class.

<?xml version="1.0"?>

<ArrayOfValidator xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Validator TypeName="Mediachase.BusinessFoundation.Data.GuidFieldValidator, Mediachase.BusinessFoundation.Data">
    <Params FieldName="ContactId" AllowNull="False" />
  </Validator>
  <Validator TypeName="Mediachase.BusinessFoundation.Data.DateTimeFieldValidator, Mediachase.BusinessFoundation.Data">
    <Params FieldName="Created" AllowNull="False" />
  </Validator>
  <Validator TypeName="Mediachase.BusinessFoundation.Data.StringFieldValidator, Mediachase.BusinessFoundation.Data">
    <Params FieldName="FullName" AllowNull="False" MaxLength="200" />
  </Validator>
  <Validator TypeName="Mediachase.BusinessFoundation.Data.EnumFieldValidator, Mediachase.BusinessFoundation.Data">
    <Params FieldName="CustomerGroup" AllowNull="True" EnumTypeName="ContactGroup" />
  </Validator>
  <Validator TypeName="Mediachase.BusinessFoundation.Data.ReferenceFieldValidator, Mediachase.BusinessFoundation.Data">
    <Params FieldName="PreferredShippingAddressId" AllowNull="True" />
  </Validator>
  <Validator TypeName="Mediachase.BusinessFoundation.Data.BooleanFieldValidator, Mediachase.BusinessFoundation.Data">
    <Params FieldName="MyCustomBool" AllowNull="True" />
  </Validator>
</ArrayOfValidator>

As you see there are a variety of validator types, and not all properties can be managed in the Business Foundation management UI. Also, when setting up a large e-commerce project which might need deployments to several different environments we'd like to automate the setup of these validators but that's another story.

A validator is defined using ntype names and assemblies making it possible to create custom validators implementing IFieldValidator and IValidator. Yay :)

But first, let's take a look at the existing validators.

AllowNull is a parameter used in most validators and defines whether or not to accept a null value.

StringFieldValidator

This validator is used to validate a string input.

Maxlength defines the maximum char length that may be input. Note that this is just a validator, make sure not to allow a string longer than you can actually store.

RegexPattern is a nifty property where you can define a regular expression to validate the input against.

For example, if you create a string field in the BF management UI and select the format "e-mail" the RegexPattern would be set to \w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)* which is in my opinion far too basic. Just pop in a new regex and you're all set :)

Other use cases could be to validate phone numbers, postal codes, allowed chars for name fields and so on. Also, there is no MinValue property so you could easily use the regex property for validating your minimum string length.

GuidFieldValidator

This validator is used to validate if the input is a valid guid. If the value can be parsed to a guid it's valid.

BooleanFieldValidator

Validates if the value is of boolean type.

DateTimeFieldValidator

Validates if the value is of DateTime type, and checks the below properties if present.

MinValue - can be used to set the lowest allowed value

MaxValue - can be used to set the highest allowed value

For birth dates MinValue and MaxValue could be used to limit how young or old contacts that may be created, or if we would store for example a member date we wouldn't want to have dates from before the member system was created. If you would like to disallow dates in the future you could create your own validator and add a property for enabling/disabling future date validation.

CurrencyFieldValidator

Validates if the value is of decimal type. Not sure why it's been named CurrencyFieldValidator since it's just a basic decimal validator.

DecimalFieldValidator

Works the same as the CurrencyFieldValidator but also has MinValue and MaxValue properties to limit the minimum and maximum value that may be entered.

DoubleFieldValidator

Works the same as for decimal but validates if the value type is double. Also accepts MinValue and MaxValue.

IntegerFieldValidator

Works the same as for decimal but validates if the value type is integer. Also accepts MinValue and MaxValue.

EnumFieldValidator

Validates if the value maps to a value in an enum meta field.

EnumTypeName is used to define which meta field to compare the input value with.

IsMultiValue defines whether or not multiple values may be input. If not accepting multiple values correct input type would be int or string, and for multiple values input types would be int[] and string[]

FileFieldValidator

Validates if the value is of type FileInfo.

ValidationExpression property allows you to specify a regex to validate the file name againts.

IdentifierFieldValidator

This validator is a bit weird, it validates if the value is of type MetaIdentifierValue or of type string.

If the type is string any value is valid which makes me confused of the use case.

ReferenceFieldValidator

Validates if the value is a PrimaryKeyId

Hello world :D

Mon, 02 May 2016 11:44:03 GMT

I guess I've been too lazy, and had too little time, to blog but now I've decided to grab the monkey by its ass or whatever the saying is. Having worked with web based applications since 1998, and e-commerce since 2001, I think I've got alot of interesting challenges and experiences to share.

Maybe you've seen me on some meetup or event the past few years, if not maybe we'll meet next time. Whenever there's a party.... Jokes aside, with 3 small kids at home I can't attend all the happenings but I'm at least trying :P

During my time in the business I've tried on a few different hats - developer, DBA (mainly Oracle and MySQL), infrastructure, server platforms (Linux since kernel 1.0.2, *BSD, Solaris, Windows), architect, CTO. On top of that I've founded and run a couple of own business, some quite successful and some not so successful but hey, it's been a blast and I've learned from it either way.
I've also been involved in a couple of startups, breaking new ground with techniques and applications not commonly used by web projects, and I've also found it very stimulating to do whatever neccessary to get the project forward regardless of techniques what role is stated on your contract.

My epi journey started in 2006 when I did my first CMS implementation. Wheter it was Skånemejerier or ProViva I can't remember. Since then I've worked with epi every now and then, mixed with other platforms such as Litium, Magento and Umbraco. The past 3 years I've focused 100% on epi for commerce implementations though, and in my current position as CTO at the e-commerce division at Knowit I face interesting epi commerce challenges daily so I guess I have the coming blog topics covered.

Now the intro's done I guess, if there's anything you wonder or would like to comment please feel free.