Closed SimonBiggs closed 6 years ago
A key issue with the implementation of this will be the fact that the html being rendered will be flexible. Previously if the html/markdown ever changed it was only because the file itself changed. This was coped with by refreshing the whole form.
A form refresh everytime the jinja template updates won't work. Therefore I need to decouple form component initialisation from the page loading sequence. This will be quite a refactor. This refactor will however help for a range of outstanding issues.
@OxygenLithium @robmarkcole any thoughts on this idea?
What is the use case?
It is for advanced use cases. Not expected to be used in basic scenarios.
It makes what is displayed on the screen be significantly more flexible. For example, certain parts of the form can be conditionally displayed. Other parts of the form can be repeated as needed.
Forms could start quite sparse and then have the content of the form that is displayed on the screen grow conditionally depending on user input.
If this is a good idea, and if after implementing it it seems to work well, then I shall expand to refactoring the form structure to also be a jinja template. The default one will be used as standard and the majority of users need not know it is there, however the template used by scriptedforms will be able to be swapped out. I can then use these templating options to customise scriptedforms into a documentation layout. Therefore making the documentation itself simply be a customised scriptedform.
So instead of locking the layout away and making it rigid, I will be exposing the form layout and styling as a overridable jinja template.
Understood, I can certainly see the benefits of this approach, so long as the basic usage maintains the currently simplicity
Yup. Keep the basics simple. A major draw of ScriptedForms is its initial simplicity.
I just want to push it further however and take the lid off the top for those who want to make it do more. ...and if I can make the documentation itself be a ScriptedForm, that would be ideal.
I really like this idea. How would someone use jinja to change the colour of a button for instance? Would it be that the user can define the colour in Python and then that variable is input into the HTML?
I've actually been thinking further about this. And I think what you've been keen on is actually something a bit different.
I think what you really want is top level access to the css. And I think I've worked out how to do it.
I should be able to also make that cover button color etc. I'll keep you posted.
Won't implement Jinja2 something like this feature will still be implemented however. Just not like this.
Alright, so, to help begin addressing the following issues:
I will be attempting to create a
<jinja>
component. The idea/hope is that it will be able to work as so: