Skip to content
Browse files

Doc fixes.

  • Loading branch information...
1 parent e90ac83 commit f2a7c6f3d5a0e5facc7631aeb81532be39c9e1fc @jayd3e jayd3e committed
Showing with 13 additions and 13 deletions.
  1. +1 −1 README.rst
  2. +10 −10 docs/startup.rst
  3. +1 −1 docs/tutorial.rst
  4. +1 −1 docs/unique.rst
View
2 README.rst
@@ -68,7 +68,7 @@ You should read the source of myapp, after all it is your application. A good p
Another example
---------------
-Ptah101 scaffold generates a simple application which has an example form, view, a model called Link. Ptah101 is meant to get your feet wet. There is a more sophiticated example in the Ptah301 scaffold. If you have not written a Pyramid application and/or you are not familiar with traversal do not attempt to use Ptah301.
+Ptah101 scaffold generates a simple application which has an example form, view, a model called Link. Ptah101 is meant to get your feet wet. There is a more sophisticated example in the Ptah301 scaffold. If you have not written a Pyramid application and/or you are not familiar with traversal do not attempt to use Ptah301.
Let's uninstall the ptah101 egg, myapp::
View
20 docs/startup.rst
@@ -52,17 +52,17 @@ Optional. If you are using ptah.make_wsgi_app some extra features are available:
This function returns a WSGIApp.
-I have 2 ways to do register?
+I have 2 ways to do registration?
-----------------------------
Yes. But its easier to think about it this way. Pyramid is a agnostic
web framework. Ptah is a application/web framework with opinions.
Ptah registration revolve around services (uri resolvers, models and a
type system). These ptah registration's are application specific and
-have no such equivilent in Pyramid (nor should they).
+have no such equivalent in Pyramid (nor should they).
Where is ptah.config used?
--------------------------
-Everywhere. But you never touch it. There is always formal API that is defined and (will be( documented. The internal implementation uses ptah.config implementation.
+Everywhere. But you never touch it. There is always formal API that is defined and will be documented. The internal implementation uses ptah.config implementation.
Some examples:
@@ -113,7 +113,7 @@ Currently ptah differs in Pyramid in the following ways.
- config statements do not have context (but will in 1.4?)
- - config statemetns talk about concrete services of *pyramid* ala
+ - config statements talk about concrete services of *pyramid* ala
route, views, etc. not high-level application services such as
model registration.
@@ -123,10 +123,10 @@ Currently ptah differs in Pyramid in the following ways.
In ptah there is a
more formal 2 stage configuration, registration stage and apply stage.
-It loads all packages and can be introspected and then a applying
+It loads all packages and can be introspected and then applys
the configuration to the environment. Why? An example:
-URI implementaiton is a dictionary which maps the uri scheme / key
+URI implementation is a dictionary which maps the uri scheme / key
to resolver callable. {'crowd+user':ptah.crowd.userProvider}. If an
add-on package defines an additional URI resolver, what will happen when
we load the external package:
@@ -147,10 +147,10 @@ we load the external package:
- Another possibility is unloading this configuration. In future we may have a add-on ecosystem where you will want to "unload" registrations.
- - registeration/apply are runtime features of ptah.config and maybe in future there will be remove registrations.
+ - registration/apply are runtime features of ptah.config and maybe in future there will be remove registrations.
More thoughts
-------------
-Pyramid is explicit. ptah is sort-of implicit and has indirection. For instance ptah needs to scan packages with the entry-point ptah. Pyramid would need to expose this functionality for ptah to plugin its own higher-level registration calls (uri, type system, etc).
-Also Ptah/ptah reuse ptah.config in a lot of places. The pattern
-of having an public API which advertises the functionality but internally uses the ptah.config implementation - is inspired from Pyramid.
+Pyramid is explicit. Ptah is sort-of implicit and has indirection. For instance Ptah needs to scan packages with the entry-point ptah. Pyramid would need to expose this functionality for Ptah to plugin its own higher-level registration calls (uri, type system, etc).
+Also Ptah/ptah reuses ptah.config in a lot of places. The pattern
+of having a public API which advertises the functionality but internally uses the ptah.config implementation - is inspired from Pyramid.
View
2 docs/tutorial.rst
@@ -4,7 +4,7 @@ Ptah Walkthrough
You should have virtualenv with ptah installed. Let's create an add-on::
- ~/venv/src$ ../bin/paster create -t ptahdemo mypkg
+ ~/venv/src$ ../bin/paster create -t ptah101 mypkg
~/venv/src$ cd mypkg
~/venv/src/mypkg$ ../../bin/python setup.py develop
View
2 docs/unique.rst
@@ -96,7 +96,7 @@ it is flat. We have 2 attributes we use for mapping on to heirarchies:
ptah_cms_nodes.parent_uri and the ptah_cms_content.path columns. The path
attribute is how we efficiently do fast look ups. Walking parent/children
relationships in a RDBMS is inefficient, say, compared to graph databases such
-as ZODB or Neo4J. RDBMS arent graphs. The REST API is another example of this
+as ZODB or Neo4J. RDBMS aren't graphs. The REST API is another example of this
mantra.
REST as First Class Citizen

0 comments on commit f2a7c6f

Please sign in to comment.
Something went wrong with that request. Please try again.