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:
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.
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.
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)
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
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
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.
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.
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 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.
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:
It would be nice to delete some lookups data (e.g. Cities, Product type, Units etc) from Base packages. It allows not to waste time for initial cleaning and will not add these data again with updates.
These data can be provided on Marketplace as additional packages
It would be nice to add one more 'Delete&Bind' action to Sections, Details, Lookups etc. Id's of deleted records should be bound to the package and deleted on other environments as well when package is installed.
it would be great to have a progress page regarding update releases for partners, because the delivery time between the release notes of an update and the actual availability of update files are inconsistent.
To be able to read (weekly?) progress and update availability would be great to handle customer expectations.
Let me mention that "Release date" of a specific version can be tracked in the "Release notes" article directly on our Academy, for each new release version a corresponding article is created.
Installation files of a new release version is always available in approximately 14 days from the release date, once final testing is completed (and successful) by our responsible R&D team.
If you are interested in a specific query for functionality implementation registered for our R&D team and would like to have an update about it, you can contact our support team using support@creatio.com so we will be able to update you about the progress. As of now, the progress of such queries are being tracked only directly in our system.
But we've registered a corresponding query for our R&D team to consider your suggestion.
Status of actual release date of installation files - not released as of the 7th of December (that's 34 days after release date announcement, more than double the approximate time to installation release )
General communication done to partners - none (please correct me if I am wrong)
Release date of next release 8.0.6 : 13th of December (public event - in less than a week)
You can see with the timetable here above of events, why clients are asking questions about 8.0.5 not in production while 8.0.6 is already presented next week.
It would be great to have a more consistent dashboard of communication - new section in partner portal for example?
Seeing I have a couple likes and a comment - it feels that your current update process and communication around is not really fullfiling partner needs.
Do I really need, for each release, to guesstimate a release date of installation files, guesstimate progress, have to systematically ask support for information ? Feels like an unproductive process 😭
Re-upping the demand, it's the 16th of January, a month since the 13th December release. Seems we're slightly off track the "2 weeks from release date announcement "availability for 2 releases in a row ( well more if you consider some instances are jumping from 8.0.4 to 8.0.6) - An update progress page readable by partners seems more than relevant ...
thank you!
It is very useful for Partners to know all bugs already found in Creatio in order to give excellent support for customers. Otherwise we spend our time for researching of each case instead of just finding the situation, reason and status in the full list
