So Fano doesn't have an opinion on the folder structure. But Fano does have an opinion on the folder structure.The framework and CLI must always be clearly stated then. Although it's rather unconventional to have a framework without any particular structure.
Getting started also requires setting up Apache, mod_Xcgi and root access for setting up virtual hosting. That's just too much to ask for up front. Who sets up CGI just to try things out these days?Indeed, the fpWeb way of getting started is as simple as:
CLI is good for showing off "go from git cloning this repo to having a running hello world web app in 1 min, with source code templates for routing, controllers, views, models and so on all set up". But the Apache requirements totally get in the way. The framework should just run a Pascal web server directly to serve the web app being built.
So Fano doesn't have an opinion on the folder structure. But Fano does have an opinion on the folder structure.Maybe after the developer created the new CLI tool they forgot to update the documentation, or if you don't use the CLI then your folder structure can be whatever you choose?
Getting started also requires setting up Apache, mod_Xcgi and root access for setting up virtual hosting. That's just too much to ask for up front. Who sets up CGI just to try things out these days?Yes, this was my gripe as well when I went through the tutorial. I ran it all inside an LXC container, so I wasn't too worried, but was still a bit struck by it. It is kind of nice that it can auto-generate apache VirtualHost configuration like it does, making deploying to a server pretty easy, but running a deploy tool as root is never recommended. I'd prefer it just spit out the config files to a build or output directory, then let me use whichever deployment tools I choose to put all the pieces together. There's just a bit too much magic happening under the hood for comfort.
CLI is good for showing off "go from git cloning this repo to having a running hello world web app in 1 min, with source code templates for routing, controllers, views, models and so on all set up". But the Apache requirements totally get in the way. The framework should just run a Pascal web server directly to serve the web app being built.
I've only learned of Fano Framework's existence as of yesterday and actually lost sleep because I went to bed later as I was curious about it. At first glance, it shows a lot of promise. Has modern features that remind me of both Django and Ruby on Rails. It seems like it has the potential to be a killer app for web development for ObjectPascal, but parts of the documentation make it seem unfinished.
However, the lack of documentation in these areas could be a valid reason why the ObjectPascal userbase hasn't really grown. As not everybody is willing to deep dive into someone else source code to learn how stuff works, and would rather read a document from readthedocs.io instead.
Waiting for a sponsor\donor to offer a bounty (https://wiki.lazarus.freepascal.org/Bounties) in order to have a fully operational and working CRUD example inside fpWeb...This is rather simple and indeed fpWeb isn't tied to any kind of CRUD mechanism, you're free to use whatever you want. Combining with SQLdb is straightforward.
It's maybe pretty straightforward. But the point is that the weblaz.lpk and weblazextra.lpk code source packages - containing the THTLMDatasetContentProducer, ... , i.e. the equivalent of Delphi's TDataSetProducer - and all the TClasses\objects implementing in Pascal the DOM-<html> tags, are present, written. But without any more minimalist working application in order to handle a visual CRUD example of a simple SQL table management on the internet. I'm just saying that it's a damage. To manage small SQL tables, there's no need with such javascript-side database engines to produce a weak html visual result, at the end.AFAIR Michael as their author also didn't use them. I didn't remember the motivation to make them, but anyhow he's the same as me, we use fpWeb without any componentization, only pure hand coding. I'm not sure with the future of those, so maybe ask Michael?
Something else to note, which may not bother everyone, is that it lacks any Lazarus integration.
Fano first requires building a CLI tool.
The getting started page says "Fano Framework has no opinion about your project directory structure. You can structure your project directories and files the way you like. However, Fano CLI creates several files and directories that follows certain assumptions."
So Fano doesn't have an opinion on the folder structure. But Fano does have an opinion on the folder structure.
if you don't use the CLI then your folder structure can be whatever you chooseCorrect
Yes, this was my gripe as well when I went through the tutorial. I ran it all inside an LXC container, so I wasn't too worried, but was still a bit struck by it. It is kind of nice that it can auto-generate apache VirtualHost configuration like it does, making deploying to a server pretty easy, but running a deploy tool as root is never recommended. I'd prefer it just spit out the config files to a build or output directory, then let me use whichever deployment tools I choose to put all the pieces together. There's just a bit too much magic happening under the hood for comfort.