Ptah Q & A¶
What is scope of Ptah?¶
Ptah aims to provide a framework which makes low level choices for developers so the programmer can get on with solving their problems on a unrealistic deadline.
ptah.cms is an API it is not an applictaion. The API does not have advanced CMS functionality such as staging, workflow or versioning. That is someone elses job.
Ptah is a framework, an implementation and set of opinions around the Pyramid web framework.
Ptah, like Pyramid, supports both URL dispatch, traversal. Unlike Pyramid it provides a data model, content heirarchy, form library, and high level security primitives (permissions, roles, and principals). Any of this is additional to Pyramid and augements your application.
Where does Pyramid and Ptah differ?¶
Ptah attempts to provide a “full stack” on top of Pyramid whereas Pyramid urges you to find and use individual libraries.
Why does Ptah not use deform?¶
Ptah does not use deform; but you can. Ptah ships with a form subsystem,
ptah.form which you should give a shot.
Why does Ptah use a Folder paradigm?¶
Ptah does not require a Folder paradigm or containment. examples/ptah_minicms demonstrates the features of ptah.cms and one of those features are content hierarchies. Thus the Page/Folder experience in ptah_minicms.
Why does Ptah use sqlite?¶
Ptah uses SQLAlchemy which supports many different database drivers. sqlite ships with Python obviating the need to install a separate database daemon. ptah.cms will not depend on database specific features to gain performance or scalability.
SQLAlchemy is complex and scary¶
SQLAlchemy is a comprehensive library and an effect of that is it can feel overwhelming when reviewing the documentation. SQLAlchemy is the best thing we have in Python.
Traversal is not required. It is optional. It is a feature which can you use if you like. Traversal works quite well & if you have used Apache - you have used traversal - instead of a database Apache uses a filesystem.
Layout vs. Macros/Inheritance¶
Layouts are 100% optional. They provide an alternative for template inheritance. Layouts are renderer independent. This means you can use Jinja, Chameleon, & Mako with the Layout subsystem.
Several reasons exist for Layouts:
- A layout is a view with a template. This provides a encapsulated template and view. Meaning a template which is used as a layout has its own view (methods, data, etc).
- The contract between layouts is a string. Layouts can only be passed a
contentstring which is the result of rendering the “inner” block.
- Since layout’s work from the “inside-out” there is a desirable side-effect, by the time the <HEAD> layout is rendered all static assets (CSS, JS) that are requirements for form elements or for your custom view will have been computed. This is not possible to do generically with the ZPT/MACRO or the Jinja inheritance system.
- Layouts can be context dependent. This is a advanced usage. It is unclear if this is possible with other template composition mechanisms. This is a feature you will most likely need or use or understand why it is needed.
Getting a pkg_resources.DistributionNotFound: myapp Exception¶
This means that you did not run
python setup.py develop on your package. This is Python and you need to add your
package to the python path/virtual environment. e.g.:
$ bin/pcreate -t template mypackage $ cd mypackage $ ../bin/python setup.py develop $ ../bin/pserve settings.ini
Where did Paster Go?¶
ptah 0.1 used Pyramid 1.2 and Paster. Pyramid 1.3 removed the dependency on Paster and rolled the functionality directly into the pyramid framework. pcreate and pserver are scripts which are now generated by Pyramid.
(OperationalError) no such table:¶
Previously to ptah 0.3; all of the tables were created automatically without intervention. As of 0.3 you explicit must bootstrap your schema using
$ virtualenv/bin/ptah-populate settings.ini
ptah-populate script takes the .INI settings file as a parameter. Once this completes you will be able to start your application. For details check
Data population chapter.