Open Deepwalker opened 9 years ago
Can you propose something in Pull Request that can be used to achieve this goal? For example, we can use Jinja2 and other template engines in he same way. It will be a decoration over the template engines with the same external interface.
By the way, we can do the same for Model layer by adding multiple ORM implementations and use the same interface to interact with them. For example, two developers can use different ORM depends on their needs or qualification. Don't sure that mess of different libs inside one project is a good idea - but it will open the doors to flexibility and allow to integrate other projects with different libs (ORM, template engines) to our existing project and use it without code changes.
@Deepwalker do you have any updates for this issue? I wish to release full-featured version of Python on Rails in coming weeks. You can help me to speed-up this process.
I can write separate ActiveView, that you can include to project as view layer. With support for jinja2, mako etc. Not sure if will be able to make all them interchangable, like in rails, but will try.
@Deepwalker thanks. I will push my changes to a View
in coming days. Please check updates before you will push your changes and create Pull Request.
Our main goals now - create interface to use Model (#5) and View layers. It means that customer can select any ORM (SQL Alchemy, SQLObject, etc) and any Template Engine (Jinja2, Mako, etc). When we will do this - we can release a first stable version of the Python on Rails.
Added support for Jinja2 templates. Updated example blog app to use these templates.
Hi, I have something for you – https://github.com/Deepwalker/backslant
Actually, if you plan to implement Rails somehow, you need to provide something like ActiveView – one rails project can use wast amount of different view builders and all of them are interchangeable and play nice together.
And in backslant I really did play well with jinja2 – both using iterators inside (generators actually), and its damn simple to make them play well together.
Today I wrote simple thing to support include backslant templates into the jinja templates:
Its simple to add special case to jinja2, that will eliminate this staff, and will support just generators.
And this is damn simple proto – any view lib must support simple protocol – it return view instance that supports generator protocol.
And we have two libs that almost support it. Backslant actually did, and did it way simpler then jinja2.