Requested Improvements for developer experience with Freedom UI pages

Freedom UI pages do make many things easier/better for the no-code experience, but the developer experience has suffered as a result in some aspects, at least as it exists in 8.0.6. The following are items that are needed to improve the dev experience when working with Freedom UI pages:

  1. Naming attributes for data source columns as column name (Must have)

    This one is critical. Currently, when you add a column to the page, it adds an attribute for the column in the viewModelConfig, however, it adds it as something like "FieldAttribute_yxzhag" instead of the field name, such as "UsrTheField". This means, if you're going to read or set values in that field from page handlers, you have to check what the attribute name is and use request.$context.FieldAttribute_yxzhag = "Some value", rather than using the actual field name as request.$context.UsrTheField = "Some value". This makes writing code for a Freedom UI page extremely difficult (or at least a huge pain). I do understand how the attribute names need to be unique and there could be attributes from the page and list data sources with the same name, but we desperately need a better way. My proposal would be to have primary data source attributes named as the field names (the editor could check if the same field is added twice to the same page and reuse the existing attribute). Any attributes added for non-primary data sources could get prefixed with the data source name (and would be fantastic to have consistent data source names as well. The primary always being named PDS and any list/lookup data sources named something like "ObjectNameDS"). Or at minimum, a built in set/get function that would lookup & translate the attribute name based on a provided data source path.
  2. Objects created in page editor must allow for naming the object code (Must have)

    Currently, if you use the page editor and create a new object you cannot change the object code to give it a proper name and instead the object is named something like "UsrObject_xhsggy". This is a critical thing and honestly a deal breaker. This has to change to allow for naming objects. It's a lot of extra steps to create the objects separately in the configuration and then use in the page editor.
  3. Methods on page to organize code (Nice to have)

    There needs to be some way to organize code outside of handlers. For example a methods node where methods can be added. If you were going to be handling 20 change events for things on a page, as it is now, you would have 20 if blocks all in the "crt.HandleViewModelAttributeChangeRequest" or you would need to have 20 separate "crt.HandleViewModelAttributeChangeRequest" handlers in order to organize or separate the code. Neither one is ideal and leads to the page code becoming a big mess. I started trying adding a methods node, with methods inside, to viewModelConfig, which worked great - however, that breaks the visual page editor. As it is now, I put page logic in modules that is called from the request handlers, but that seems like a lot of unnecessary work for code that is only needed for a given page. I get that this opens a big topic of whether the functions would need to be inheritable, which is what the request handlers are supposed to replace, however, I would settle for those functions only being considered a way to organize code, as an extension of sorts for the handler implementations (and not inheritable)
  4. Built-in reference for devkit on pages (Nice to have)

    Since it's common to need to use devkit, rather than needing to add "@creatio-devkit/common" to the AMD modules on every page, it would be nice to have a built in reference on the page, available via something like request.sdk or request.$context.sdk etc
  5. Adding esversion jshint to Freedom UI pages (Nice to have)

    For Freedom UI pages, the ability for the correct esversion for jshint warnings is needed. Currently, if you add a comment to the page schema /* jshint esversion: 11 */ this is removed any time you open the page in the editor
  6. Inheriting/extending anglular UI components (Assumption/question)

    Since everything is componentized in the angular Freedom UI pages, I assume, hopefully correctly, that there is, or will be, some way to override angular components to extend the application beyond the editor and page view model. Extending things like crt.ContactCompactProfile, crt.AccountCompactProfile, crt.ActionDashboard, crt.AppToolbar, etc.
  7. Would be nice to add to the rendered markup information about the components (Nice to have)

    In non-Freedom UI pages, it is extremely useful to be able to look at the rendered HTML of a page and you can tell what the component on the page is called, what the name of it's container is etc. For example in classic Creatio, inspect the top-right corner and you'll find out that the schema name there is MainHeaderSchema. This makes locating things and knowing what to look for very easy. All of this is lost with the angular components since those names are not a part of the rendered markup. It would be very nice/useful if that information could be somehow included in the resulting markup.
  8. Using additional/other icons (Nice to have)

    It would be great if we could specify different mat-icon icons rather than using only the list of icons provided. The icon names don't appear to translate exactly to mat-icon names, it would make things much easier if it did so we could just change the name to a different one in the viewModelDiff.

Thank you. Also, kudos for so much amazing work on the new page editor and reducing the things needed as a dev task that can now be accomplished as a no code task!



Thanks a lot Ryan for this detailed push, lots of great ideas needed to be implemented ! :)

Definitely Ryan, these features will make the life of an developer lot easier like with vesion 7.18.x.

The current version is a blessing for no code approach but not that much for cutstom development approach.

Hello Ryan,


Thank you so much for your ideas.


We've registered it in our R&D team backlog for consideration and implementation in future application releases.


Thank you for helping us to improve our product. 


Hello Ryan,


Thanks again for such structured and comprehensive feedback.


I want to clarify a few things:

3. Methods on page to organize code (Nice to have)

If you are developing complex custom logic, it's better to organize it using npm packages and developing in the file content. Right now we have the documentation about implementing a remote module and business logic using the custom input component as an example. I think we will publish more articles on this topic to cover more cases. Also, we have plans to make developing in npm packages easier.


4. Built-in reference for devkit on pages (Nice to have)

Yes, it's common to have devkit when you are developing. At the same time, only a small portion of all pages have custom business logic. If we reference devkit on all pages, it will be redundant and produce more performance usage in some cases.


6. Inheriting/extending anglular UI components (Assumption/question)

We are moving forward to web components. This allows us to provide faster system updates, integrate more components to Creatio (on Angular, React, Vue and others) and use this best practice for composable apps. They are much more independent elements that have strict API and configuration possibilities.

If you want more customization options for a certain component, it's better to create a separate request for those specific options.

Also, if you want to create your custom component that will include some Creatio components, we have plans for that in our roadmap.


7. Would be nice to add to the rendered markup information about the components (Nice to have)

For what purpose do you want to locate things?

If you want to find a container or some control code (name) inside the page, then it's possible in the page designer. You can select any element and see its code in the "Advanced settings" area of the right settings panel.

If you want to find schema, it's still in the markup as the first child of the "crt-schema" DOM element:


2. Objects created in page editor must allow for naming the object code

Now, if user is creating a new datasource, the object code can be changed

in the right settings panel for this datasource:

It can be done until this object is saved to the database (until you save the page).


Also, it's possible for the new dropdown (lookup) fields and objects for them:

Oleksandr Khardikov,

That is excellent news. I assume this is 8.0.7? I believe the release notes mention something about this, so hopefully we'll see it soon. 


Ryan Farley,

it's present in 8.0.7, but I think it has already been

available for some time now.

Oleksandr Khardikov,

Hmm. Might be something new, in 8.06 I do get the three-dot button to edit details of the data source, but it doesn't allow me to change the object code - which I'm fine to not edit it as long as I can set it when it's created). At least knowing it's coming is good news.


Show all comments