Grok社区文档1.2版：全面指南与技术细节

版权申诉

116 浏览量更新于2024-06-15 收藏 1.4MB PDF 举报

Grok Community Docs Documentation 是一份详细的文档，针对 Grok 这个 Python Web框架的用户和开发者提供了全面的指导。该文档发布于 2010 年 11 月，由 The Grok Community 编写，主要涵盖了 Grok 的核心功能和实现细节。 1. 关于 Grok 文档 - 1.1 节介绍了文档的目的，旨在帮助用户快速上手 Grok，了解其设计理念和架构，以及如何高效地构建基于 Grok 的Web应用。 - 1.2 节着重讲述文档的构建过程，包括如何维护和更新文档内容，确保信息的准确性和一致性。 2. 数据访问与存储 - 2.1 部分指导开发者如何在 Python 代码中访问静态目录中的内容，这对于资源管理至关重要。 - 2.2 索引和搜索功能在 ZODB（对象数据库）中的应用，有助于高效检索数据。 - 2.3 介绍 Megrok.rdb 和 SQLAlchemy 的基本 ORM（对象关系映射），用于数据库操作的简化。 - 2.4 提供了 Grok ORM 与 Storm 数据库集成的示例，展示不同的数据库选项。 - 2.5 演示如何让 Grok 与 CAS (Central Authentication Service) 通信，实现身份验证和授权功能。 3. 安全与认证 - 3.1 阐述了 Grok 如何支持用户认证，确保系统的安全性。 - 3.2 探讨了 Grok 在认证和授权方面的策略，帮助开发者设计更复杂的安全系统。 4. 视图、模板与客户端交互 - 4.1 精心讲解 Fanstatic 资源管理，便于管理和分发前端资源。 - 4.2 提供了一个 KSS 插件示例，展示了如何利用 Drag-and-Drop 功能。 - 4.3 z3x.form 与 Grok 的结合，说明了如何创建和处理表单。 - 4.4 讨论如何在视图中处理子路径，提升用户体验。 - 4.5 介绍如何在 Grok 中添加 AJAX 功能，增强前端与后端的交互。 - 4.6 自动表单生成机制，节省开发时间。 - 4.7 Grok 对 RESTful API 的支持，方便API的设计和使用。 - 4.8 详细解释了 XML-RPC，一种远程调用协议在 Grok 中的应用。 - 4.9 关注表单的工作原理，以及如何在 Grok 应用中正确处理它们。文档深入浅出地介绍了 Grok 框架的各个方面，无论是初学者还是进阶开发者都能从中获益匪浅。通过阅读这份文档，用户可以掌握 Grok 的核心特性和最佳实践，从而更有效地构建功能丰富的 Web 应用程序。

Grok Community Docs Documentation, Release 1.2

def findMe(self, mini, maxi):

q = value.Between((’content_index’, ’published’), mini, maxi)

query = getUtility(IQuery)

r = query.searchResults(q)

return r

This also shows how to ﬁnd a catalog, which is useful if you want to check statistics on the index or need to update

(reindex) the index.

If you want to index datetime properties, there is a datetime normalizer which I never got to work. Instead I did

something like this.

from zope.interface import Interface

from zope import schema

class IPublished(Interface):

published = schema.Int(title=u’Normalized datetime’)

def _minuteNormalizer(dt):

tmpin = dt.utctimetuple()[:5]

multi = (535680, 44640, 1440, 60, 1) # Resolution in minutes

value = sum(i

j for i,j in zip(tmpin, multi))

return value

class Published(grok.Adapter):

grok.implements(IPublished)

grok.context(MyObj)

def _published(self):

return _minuteNormalizer(self.context.published)

published = property(_published)

class SitePublishCatalog(grok.Indexes):

grok.site(MyApp)

grok.context(IPublished)

grok.name(’my_catalog’)

published = Value()

The SitePublishCatalog uses the IPublished() adapter to convert the datetime property “published” to an integer. In

order to perform a query you will need to normalize your parameters too. Don’t forget timezones or you might get

unexpected results. I use the “pytz” egg to get preconﬁgured timezones.

from pytz import timezone

d_mini = datetime(2010, 1, 1, tzinfo = timezone(’CET’))

d_maxi = datetime(2010, 12, 31, tzinfo = timezone(’CET’))

