Storing html components in database - html

I want to store html components of my website in the database in order to let the user choose from a variety of components each time
for example :
one page styled html page with a navbar and about section that could be changed and other stuff , it's layout could contain the following :
<div id="nav-holder">
<!-- Nav html goes here -->
</div>
<div id="about-holder">
<!-- about section html goes here -->
</div>
<!-- other html stuff -->
My db now is structured to hold the template with it's possible components for each section , and is storing a 'text' in it's html column , and I am adding all my styling and scripting to one sheet and js file that is loaded for the whole layout.
Is there any best practice to store and render those components in my db ?
Edit :
My main purpose is to create a website generator with some customization , providing a set of templates that the user chooses and within one template he can customize his template by choosing different components (navs,about sections , ... )
Also I will grab the data from some place and fill it into those templates The user will not be able to modify the data here , it's ready already so there is no need to give the user the ability to modify the data that would be filled in the document

Is there any best practice to store and render those components in my
db ?
Yes, don't! For several reasons, the primary one being that you use your database to persistently store variables related to models. Not html. The place for your html is in your views, the place to make choices as to which html to show is in your controllers.
Other reasons include that reading your html from a database will slow down your apps responsiveness and Rails tends to make text from a database html safe, meaning it will not automatically behave as html. This is a security precaution as a very common attack is to insert 'bad' code into your database which then gets run when you recover it and supply it to an unsuspecting user.
Use partials. Reference section 3.4 of this Rails Guide
Save the users choices of components in the database. If he chooses navbar_23, you store that 9 character string in the database and on request, your template serves him the partial named _navbar_23.html.erb from your views folder.
For example, in your views folder, create a subfolder views/navbars, inside that place your variants of navbars. Partials start with an underscore and end with .html.erb
In your model, store the users choice of navbar in say user.navbar. Just the name, not the starting underscore or .html.erb
In your template;
render partial: "views/navbars/" + user.navbar
Rails will automagically add the underscore and .html.erb when it looks for the file.

Related

Email Template Dynamic Rendering

Developing email templates for a react application that basically populate basic information from app such as customer name and store name, then get sent to customer to log in to complete purchase process. The company has 4 brands so I created four separate email template with the appropriate logos and images. My question is, would it be possible/better to create just one template and use JS to load the correct images and text in? Or is it better to keep the four templates separate and create logic to determine which template to send?
If you know that you will never have to customize the content of each 4 separate brands' emails, you can use one file and dynamically populate the correct branding info. This will require you to write less code, so is a plus for efficiency and cleanliness.
However, that means you can't change the layout for one brand specifically if you need to. Unless you were to create another template for the actual body of the email which differs from brand to brand, which is basically the same as having 4 separate templates initially.
I would keep them separate to allow customization if you need it.

Views in Drupal 8 / Preprocess Function

I've a question about Drupal 8, again and again and again...
Today, I've two views displayed on my front page and this two views display two differents informations types (in the first : Last articles in a caroussel, in the second : Recents events like a calendar with date and little description).
So, I would like to know if it's possible to template those views differently (two types) ?
Template those with preprocess functions ?
Or
Template those with templates files and template each field of those views ?
If your template is not complex, you can simply add in your views a field of type Custom text.
In there you can write HTML, use your fields (replacement patterns) and even use twig for custom logic.
*Make sure you have all the fields you need hidden.
*Make sure the field "Global: Custom text" is the last field in the list.
Another way is to create a theme by following the naming convention (see the docs here

How to best transfer a document to a SAPUI5 framwork?

I'd like to achieve the following and I'm looking for ideas. I have a document and I want to represent/transform this content in/to a nice SAPUI5 framework. My idea is the following: a split app with having the paragraph titles in the master view (plus a search function on top) and the respective content in the detail view.
I'd like to know from you if
a) you might want to share your ideas and hints on alternatives.
b) this can be achieved within one single file (i.e. all the code for the split app and document content in one html) and maybe using pure html code (xml also feasible) - against the background of easily handing a large amount of text available in html.
c) if you happen to have/know a reusable template.
Thanks in advance!
An interesting question. I went through a similar exercise once, re-presenting my site with UI5.
To your questions:
(a) I would think that the approach you suggest is a good one
(b) You can indeed include all the app in a single file, I do that often by using script templates, even with XML Views. You can see some examples in my sapui5bin repository, in particular in the SinglePageExamples folder. Have a look at this html file for example: https://github.com/qmacro/sapui5bin/blob/master/SinglePageExamples/SAP-Inside-Track-Sheffield-2014/end.html
What I would suggest is, rather than intermingle the document content and the app & view definitions, maintain the content of your document separately, for example, in XML or JSON, and use a client side model to load it in and bind the parts to the right places.

Ckeditor Fixed HTML Structure

Is it possible to have a fixed structure for the HTML using CKEditor. For example, HTML5 placeholders are shown in editor as user hints so user know where to enter what content. Further, it should be possible that user shouldn't be able to change the structure.
An example structure may look like this and placeholder text is shown till user enters the text.
Title Only
....
...
...
As mentioned above, user shouldn't be able to change the structure/order of the sections.
This is a perfect use case for a CKEditor widget.
In short, widgets are special rich content units in that they are groups of elements which are treated as a single entity inside the editor. Once developed, their structure (but not necessarily their content) is immutable and enforced by the CKEditor instance they are used in. These entities can thus be selected and deleted or moved freely as a whole around the editing area, keeping their predefined structure intact. At the same time all the individual parts of the widget (its "building blocks") can be edited or configured separately, again, without affecting the whole widget entity and its structure in the process. Read more here: http://docs.ckeditor.com/#!/guide/dev_widgets
In your case, you could have a look at the sample Simple Box widget which is demoed here and actually created step-by-step in this tutorial. It creates a simple template widget with an immutable structure and pre-defined fields for the users to fill in. What's more, thanks to ACF (CKEditor content filtering mechanism) you are even able to define the elements (and their attributes, styles, classes) that are allowed in each of the widget parts.
Widgets are a really powerful tool, you can see some other implementations of the widget API in the widget demo.

JSP - how to render html(or jsp) code from database

I have a jsp that is being used by multiple user groups. The requirement is that each User group wants a customized look and feel when they access the page (with a distinguishing parameter). We are proposing to allow the Users to dump the html that they need in a database table and the jsp will determine the User group and they display the corresponding html. Any pointers on how this can be done?
Example: if User group 1 access the url abc.com/xyz?param=aaa, then the jsp should display the html that is stored in the database corresponding to UserGroup1. similarly, abc.com/xyz?param=bbb should render the html stored for UserGroup2.
html for Group 1:
<html>hello, user 1 </html>
html for Group 2:
<html>hello, user 2 </html>
How does my JSP get this html code from Servlets or any other classes?
Any JSF 2.0 suggestions are also welcome.
The above example code might sound simple, but in reality the entire layout, images, borders, tables, content will be different
distinguish between users through the use of session and manage it by its API
IMO, i would not store html in the DB. It is not where it belongs.
What you can do (in JSF 2.0) is create a 'template' page that contains basic things that you reuse on each page...header,body, footer, css, js, etc.
On this 'template' page, you can use the <ui:insert name="body"> tag to define places that each page will define.
On your pages, you use the <ui:composition template="whateverPage.xhtml"/> to define your template. Then you can insert the code you want based on whatever params using <ui:define name="body">
JSF 2 Templating with Facelets
instead of saving entire html which is not recommended as phanneman says,
save a css or css snippets . for example save in your db, the image paths for each user, color, etc in the db for each user.
this might help by retriving the specific data for each userGroup.