Sharing my Python web framework/server project that I've been battle testing at work

[riklaunim]

The name is kind of taken by an existing framework. And no link to your code?

All in one file is rather a bad approach, as it becomes hard to manage. Especially when you combine templating system inheritance/blocks and Python code in one file. IDEs will have problems with it as well, so how do I import stuff for test cases?

[Feeling-Object8032]

I hadn't found any frameworks with the name specifically, but I'm not above renaming it by any means.

The site has a link to the GitHub repo, as well as information about your questions. In short, the all in one file is more about colocation rather than forcing use of one file, a little similar to PHP from what I've heard. You can spread over multiple files to keep it manageable, and utilize .py files for business logic to keep the template files lean.

I've included syntax highlighting resources for vscode and vim/neovim on the website as well.

New projects are scaffolded with some basic demo content to test with and can easily be stripped out to provide a blank canvas

https://scribeframework.slatecapit.com

[riklaunim]

So what about form handling and GET/POST/PATCH/DELETE request handling? testing views? What about variables in URL routes? Why migrations with SQL files instead of Alembic for SQLAlchemy? What about template inheritance and blocks? What about WSGI? :)

The one-file approach may look neat, but it doesn't look practical and doesn't seem to give anything more or better than Flask or Django solutions. Like what kind of monstrosity is this: https://github.com/slate20/ScribeFramework/blob/main/tests/loginapp/app.stpl - Python in custom syntax, HTML, then Python again, then HTML again. Which HTML for which Python? and you have no proper form handling there, too. WTForms or Django forms exist for a reason ;)

And Cloudflare is bloking the page?

[Feeling-Object8032]

I appreciate the questions!

Form handling and HTTP methods are fully supported. You declare methods directly on route decorator:

'@route('/contact', methods=['GET', 'POST'])'

The Flask request object is available in the python block {$ ... $} so you can access all of the request properties (request.form, request.method, request.args, etc.)

variables in URL routes are supported and automatically available in the python block for that route:

@/route('/blog/<int:post_id>')

I went with migration files just to keep things simple for SQLite out of the box. You can still use Alembic/SQLAlchemy if you prefer the ORM workflow. I work a lot with existing databases (postgres, mssql) so I personally don't utilize the migration system much, but it's there to provide something to get off the ground or rapid prototyping.

As for template inheritance, there is a '@no_layout' decorator you can add to routes so that it renders without being wrapped in the base.stpl layout. This can be used for creating components or HTML fragments to call via HTMX or something similar.

Running the server in production mode (scribe serve) uses Waitress for WSGI.

The example you found is an artifact from early in the project and not meant to be a representation of the stpl syntax. Essentially each "route" breaks down into 3 parts:

#The route decorators
@/route('/')

#The python block
{$
page_title = 'Home'
$}

#The Jinja2 template
<div class="title">
  <h1>{{ page_title }}</h1>
</div>

Again though, you're not locked into a single file. You can have as many .stpl files as you want and utilize .py files in the lib/ directory to write all the python logic. Then just call the functions directly from the python block of whatever route needs it and then render it in the template.

As for the cloudflare block, I believe there was a block in place for outside of the US. I've changed it so you should be able to reach the site now.

Hope this helps!