OK, not sure if this is a blasphemous question or not. I've been slowly
working through "Web Component Development with Zope 3" , and instead of
trying out the things in zopeproject, I figured that trying out the things
in bfg as well may yield a greater understanding of what the heck is going
on. I realize that this may be incredibly dumb, so I'm not surprised that
I'm hitting roadblocks once in a while.
After reading up on zope.schema and zope.formlib, it seems that schema based
forms, fit my brain, and I would like to use them in bfg if possible rather
than tw.forms etc...
I got this far...
#models.py
#================
...
class Record(Base):
__tablename__ = 'records'
id = Column(Integer, primary_key=True)
name = Column(Unicode(255), unique=True)
value = Column(Integer)
def __init__(self, name, value):
self.name = name
self.value = value
...
#views.py
#================
...
from zope.interface import implements, Interface
from zope.schema import Text, Int
from zope.formlib.form import EditForm, Fields
class IRecord(Interface):
id = Int(
title = u"The id field",
description = u"field that holds the id",
required = True)
name = Text(
title = u"The name field",
description = u"The field that holds the name",
required = True)
value = Text(
title = u"The value field",
description = u"The field that holds the value",
required = True)
class RecordForm(EditForm):
form_fields = Fields(IRecord)
label = u"Edit Record"
...
#configure.zcml
#====================
...
<view
for=".models.Record"
view=".views.RecordForm"
name="edit.html"/>
...
First run and accessing the page http://localhost:6543/1/edit.html I get an
expected error...
TypeError: ('Could not adapt', <tst.models.Record object at 0x9fb0d4c>,
<InterfaceClass tst.views.IRecord>)
Makes sense, I need to create an adapter, no biggie.
#views.py
#=====================
....
class RecordAdapter(object):
"""probably not the best way to do this..."""
def __init__(self, context):
self.context = context
def _get_id(self): return self.context.id
def _get_name(self): return self.context.name
def _get_value(self): return self.context.value
def _set_id(self,v): self.context.id = v
def _set_name(self,v): self.context.name = v
def _set_value(self,v): self.context.value = v
id = property(_get_id, _set_id)
name = property(_get_name, _set_name)
value = property(_get_value, _set_value)
...
and registered
#configure.zcml
#====================
...
<adapter
factory=".views.RecordAdapter"
provides=".views.IRecord"
for=".models.Record"/>
...
Next run fingers crossed.....
ComponentLookupError: ((<zope.schema._bootstrapfields.Int object at
0xa690c6c>, <Request at 0xa69084c GET http://localhost:6543/1/edit.html>),
<InterfaceClass zope.app.form.interfaces.IInputWidget>, u'')
Based on my limited understanding of zope, I am assuming that in my
configure.zcml I need to include a package, maybe zope.app.form ?
#configure.zcml
#====================
...
<include package="repoze.bfg.includes"/>
<include package="zope.app.form"/>
...
next run results in not even getting the server running.
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File
"/home/twillis/projects/bfg/tst/tst/configure.zcml", line 5.2-5.36
IOError: [Errno 2] No such file or directory:
'/home/twillis/projects/bfg/lib/python2.6/site-packages/zope.app.form-3.8.1-py2.6.egg/zope/app/form/configure.zcml'
and indeed it doesn't exist. So all of this was done in a virtualenv and
easy_install. So finally here's my questions.
#1 does bfg provide machinery for registering components or is that
functionality specific to big daddy zope? I assume the answer is yes,
augmented with "it depends". I realize that bfg is meant to isolate you
from the zca, but darn it I think it's cool and I want to understand how
it's used. The above referenced book doesn't have any obvious section that
details how this works, at least not that I've found, so if anyone knows of
an online resource on how this works. I'd appreciate knowing about it.
#2 is the fact that an easy_install off zope.formlib results in no out of
the box zcml file to include (as far as I can tell) a result of these
particular zope libs not being refactored to be more standalone-ish? If so,
what would generally be the process of making it more standalone-ish. Would
it just be coming up with some configure.zcml to deploy with the package?
Hell If I knew all this already, I'd blog it. Because I'm sure there are
others out there interested in zope/repoze and might get intimidated by this
kind of thing. :)
Anyway, thanks for reading, any information is appreciated.
--
Thomas G. Willis
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