q = value.Between((’content_index’, ’published’), _minuteNormalizer(d_mini), _minuteNormalizer(d_maxi))

query = getUtility(IQuery)

r = query.searchResults(q)

2.2.7 Learning More

The “hurry.query” package contains the DocTest “query.txt” that shows how to perform more complex search queries.

10 Chapter 2. Data Access

Grok Community Docs Documentation, Release 1.2

2.3.3 Imports

Note: You can ﬁnd another ( and eerily similar :) ) example of this setup code in megrok/rdb/tests/initialization.py in

your eggs-dir.

To get started we need to import some packages and modules:

import grok

from megrok import rdb

from z3c.saconfig import (EngineFactory, GloballyScopedSession)

from z3c.saconfig.interfaces import (IEngineFactory, IScopedSession, IEngineCreatedEvent)

2.3.4 Connection string

We will be using Oracle as our database for this how-to, however it should cover pretty much any DB SQLA supports:

DSN = ‘oracle://username:password@database_name’ My DSN is a bit different than others as it relies on Oracle

TNS for some of its information, speciﬁcally the host.

Create your DSN by following the guidelines from SQLA:

"The URL is a string in the form dialect://user:password@host/dbname[?key=value..], where dialect

is a name such as mysql, oracle, postgresql, etc."

For postgres it should look like:

DSN = ’dialect+driver://username:password@host/database_name’

So if you use psycopg2 for your adapter, you’d have ’postgresql+psycopg2://...../database_name’

For more info on SQLA connections please consult the SQLA docs.

2.3.5 SQLAlchemy engines and scope

Now that we have a connection string we must setup an SQLA database engine, for this z3c.saconﬁg has provided us

the tools:

engine_factory = EngineFactory(DSN, echo=True)

grok.global_utility(engine_factory, provides=IEngineFactory, direct=True)

Consult the z3c.saconﬁg code to examine the inner workings of EngineFactory, but it’s main purpose is to provide an

SQLA engine. Notice too that we have set echo=True, this turns on SQLA output so you can see what it is doing in the

background. When you are satisﬁed all is well, just set it to False or remove it all together. We must also register our

engine factory as a global utility, generally we are making it available globally, and more speciﬁcally so megrok.rdb,

can get at it through the utility machinery.

Similarly we must also setup an SQLA session, again z3c.saconﬁg to the rescue:

scoped_session = GloballyScopedSession()

grok.global_utility(scoped_session, provides=IScopedSession, direct=True)

In our case the scope is global, making the session ubiquitous in our app. You are not required to to this, you are

also able to scope it by site using SiteScopedSession(). Again consult the z3c.saconﬁg code for more speciﬁc details,

particularly about scope. Moving on, we register the session as a utility to make the session available to the utility

machinery scoped as we like.

12 Chapter 2. Data Access

Grok Community Docs Documentation, Release 1.2

2.3.6 Metadata and EngineCreatedEvents

Generally metadata is how SQLA keeps track of your classes and mappings. Here is where things can get trickier.

In most cases, you are going to only need one set of metadata. However there are special cases to consider, particularly

for our example. So we will create two(2) sets of metadata.:

skip_create_metadata = rdb.MetaData()

create_metadata = rdb.MetaData()

Notice the names, the reasons for this are forthcoming...just note them for now.

Continue by setting up our events:

@grok.subscribe(IEngineCreatedEvent)

def create_engine_created(event):

rdb.setupDatabase(create_metadata)

@grok.subscribe(IEngineCreatedEvent)

def skip_create_engine_created(event):

rdb.setupDatabaseSkipCreate(skip_create_metadata)

Feel free to delve into how events work at your leisure, we simply need to know the basics of what’s happening.

Grok subscribes to (watches for) the EngineCreatedEvent, and when it happens, executes some code, in our case

rdb.setupDatabase() and rdb.setupDatabaseSkipCreate(). We have two(2) events, one for each set of metadata.

So, why both sets of metadata? Why both events? For Postgres, existing views, existing tables and tables dynamically

created from your classes are all handled by rdb.setupDatabase(). SQLA recognizes all reﬂected objects as already

existing and doesn’t try and create them. But with Oracle(and our example) if you reﬂect an existing view into some

metadata and pass it through rdb.setupDatabase(), not only will SQLA reﬂect your views, it will also try very hard

to create them as tables in your DB. This is bad. The views already exist, right? So, we need a solution, which is,

