form elements should be constructed from a template, and not in-code

[fiammybe]

The calendar uses javascript that dates back to 2005. We need to have an updated implementation, that can be configured to integrate with the choice of front-end technology (jquery, bootstrap, material, react, angular, ...). Most calender implementations use javascript, so if we can define the output that or calendar will give, to integrate easier in the frontend technology, that will be great. Different plugins handled by composer can be an option : a plugin 'impresscms-plugin-calendar-bootstrap3', that handles (in PHP) the inclusion of the correct files, and also the generation of the specific html and javascript code to run the calendar.

[MekDrop]

idk if we should not refactor any similar components with some JS framework like Vue... :/ F.e.: https://www.iviewui.com/components/date-picker-en looks good and maybe has more power than we could provide with our resources.

[fiammybe]

vue would be an option, certainly. The thing is that the calender component should be able to work with the frontend system of choice by the website. If website A wants to use Bootstrap 3 for example, they could use the calender module for bootstrap 3, if website B wants to use Vue for their frontend, they can use the calender module for vue2. The backend should be as frontend-agnostic as possible, to use a difficult word :-) First step is to see what the data is that the calender needs to work, and put that in a generic calendar php module. Then the next step is to have several frontend modules that transform and use that data to be used on the frontend.

[MekDrop]

That would be awesome but I'm bit afraid that if we do for any possible CSS/JS system, we could stuck for very long time. There are too much possible options. Also support such variety could be real hell. I think probably something should work out of box and could be easy reusable. And in most cases we should recommend to use only one way. Maybe we could provide tool that convert in to our thinking way but not all possible variants.

[fiammybe]

Yes, we shouldn't be the ones providing all the modules :-) Just the php part that needs to be generic enough, and a reference implementation for 1 or maybe 2 frontend systems. We should be as loosely coupled as possible on frontend technologies, because if vue2 is replaced by vue3, we don't want to have to rewrite half the frontend :-)

[MekDrop]

Mixing Vue, React, Angular, jQuery and other frameworks could give another problems. Sometimes these frameworks interacts with each other in some strange ways. So, if theme has one framework and module other user could get some unexpected results. I think that would be worse option. Probably most ICMS users will not much to look in the core if that happens. Same, I think goes to CSS frameworks.

Vue 2 from Vue 1 doesn't differs so much. Angular also back to path where releases doesn't looks so different. ReactJS is also pretty stable. Also there are some other frameworks that could be used for us. I think we could just select one and start to use for ICMS 2. If we need to switch in something we could that do in ICMS 3 and so on. This will be also a clear path for developers. They could easier select choices for developing new modules or themes. Maybe this would less that would be impressive but it would work with less pain and that also is impressive.

[fiammybe]

I changed the title, because that is the underlying solution : the theme should be able to override totally how the elements in a form are rendered. Our current solution predates HTML5, and as such is lacking many elements that modern themes are using to work. In essence, the render() function of the form elements should use a template, and that template should must be overridden in the theme if you want.

[fiammybe]

I don't know the best way to call the template from the form classes. If I have 1 example I think I can take care of the rest.

[skenow]

So, are you considering using a separate template file for every element? 'checkbox.tpl' for example?

[fiammybe]

Yes, I think that is the most flexible way. And in a certain way, the template is currently more or less in the ‘render’ function.

[MekDrop]

Probably we could use another way how to solve this problem not direct templates but instead fully implement HTML5 form fields. I mean generated form field should provide correct types like date, time, number and some classes. In that case these standard fields could be extended from theme with JS, CSS help if user needs some custom functionality.

f.e.: to extend date field we have something similar like

<input type="date" name="mydate" value="" />

user could use something like this:

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/bootstrap-datepicker/1.8.0/css/bootstrap-datepicker.css" />
<script src="https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/4.3.1/js/bootstrap.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/bootstrap-datepicker/1.8.0/js/bootstrap-datepicker.js"></script>
<script>
$('[type=date]').datepicker();
</script>

for beautiful checkbox:

<label class="checkbox"><input type="checkbox" name="bt"><span></span> Beautiful checkbox </label> 

we could use such css code:

.checkbox input[type="checkbox"] {
  display: none;
}
.checkbox input[type="checkbox"]:checked + span {
  background-color: blue;
}
.checkbox span {
  display: inline-block;
  width: 16px;
  height: 16px;
  border-style: solid;
  border-width: 1px;
  border-color: blue;
  background-color: white;
  overflow: hidden;
  content: ' ';
  transition: background-color 0.5s;
}

I think this would more clean way to let theme designers change some default icms functionality for build-in forms.

[fiammybe]

The way I was thinking about is to make it easy to use an existing theme (Bootstrap or something else) that you buy somewhere, and integrate it as easy as possible in 1.4.x. To do that, most of the time you want ImpressCMS to generate very specific HTML code in order to work with the theme directly. No CSS overrides, no extra Javascript to write, and not so much work to take what is in the different classes and pull out the render function into a template. If I want to make the backend fully Bootstrap 3 or Bootstrap 4 compliant, it is currently not possible. That was the trigger 😊

[MekDrop]

Bad thing with this idea templates are now database based. So performance could decrease significantly if we use for such small things. At the moment I think it would be easier to use overrides - it's easier in theme js and css replace some values than redo our templating system.

[fiammybe]

Wouldn’t the caching of templates take care of this? Once you created your form the 1st time, every form element should be pre-created in the cache I think

[MekDrop]

Sadly, that is not always a case. It's works if caching is enabled but that is not by default. Otherwise I think it tries to look in db first if there are some changes. Maybe we could improve that for 2.x but I don't think so that I would like find some free time to look for that in 1.4.x. In any case I think if we decide to go with your option, we should rethink how templates works.

[github-actions[bot]]

This issue was automatically marked as stale