Create a central code repository to allow code sharing within the Application

(Mark Wonsil) #1

Central Code Repository: Instead of custom client DLLs, allow users to upload shared code to one place and then have that code be callable by BPMs or Configurator Methods. This promotes the DRY principle - Don’t Repeat Yourself. Have the code stored in one place, it’s audit-able, it can be source-controlled, and easier to upgrade since it can be reviewed with automation.

Shared Code in Customizations and BPMs
Improve Logging
(Haso Keric) #2

This one is a complicated one but let’s just focus on BPMs right now.

If we could Create a Shared Code Location even if its for the time being Lambdas/Funcs/Actions and Reference it in the BPMs like-so Ice.ExecuteSharedFunction(“YourGistName”, [ Array of params ]); or even have the Compiler In-Line it. Support Shared LINQ Expressions.

Atleast we can Maintain it at 1 location instead of Duplicating it.

Stuff Like:

// Initialize Logger
string LogFile = "";
Action<string> log = (m) =>
    if ( !string.IsNullOrEmpty(LogFile) ) {
        Ice.Lib.writeFileLib.FileWriteLine(LogFile, string.Format("{0} - {1}", DateTime.Now, m));
    else {
// Initialize Helpers
Func<string, string> CleanFileName = (fileName) => {
    return System.IO.Path.GetInvalidFileNameChars().Aggregate(fileName, (current, c) => current.Replace(c.ToString(), string.Empty));

// You could of course Func a Query in

(Evan Purdy) #3

This seems very similar to this other suggestion: Create a central code repository to allow code sharing within the Application

(Haso Keric) #4

Ah howd I miss it, Maybe @josecgomez can merge it

(Jose C Gomez) #5


(Chris Conn) #6

A friendly bump - this does not have enough votes!

In the use case I am thinking of right this moment, I have several little features\functions I use on many of my customs. An example is a way to store and display a version number in the caption - I am sure most of you have been in the situation where you are wonder what version of a custom is loading for a user. Instead of having to finagle every custom I start, if I had this global code base I could access, it would make it much easier to implement something like this and many other time savers.

I would note the global code should get a context passed into it, so you could write funcs to affect the caller.

(Mark Wonsil) #7

DRY - Don’t repeat yourself!

(Chris Conn) #8


(Mark Wonsil) #9

But you’re right @Chris_Conn. Imagine having some well-tested code that can be used by BPMs, Configurators, Directives, etc. If you change it in one place, it’s changed everywhere. It would make staying current so much easier.

(Jose C Gomez) #10

I have done this via UBAQ write a UBAQ that performs some function then invoke that UBAQ from Customization or BPM or REST

Granted this is a hack

(Chris Conn) #11

Any port in a storm I say - creative solutions are acceptable in my book. The biggest drawback I see with that is not having the context of the caller (really a pointer to the caller - particularly in the case of a form)

(Jose C Gomez) #12

UBAQs have callcontextclient and bomdata

(Chris Conn) #13

Ah so you are saying pass the form in thru call context?

(Jose C Gomez) #14

It passed automatically via callcontrxfclient

(Chris Conn) #15

Really?! Like the form as an obj? I just learned something.

(Jose C Gomez) #16

Lol not the whole form just which form