Wish List - New Configurator Version - single source BSV

ACDC

When developing an application that is intended for multiple customers very often there are some slight changes in the form layout or even additional rules on the object that need to be carried out.

These changes necessity that the developer fork the BSV so the custom changes can be accommodated, eventually leading to multiple BSV versions having to be maintained for each customer

Ideally the developer wants to have one BSV as the source application and then export the bsv into the relevant customer BSV version.

If the configurator application included a place to record BSV names and then we are able to assign Default Forms and Object Rules to a relevant BSV name that would get rid of the need to maintain multiple versions of the same BSV and make life a lot easier.

So in the left hand tree view of the configurator if support introduces an additional level on the Object Rules and Forms that shows exclusively assigned forms and rules against specific BSV names that would be an excellent feature. So it’s like a mini fork within the main source application.

We currently have a feature that lets us switch off a rule, maybe this can be extended to only run the rule if it is assigned to an exclusive BSV name – and the same goes for the form – if it is exclusively assigned to the BSV name it becomes the default form of the BSV in operation.

Does this make sense, would love to hear other opinions - having to maintain multiple BSV versions for the sake some basic changes does not make sense, especially in complex business applications

4xjbh

Sounds like an interesting idea and clearly described. All 'I' can say is 'condolences' for having to maintain separate BSV's like that. Do you drink more at version distribution time?

aware_support

You need to check out the "User Defined Processes" feature.

ACDC

I am not sure how one would use a User Defined process to disable an existing rule on the object. If I create a new rule on the Object with User Defined Process it may conflict with an existing rule. So I would want to disable this rule ( in fact I was not aware that you could add a new rule to an object this way )

Besides, this method would not let you change a form in any way. If a customer wants some custom attributes on a form or a simple layout change , I am forced to start thinking of forking the BSV. I could make provision in the source BSV and make use of form access levels, but that would be very cumbersome and complicated

This is a very real problem for developers who provide B2B solutions, being able to have a single source is vital. Rolling out additional functionality in the configurator to support this seems very obvious to me.

Also, the "Team Developer" logistics when developing a single app in an AwareIM environment is very different and support for being able to segment a single BSV source to serve multiple BSV versions of the source would be a game changer and also work towards an efficient pseudo-multi developer functionality ......for me at least

aware_support

We have some real apps using User Defined Processes feature extensively to enable functionality for customers that is not included in the core BSV.

In most cases this is functionality they are after, not form layout changes. If they want some custom attributes - just add some dummy ones to your core BSV and let them use these custom attributes.

RLJB

I can only image it is very difficult to implement ACDC's suggestion, however we find ourselves in exactly the same situation and would benefit immensely from being able to manage a single source BSV as described.

Interestingly, we have built our business model, pricing structure, internal resources and versioning methods around the limitation of having to fork and support so many BSVs. We have in fact made this 'limitation' into a business advantage, however maintaining and undertaking changes (like the upgrade to V7) turns in a massive undertaking that does hurt, and as we are continually growing in client numbers will only hurt more.