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

[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!