hold them in a separate metadata, pass the proper metadata to rdb.setupDatabaseSkipCreate(), which skips the creation

attempt, leaving you with your views reﬂected as you’d expect.

It’s up to you how you handle reﬂected tables in this case. SQLA will recognize those as existing and skip the create

for you. Go ahead and put them in whichever metadata you like, as either will work. Dynamically created tables,

however, must be held in the metadata passed to rdb.setupDatabase() so that they are created for you.

2.3.7 The Complete Conﬁguration

Combining all the previous code our conﬁguration looks like this: (oracle_cfg.py):

import grok

from megrok import rdb

from z3c.saconfig import (EngineFactory, GloballyScopedSession)

from z3c.saconfig.interfaces import (IEngineFactory, IScopedSession, IEngineCreatedEvent)

DSN = ’oracle://username:password@database_name’

engine_factory = EngineFactory(DSN, echo=True)

grok.global_utility(engine_factory, provides=IEngineFactory, direct=True)

scoped_session = GloballyScopedSession()

grok.global_utility(scoped_session, provides=IScopedSession, direct=True)

skip_create_metadata = rdb.MetaData()

create_matadata = rdb.MetaData()

2.3. Basic ORM with megrok.rdb and SQLAlchemy 13

Grok Community Docs Documentation, Release 1.2

@grok.subscribe(IEngineCreatedEvent)

def create_engine_created(event):

rdb.setupDatabase(create_matadata)

@grok.subscribe(IEngineCreatedEvent)

def skip_create_engine_created(event):

rdb.setupDatabaseSkipCreate(skip_create_metadata)

2.3.8 Mapping our Classes

The heavy lifting is ﬁnished and megrok.rdb, et al, did most of it for you trust me. Now we can start developing our

mapped classes.

First, we import any modules we need and our metadata:

from megrok import rdb

from sqlalchemy import Column, ForeignKey, Sequence

from sqlalchemy.types import Integer, String, Float

from sqlalchemy.orm import relation

from oracle_cfg import (create_matadata, skip_create_metadata)

Next, we create a container, you’ll notice a striking similarity to grok.Container:

class TestSA(rdb.Container):

pass

The container does what you might expect, it contains objects. Certainly, it does more than that and there are more

container options than what will be presented here but we’ll save that is for a future how-to. If you don’t want to wait

and you have to know it’s full functionality now, use the source. You can ﬁnd this in the eggs-dir under megrok/rdb/

in interfaces.py and components.py

Next we create our Models, these will be our mapped classes. Again these are similar to their Grok counterpart

grok.Model and you can ﬁnd information about them in the same place as rdb.Container. In our ﬁrst Model we will

describe a reﬂected view. The actual Oracle view name is “sales_part” it is made up of numerous columns and holds

data that describes, you guessed it, parts that are available for sale.:

class SalesPart(rdb.Model):

"""

Reflected view, notice the metadata used is the same as the one passed

to rdb.setupDatabaseSkipCreate(), Don’t run create_all() on this

metadata SQLA will see this as a table that needs creation and try and

create it in the DB, which we do not want.

"""

rdb.metadata(skip_create_metadata)

rdb.reflected()

rdb.tablename(’sales_part’)

rdb.tableargs(schema=’app’, useexisting=True)

contract = Column(’contract’, String, nullable=False, primary_key=True)

catalog_no = Column(’catalog_no’, String, nullable=False, primary_key=True)

Ok, lets examine some of the details. The ﬁrst thing we see is a class deﬁnition, nothing unusual, just a normal python

class that inherits from rdb.Model. Next, we see several directives or class annotations, if you are new to Grok, you

will ﬁnd that it is big on these. Lets look at them individually:

14 Chapter 2. Data Access

剩余278页未读，继续阅读

百态老人

粉丝: 5171
资源: 2万+

Grok社区文档1.2版：全面指南与技术细节

Documentation.pdf

documentation.pdf

Grok1.0WebDevelopment.pdf 英文原版

2024-03-musk-source-grok-chatbot.pdf

Grok Local MCX.pdf

搭建Opengrok看源码文件.zip

Grok Learning – Privacy risks.pdf

GROK-FPGA- GENERATING.pdf

Grok 1.3 – Installation Guide.pdf

logstash-audit:selinux audit.log 的 logstash 配置（grok 模式和 logstash.conf）

最新资源