Replies: 3 comments
-
If the UI framework can reduce dependencies or be easy to separate, that's wonderful. |
Beta Was this translation helpful? Give feedback.
-
1- Bootstrap centric The main issue is that when a content item is rendered using a theme, even if a theme only contains a layout we need to render something for each part and field. It requires some balance between being able to render something that looks good and something that is not dependent on any class/tagging. For the TitlePart for instance it's easy, we just need an I assume you understand the dilemma here, but I with we could do something better. For instance maybe we could use some pretty standard tagging, with custom classes that could be used to customize it, while at the same time provide a set of templates that are framework specific, that devs could use when starting new templates. This means that for TheBlogTheme which is based on Bootstrap, we would have to copy these sample templates in the theme. We could then have the same ones for Bulma or Foundation. And it would also have a file for the Flow grid. It's like having base theme for each framework, though copy-pasting the templates is also a good solution. 2- Fluid vs Razor Fluid is a necessary solution for admin-side templates., no discussion. Razor is "my" preferred solution for file-based templates, but several users have given the feedback that they prefer Liquid for these too, either because it's easier for designers, or because it lets them use the same language everywhere. I prefer Razor because I get intellisense, and it's easier for me to write custom code. Also it's faster because it's compiled instead of being interpreted. I assume the issue here is that all front-end templates that ship OOB are on Liquid. blame @jtkech for that ;) How it happened is that Liquid has been added as an option for the the file based templates, then to validate it TheBlogTheme was converted to liquid, then TheComingSoon was created using the same basis by another contributor. So it's not really a project preference but mainly based on each contribution. What do you suggest here? Duplicate all themes in both Razor and Liquid such that there is no actual preference at the project level? |
Beta Was this translation helpful? Give feedback.
-
Thank you, Sebastien for the detailed answer
I agree, having UI Framework agnostic templates would not help much as they would have to be replaced by the ‘real’ ones. I doubt that to have them solely as starting point would help much, except for that they are free of the UI dependent stuff.
To replicate complete themes for Bootstrap, Bulma, Foundation using Razor and Liquid would mean to maintain six versions with about the same content. I don’t think that this would be funny 😊
But what about
* Project templates for the CLI. They could serve as starting point and they could contain pointers to the documentation.
* The doc could contain guidance about leveraging different UI frameworks
* A YouTube video demonstrating the required steps. Something like “Building a theme for Orchard Core from scratch” (https://www.youtube.com/watch?v=wtAIgn4gYXc&t=456s)
* In O1 it was possible to add CSS classes within the admin UI. Maybe such a tooling could be helpful for adding the classes needed to support a different UI framework
These are just ideas. I think I cannot give THE answer.
I just expressed my findings as I tried to use orchard with Bulma.
Regarding the preference of Liquid over Razor, I am glad to read that I am wrong. I would suggest to have one of the fully functional themes (TheAgencyTheme or TheBlogTheme) be using Razor. They are quite similar, so one could see the difference between Liquid and Razor and it would prove that either languages will work if used the right way.
Von: Sébastien Ros <[email protected]>
Gesendet: Montag, 31. Dezember 2018 23:12
An: OrchardCMS/OrchardCore <[email protected]>
Cc: dschmid <[email protected]>; Author <[email protected]>
Betreff: Re: [OrchardCMS/OrchardCore] Templating issues I had (#2962)
1- Bootstrap centric
The main issue is that when a content item is rendered using a theme, even if a theme only contains a layout we need to render something for each part and field. It requires some balance between being able to render something that looks good and something that is not dependent on any class/tagging. For the TitlePart for instance it's easy, we just need an <h1> tag. For a form element however, the size of the field, the label location and style, checkboxes, all these will depend on the framework we use. And because the default rendered html is targeting bootstrap, it looks fine when your theme also uses bootstrap, or you have to override all the form elements to define a new template that matches your framework. Now let's assume we are way less opinionated and render framework-agnostic html. Forms elements will look nicer than before, but will probably not match your tagging either and you will still need to create custom templates for each element.
I assume you understand the dilemma here, but I with we could do something better. For instance maybe we could use some pretty standard tagging, with custom classes that could be used to customize it, while at the same time provide a set of templates that are framework specific, that devs could use when starting new templates. This means that for TheBlogTheme which is based on Bootstrap, we would have to copy these sample templates in the theme. We could then have the same ones for Bulma or Foundation. And it would also have a file for the Flow grid. It's like having base theme for each framework, though copy-pasting the templates is also a good solution.
2- Fluid vs Razor
Fluid is a necessary solution for admin-side templates., no discussion. Razor is "my" preferred solution for file-based templates, but several users have given the feedback that they prefer Liquid for these too, either because it's easier for designers, or because it lets them use the same language everywhere. I prefer Razor because I get intellisense, and it's easier for me to write custom code. Also it's faster because it's compiled instead of being interpreted.
I assume the issue here is that all front-end templates that ship OOB are on Liquid. blame @jtkech<https://github.com/jtkech> for that ;) How it happened is that Liquid has been added as an option for the the file based templates, then to validate it TheBlogTheme was converted to liquid, then TheComingSoon was created using the same basis by another contributor. So it's not really a project preference but mainly based on each contribution.
What do you suggest here? Duplicate all themes in both Razor and Liquid such that there is no actual preference at the project level?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#2962 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMkJx1zozg9LWq5QXkrmVU6-J0QP9nvHks5u-ovKgaJpZM4Zlc91>.
|
Beta Was this translation helpful? Give feedback.
-
I tried to create a template for Orchard core. I started with disabling JQuery and Bootstrap. Instead of JQuery I would want to use Vue.js (http://vuejs.org) and instead of Bootstrap I decided to use Bulma (http://bulma.io). Here are just some difficulties I had to fight with:
Over all Orchard seems to be too much Bootstrap centric. Forms, for instance, are very difficult to leverage without bootstrap. There apparently are many
Fluid seems to hide Razor. The documentation seems to favor Liquid and the example themes/templates are written with Liquid. As far as I can see, Liquid is useful to create templates on the fly within the admin UI. I don't really understand the preference for Liquid templates within the Blog and Agency themes. For me it does seem like an additional layer of difficulty, including the loss of IntelliSense. I would wish some more advices to leverage 'pure' Razor syntax.
Am I the only one observing those problems? How would the best way be to get arround those?
Beta Was this translation helpful? Give feedback.
All reactions