I followed this steps : https://docs.wappler.io/t/server-side-includes-ssi/2864 except that the file i include is a html file.
On Wappler design editor i see the included component. But when server is running and i go to the page on my browser i don’t see the included component. I only see < ! --#include file=“components/header.html” - - > in the code inspector. Do you currently manage the rendering of the included file on server? Or what do i need to do in order to see my rendered component instead of the comment which is supposed to be used on server side to render it? Of course i can easily do that on server side, but i don’t think it’s the goal here. Thanks in advance.
We are still finalizing the NodeJS support and the way it should handle SSI or other server side rendering with template engines.
So it is still under development
3 Likes
It’s funny but the internal browser is actually importing current SSI correctly(even with JS) but external browser doesn’t. Any particular reason for this?
Wappler design view knows about all kind of SSI and just includes them.
But the browsers don’t of course and this is usually done server side.
With node all files in the public folder (which is your web root) are threaded as static files and directly served without any processing. If it has to process and parse any file for possible SSI it will add a performance hit to the node server.
This is because theoretically you can map this public folder to more performand web servers like Nginx and use node as application server only.
So we have two choices:
-
Create a separate folder inside the app root for dynamic files that will be processed. This is called usually “views” in node
-
Add support for EJS template engine and just call your dynamic files from the web root with extension .ejs. So that the node server knows that they need preprocessing. This is a bit what also PHP does.
So we are looking for the best way now.
Ah. So Design view is cheating and has a wallhack! I thought the design view when on preview was just a normal browser without an aimbot. Thanks for the explanation.
Indeed. Static files shouldn’t be served directly from node. Waste of resources and a security concern. I was already working on nginx as reverse proxy until I read your post on the approaches you are considering.
Edit: Look what I was checking out before I read your reply.
1 Like
I’ve been fiddling with both alternatives and I think EJS seems like a good choice.
Not only you solve the SSI but you set the grounds for this:
(Pending AC integration if it’s decided to be implemented). But at least it’s usable in code.
Using .ejs files will also seem more natural to people transitioning from PHP as you say.
Route to ejs file
app.get('/mypage', function (req, res) {
res.render('pages/mypage');
});
Then inside mypage.ejs
<%- include ('partials/mypartial') %>
And bam SSI…plus templates…with layouts, pages and partials.
I just finished migrating my i18next SSI using ejs partials and it works out of the box.
3 Likes
That is exactly what we plan to do 
2 Likes
I don’t know if this will be useful or not when you start integrating ejs with Wappler, but this is how I am structuring my app being ported to nodejs with ejs as templating system.
And the changes I had to do to make it work.
server.js
...
app.set('view engine', 'ejs');
...
routes.js
Changed file send for rendering. Static are served from public folder so just having the file extension html as set in config.js seems enough for Express to look into the public folder when routing.
...
if (route.url) {
app[route.method || 'get'](route.path, (req, res) => {
res.render(route.url);
});
}
...
...
//View route. It will look in the the default /views folder
{
"path": "/register",
"url": "pages/authentication/register"
},
//Static route. It will look in /public as file extension is html
{
"path": "/settings",
"url": "/settings.html"
}
...
Edit: Obviously I will port yet again to follow whatever requirements are needed by the final implementation. But as I just wanted to fiddle with ejs I thought I would share my structure strategy.
1 Like
We have almost the same implementation as you. We will use ejs as view engine. Templates will be located in the views folder, so the same as your example.
The routes will be a bit different, here an example what can be added to the routes.json
// static route
{
"path": "/about",
"url": "about.html"
},
// view route
// template is the ejs to render
// data (optional) is the serverconnect action that is used as data source
{
"path": "/register",
"template", "auth/register",
"data": "auth/register"
},
// serverconnect route
// exec is the serverconnect action to execute
{
"path": "/data.json",
"exec": "data"
},
// redirect
{
"path": "/oldpage",
"redirect": "/newpage"
}
Routes to serverconnect actions will also be auto generated and are available under /api/{action}.
Files in the public folder are directly accessible, also without the .html. So /about.html is accessible under /about. The root path / will automatically look for index.html as default.
3 Likes
Those additional keys make a lot of sense. Thanks for the extended info.
I can continue with the porting knowing that I can easily adapt what I do now to the final implementation.
It also gives a good head start to those that also start porting now.
I suggest not to make changes in the js files from us, but create you own. Then require them in the index.js. We probably going to support an easier way to implement your own code.
Code currently in the index.js:
const server = require('./lib/server');
server.start();
server has the following properties:
server.server: http.Server instance
server.app: express app instance
server.io: will give access to socket.io when implemented
server.start(): starts the server
So you could change the file to:
const server = require('./lib/server');
require('myServer')(server);
server.start();
and then have a myServer.js like:
const favicon = require('serve-favicon');
const path = require('path');
module.exports = (server) => {
// custom code here, for example add your own express middleware
server.app.use(favicon(path.join(__dirname, 'public', 'favicon.ico')));
};
This should be the best way at this moment, we try not to change the index.js and other files are being changed almost every update. Also if the index would change, it only holds a require to your implementations, so that you do not loose your custom code. Of course this can change since it is still being Beta.
2 Likes
hey guys! I think you are thinking to jump to 4.0 before wappler 3.0 is over
3 Likes
Actually I was not planning at all deviating from the standard you implement. When you release the final version I will adapt my structure and logic to fit in your implementation.
I just modified these file only to be able to continue working on the port. What I meant was that I am glad I saw your plans for ejs and SSI because I can revert fairly easy my current implementation to fit it into yours.
Although again, the extended information is very helpful now and for the future. So thanks for that.
Edit: Actually I did implement your suggestion because I see myself using this in the short term. Double thanks!
Looking forward for that. Would that be exclusive to nodejs server model or are you talking generally?
It is specific for the nodejs server model, with php and asp you could just upload your own php/asp files and it worked, with node this is different.
1 Like
or 5.0 , internal docker is the next big one I believe
2 Likes
SSI is part of Wappler.io concept, currently if you use SSI with nodejs project you will see that it’s not working, however it’s present on the interface. With php project SSI is handled, they added nodejs and SSI is not handled and they are working to make nodejs project work as well as php project. So i think that are thinking about making the v3 beta a stable version. Because 3.0 is not over if such thing as SSI is not implemented.
1 Like
I think it was a joke and had nothing to do with SSI actually
1 Like
Just not everyone has a Meme Master badge… 
1 Like