I want to Create a Button in Freedom UI that is visible in all the attachments for all Freedom UI Sections. In Older Version, we do by replacing the FileDetailV2. Here How do I able to do that?
Those buttons at the top of the attachments area are separate from the actual attachments list component (they are a part of the page, not the list). To add a new button there that will show for all Freedom UI pages with attachments, you actually have to modify the base page type that those buttons are defined in. The item to override is "PageWithTabsFreedomTemplate", I believe. Once you override that base page type you can use the visual editor to add the button to the top of the attachments tab on the right side tabs.
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
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:
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.
I want to add a custom upload icon to the attachments on Freedom UI pages. It seems the default icons given were from angular material (mat-icon). Is there a way to add a custom icon ?
Our responsible R&D team is informed about the need of this functionality and consider implementing it in the upcoming releases, but there is no ETA as of now.
Unfortunately, it is impossible to set up an action "Select multiple records" in your custom section. But this task has already been assigned to our R&D team.
We have registered your proposal and forwarded it to our R&D team for consideration in future releases.
I'm just getting started working with the new Freedom UI. One thing I'm not able to find any information on is if the new Freedom UI supports mini page popups. If not, is there a something that has been deemed a suitable replacement for that? If not, any plans on the roadmap to add support for this?
Unfortunately, the support for mini pages for Freedom UI is not released yet. I created an idea for our developers to adopt this functionality in the future.
