Re: [Zope3-dev] LocationProxy+None
On 8/14/07, Adam Groszer [EMAIL PROTECTED] wrote: A strange thing happened today: x = LocationProxy(None, foo, bar) x is None False x == None True Is this OK or I'm just missing something? You have to understand how Python's ``is`` differs from ``==``. An `is` check is an identity check, not an equality check. It's generally faster than comparing equality. It's basically like this:: a is b if id(a) == id(b) The Python `id` function is basically a memory address of that specific instance. None, True, and False are all basically constants that have the same identity unless that name is overridden in a local namespace. When proxies enter the picture, you're wrapping the object with a proxy, so it's no longer the same by identity. from zope.location import LocationProxy located_none = LocationProxy(None, foo, bar) id(None) 3120456 id(located_none) 404616 id(None) == id(located_none) False located_none is None False Since the proxy object is masquerading as its wrapped object, equality checks works. But identity doesn't. The `zope.proxy` package includes some functions that you can use for help. from zope.proxy import removeAllProxies, sameProxiedObjects, isProxy isProxy(None) False isProxy(located_none) True You have the option of removing all proxies, which would return the object wrapped up by the proxy. Since we wrapped up None, it would return the actual None object and identity checks would pass: removeAllProxies(located_none) is None True Or you can use `sameProxiedObjects`, which does the identity check on the internal objects of one or two proxies: sameProxiedObjects(located_none, None) True You can see this when wrapping another instance of None with a location proxy. singing_nun = LocationProxy(None, 'austria', 'jane') id(singing_nun) 7378424 singing_nun is located_none False sameProxiedObjects(singing_nun, located_none) True -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.cachedescriptors outdated
On 2/22/07, Christian Zagrodnick [EMAIL PROTECTED] wrote: Hi the cachedescriptors package is quite aged as it seems. It hasn't been updated for decorator use. Actually there are only three descriptors: CachedProperty – Needs to be updated to be used as decorator. But I guess we need a deprecation period. Lazy – Works like charm as property decorator. readproperty –can go away i think. The property builtin is find. I'd add a 12 month deprecation warning. As long as `Lazy` doesn't go away, I don't mind. CachedProperty is a little overwhelming.. I guess I haven't had a need for it. I use Lazy a lot in views and other objects that exist only during the request/response cycle. It's super handy in those situations. I wouldn't mind seeing `Lazy` renamed or aliased as `lazyproperty` or `lazyreadproperty`. I use `readproperty`, but I have my own copy of it. I didn't realize it was in cachedescriptors. As I understand it, `readproperty` is different from the built-in basic `property` descriptor: you can write to a readproperty. You can't write to a basic `property` that is used only as a decorator around a getter method. class Foo(object): ... @property ... def bar(self): ... return 42 ... f = Foo() f.bar 42 f.bar = 33 Traceback (most recent call last): File stdin, line 1, in ? AttributeError: can't set attribute With `readproperty`, you can still have the simple getter-method-wrapper property, with the ability to replace the value on instances. So no, the builtin 'property' descriptor is not fine. `property` came into being when Python got descriptors, but before it got decorators. By grand design or divine accident, the fact that the first argument for `property` is the getter function makes it a useful decorator. But it wasn't written with decorators in mind. It was written for ``x = property(getX, setX, delX)``, or some combination thereof. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zc.resourcelibrary resources positioning in head
On 2/21/07, Shaar Gabriel [EMAIL PROTECTED] wrote:
a little thought about zc.resourcelibrary. shouldn't the added
resources (at least javascript) be closer to /head than to head.
this way the specific javascript resources can make use of the more
general ones included in the skin with the template. does this make
sense ?
Like Gary, I don't put more general items in the main template. I
shout out my need from the head of the main template::
tal:resources replace=resource_library:brcms-rsrc /
So I would want my items to be towards the top. Usually. The more
specific resources should be wired to require `brcms-rsrc` or one of
its dependents. This is how I've always expected resourcelibrary to
behave.
But I've been thinking about resourcelibrary. In fact, I logged in to
GMail to ask some questions about it. It's such a useful tool, in some
regards, but it falls short in others. I don't know how to fix it
properly without changing the paradigm (which I would like to do).
One of my complaints is similar to yours, but I want better control of
the positioning. I've thought of making a second pipeline in the
result that would look for very simple markers - just a kind of string
insertion template language (no conditionals, loops, etc). So that
instead of looking for a ``head`` tag, it might look for
``!--#resourcelibrary:all--`` or something like that... maybe even
an XML processing instruction?
Short of an aggressively object-oriented system like Seaside, where
one is building a document page out of objects instead of just
rendering a template / raw string, I guess I really want some kind of
pipelining. I don't want the pipelining to bound to ZPT in any way.
But I imagine there might be some kind of lesson that could be
extracted from how resourcelibrary mucks with the implicit result; or
even with explicit results?
::
def _implicitResult(self, body):
#figure out the content type -- this is straight from resourcelibrary
content_type = self.getHeader('content-type')
if content_type is None:
if isHTML(body):
content_type = 'text/html'
# now we veer off in the land of hypotheticals
postprocessor = queryAdapter(self, IResultPostProcessor,
name=content_type)
if postprocessor:
# the resourcelibrary code that writes all the script and
# style tags would be in this `process` code.
body = postprocessor.process(body)
return super(Response, self)._implicitResult(body)
That might be easier to customize. Resourcelibrary is falling short of
my needs / wants in a few areas. Having an easier plug-in point for
tweaking the response would be dreamy.
--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: future of fssync (was: RE: [SpringCleaning07])
This is a very delayed response, I'm sorry. I seldom get/make the time to check GMail these days. Eternally busy, for better or worse :). On 1/2/07, Stephan Richter [EMAIL PROTECTED] wrote: On Wednesday 20 December 2006 16:03, Jeff Shell wrote: zope.fssync It's too bad that this seems to have gone unfinished. The biggest pain (well, one of the big pains) we experience with Zope 3 is the lack of anything like Zope 2's export/import. Or, going further back, 'manage_exportHack'. :). This is a side topic and I'm not going to elaborate further except to beg for some low to medium level export/import capability. It seems that fssync was one of the alternatives, or could be, if I recall correctly. The question is why you need it. zope.fssync was originally developed for TTW development via the filesystem. I think this use case has gone away. What use cases do *you* have for using fssync? More than anything, we need export/import, ala Zope 2. If my memory serves, 'fssync' was often described as the Zope 3 replacement for it when I brought it up in the past. In Zope 2, export/import was often used by us as a release mechanism: export a folder/site from a development instance, import it into a production instance. Since we don't really do much in the way of through the web development in the Zope 3 era, this hasn't been a terribly critical feature. However, we do large CMS based web sites and sometimes have sub-sections or sites that we need to build up in house with lots of graphic design, customer sign-off, etc, that then needs to be integrated with the existing production servers. For these purposes, I don't really care what the exported / sync'd files look like. I'd just like to be able to move elements from one machine / instance to another without having to replace the entire Data.fs file. And again, if memory serves, it seemed like fssync was often pitched as the potential answer to this situation. But it was pretty clear to me back then that fssync's development had stalled. I didn't have the time to contribute (hell, I barely get time to check GMail any more), and haven't had the time to look into our own solution, so we just blunder-force our way through these particular deployment scenarios. Fortunately we've had only to deal with a few such cases. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] SOAP support?
On 1/7/07, Andreas Jung [EMAIL PROTECTED] wrote: Hi, I am actually looking at options for bringing SOAP support into Zope 2. Is there some SOAP infrastructure available in Zope 3 (or some add-ons) and might be re-used in a reasonable way? FWIW, I managed to bang out a brute force RPC style SOAP publisher, based on the XML-RPC one in Zope 3. I used ZSI to handle the parsing / writing, and expect my views / published methods to do the same - ie, I can't just return a dictionary or list and have it all get bundled up correctly. This is because SOAP, as far as I can understand it, suuucks. ZSI - http://pywebsvcs.sf.net/ I had to bang this implementation together because a customer has an old flash applet that retrieved some data from a ColdFusion Component exposed as a web service. They apparently don't have the Flash source any more, and we've been unable to get much help from their developers or anyone in regards to what this Flash tool expects. All we have is the cold fusion component source - and we don't even know what data is actually being returned! At most we can see the columns / keys. Ugh. I'm glad that Zope 3 has a built-in place to attach a SOAP request factory/handler/thing, but I definitely wouldn't expect or want any more than that. I had to pull some nasty hacks to get the generated SOAP response to be handled properly by the Flash client - what ZSI generated was probably close to some kind of spec, but just didn't behave in the same manner as these two Macromedia, er, Adobe tools. It feels like the best chances of any kind of interoperability come from servers and clients built by the same provider. What a mess. I've attached the publisher side of what I've managed to cobble together so far in case anyone is interested. I'm probably not going to take this thing any further as it basically provides just enough functionality to allow us to communicate with the Flash client. The Zope application side of my project used ZSI's `wsdl2py` and `wsdl2dispatch` to generate the skeleton code, typecodes, and rough ideas on how to write a response handler. The S Stands for Simple is definitely a great read. It's terrifying because it's true. (At the same time, I can see the appeal of SOAP in the heavyweight compiled commercial crap tools business - exposing a ColdFusion Component as a web service is as easy as adding ``?wsdl`` to the URL, and I was able to attach the web service to a table in Flash 8 Professional and witness data being returned, and I don't know or use Flash (or ColdFusion) at all. Ugh. Shame it's such a crap system. Viva AJAX with JSON! Viva View-Source! Viva good old fashioned GET and POST HTTP requests that don't have additional traversal steps buried in a body that one could never type by hand!) - 100 for adding this kind of support to the core. It's way too much of a mess, and the Python SOAP libraries all seem to be in pretty bad shape. -- Jeff Shell soappublisher-0.0.0.tgz Description: GNU Zip compressed data ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: [SpringCleaning07]
to be able to move documents from Writeboard (Textile format) to our KBase for long term storage, as well as being able to post our own reStructuredText based documents. 'zope.app.renderer' is a bit confusing, but its disappearance could be critical. Again, I don't mind too much of it disappears from the core distribution, as long as it's made obvious (ie - not buried in a wiki page on some far flung remote site) and can be easily downloaded/installed. I'll note that the removal of several of the zope.app.* packages means a further distancing from TTW, offering the casual newscomer even less to look at. I am okay with this direction, but others might object strongly. This should really be brought up on zope3-users or other high-level mailing lists. I'm also for this. Besides, the casual newcomer can't really do much with the stock TTW objects anyways. For casual TTW style development with all of its features (and drawbacks), Zope 2 is a far better choice. Side Topic: When you install Pylons, you don't have anything to look at. But making a quick and simple application with it was rather straightforward. On the other end of the spectrum is Django, whose admin screens are actually usable by other humans and very very easy to customize. How easy is it in Zope 3 to customize a folder contents view so that it shows different columns, allows sorting only on certain ones, and allows quick searching, grouping, and filtering? I know (or assume) that 'zc.table' can provide for this functionality, but it's nowhere near the core. As a developer, doing custom 'listing' or index pages is something I need to do all of the time. 'title', 'size', and 'modified' aren't interesting to me in a folder full of invoices. I would be interested to know if anyone has succesfully used the TTW ZPT Page and SQL Scripts or SQL Exprs to make a usable application. Those never seemed to be the focus of Zope 3, and with the lack of auto-acquisition and Python scripts, they felt extremely crippled compared to their Zope 2 cousins. I certainly could never get them to do anything useful, because I had no answers about what objects/namespaces/modules/etc I could even access. All of the things that were easy in Zope 2's TTW environment didn't seem doable in Zope 3's. But that's OK, as custom Python / product / etc development is much easier. I'd rather see the elevation and inclusion of tools like 'zc.table' and 'zc.resourcelibrary' which can be useful across so many application domains and could solve some very common problems. And if we want to give casual newcomers something to look at, lets focus on how Instance Homes and Products/Applications are used and can be built. Perhaps give templated starting points like paster does:: $ paster create --template=zope3product easytodo The Zope 3 experience does nothing to start the casual newcomer towards building a simple starter application. Both Pylons and TurboGears have a 'quick wiki' tutorial which includes a line similar to the one above. Unlike 'mkzopeinstance', the generated directories and files reflect a working product with some starter modules, classes, and templates: the equivalent of 'BoringProduct', in a sense, but with some skeleton parts (class names, etc) filled in instead of having to be manually replaced. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
On 12/20/06, Martijn Faassen [EMAIL PROTECTED] wrote:
Rocky Burt wrote:
On Wed, 2006-20-12 at 12:52 +0100, Martijn Faassen wrote:
http://genshi.edgewall.org
Inspired by Kid (in turn among others inspired by ZPT), the main
template language of TurboGears, written by the people who also created
Trac, and it seems to be getting traction. TurboGears among others is
going to adopt it, but also things like the creator of SQLAlchemy (and
Myghthy) spending time optimizing it, etc. It's close enough to ZPT to
be palatable to me, and has some nice features for reuse.
I both like and dislike ZPT and other such languages these days.
They're great when working on some design-heavy sites. But in other
situations, it's an awful lot of useless typing and structuring.
It matters to me especially when we're talking about reuse. Template
languages differ significantly in their approach. I also prefer to pick
something that has a certain momentum and a certain performance.
If TAL / Page Templates isn't really made available to anyone else,
how could it get momentum? 'zope.tal', 'zope.tales' and
'zope.pagetemplate' could probably be combined into a nice
world-usable egg. With the right extras and entry points, they could
be used with Buffet and then available to TurboGears, Pylons, web.py,
whatever.
Performance is also a strange game, as template languages differ
significantly in how (or even if) they compile, and how/where they
store that compiled manifestation.
Pylons uses Buffet, or at least a customized version of Buffet,
alongside 'Beaker'. 'Beaker' is a WSGI middleware thing that uses
Myghty's containers (which I guess basically make up the heart of
Myghty's supposedly powerful caching system) to cache templates,
fragments, all in a template-language-neutral way apparently. It would
be nice to be able to use things like that with Zope. Keep TAL, allow
for use of Buffet or something like it (perhaps something using the
same entry point) so that any other supported template language could
be plugged in.
http://projects.dowski.com/projects/buffet
http://pylonshq.com/project/pylonshq/browser/Pylons/trunk/pylons/templating.py
As a side topic, I'm also slowly coming to the conclusion that tales
path expressions are a waste of time and effort. We spent a lot of time
making sure that we can express something as a path expression, and a
Python expression would be just as easy to read and explain. We're not
stopping people from writing more complicated python expressions anyway,
and there are real cases where they're needed. A very different
templating mechanism where there is no Python at all and data is always
pregenerated before rendering is still attractive for other reasons, but
in the ZPT case I've become less and less convinced it's worth the hassle.
The nice thing then about something like Genshi is that instead of:
python:foo.bar
I can simply write:
foo.bar
Python expressions in TAL are cumbersome in part because they're simply
hard to type, not because they're necessarily *complicated*.
It's not TAL's fault - path expressions are just configured to be the
default for the engine used by Page Templates.
It should certainly possible to set Python Expressions as the default
for your ZPT Page Templates. I did a simple-stupid string template
language that basically looked for the following pattern::
{{ expr }}
and ran the TALES expression inside. For that setup, I set Python
expressions to be the default. This was used for generating emails,
etc. Kindof a slightly fancy mail merge::
Dear {{customer.name or 'customer'}},
But I could use string, path, whatever as well.
Doesn't Genshi allow for {{ expr }} type things in its templates? Or
was that Kid? Anyways, I hate having to type a whole bunch of TAL to
generate a fake tag and all of that to do a simple insertion in cases
where I could really do without that overhead::
strongFeatured?/strong
tal:insert content=structure view/featuredFlag /br /
'view/featuredFlag' renders lots of fancy HTML on its own, so I don't
need a span or div or anything right there.
--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Do not serialize one attribute
On 12/14/06, Florian Lindner [EMAIL PROTECTED] wrote: Hello, I have a object, derived from Persistent when contain one attribute which is not serializable and that's not a problem for me, but Zope complains about that. Can I mark this attribute somehow as not to serialize and make Zope call a member function when it has unserialized this object so I can reinstantiate this attribute? What do you need to do to re-instatiate the attribute? As another reply mentioned, you can use the Python property descriptor in combination with an `_v_` attribute. The ZODB will not serialize an attribute whose name starts with _v_ (v means volatile). Alternatively, you can override ``__getstate__()`` and ``__setstate()__`` http://www.python.org/doc/2.4/lib/pickle-inst.html Classes can further influence how their instances are pickled; if the class defines the method __getstate__(), it is called and the return state is pickled as the contents for the instance, instead of the contents of the instance's dictionary. If there is no __getstate__() method, the instance's __dict__ is pickled. Upon unpickling, if the class also defines the method __setstate__(), it is called with the unpickled state.13.5 If there is no __setstate__() method, the pickled state must be a dictionary and its items are assigned to the new instance's dictionary. If a class defines both __getstate__() and __setstate__(), the state object needn't be a dictionary and these methods can do what they want. So let's say that the name of this particular attribute is 'unserializable'. You'd remove it from the 'state' dictionary returned by 'getstate', and add it back in during 'setstate'. Warning: It's been a long time, I think, since I've used these methods. There may be better practices. :: class Example(Persistent): ... (other code) def __getstate__(self): state = super(Example, self).__getstate__() # you _might_ want to add '.copy()' to the above to play safe. if 'unserializable' in state: del state['unserializable'] # Alternatively, you might want to store a tuple or some way # of restoring the unserializable object if you can. Some # kind of small memento. # This is what gets pickled and stored in the ZODB. return state def __setstate__(self, state): # here is where you can re-instantiate 'unserializable' state['unserializable'] = unserializableReinstantiationCode() super(Example, self).__setstate__(state) -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re: [Zope3-dev] Do not serialize one attribute
On 12/14/06, Jeff Shell [EMAIL PROTECTED] wrote:
On 12/14/06, Florian Lindner [EMAIL PROTECTED] wrote:
Hello, I have a object, derived from Persistent when contain one
attribute which is not serializable and that's not a problem for me,
but Zope complains about that. Can I mark this attribute somehow as
not to serialize and make Zope call a member function when it has
unserialized this object so I can reinstantiate this attribute?
What do you need to do to re-instatiate the attribute? As another
reply mentioned, you can use the Python property descriptor in
combination with an `_v_` attribute. The ZODB will not serialize an
attribute whose name starts with _v_ (v means volatile).
Is this the IJabberClient object you were asking about a couple of
weeks ago? I just saw that thread today. Anyways, the _v_ option is
probably what you want if that is the problem.
class JabberClient(Persistent):
... (other code) ...
@property
def client(self):
if not hasattr(self, '_v_client'):
self._v_client = xmpp.Client(...)
return self._v_client
You could try using this descriptor as well (something like this might
already exist. If not, perhaps it should? This is a simple
implementation, but it should work)
class volatile(object):
A descriptor that reads and writes to a volatile attribute
def __init__(self, name):
self._volatilename = '_v_%s' % name
def __get__(self, klass, inst):
if inst is None:
# return this descriptor if accessed on the class
return self
return getattr(inst, self._volatilename, None)
def __set__(self, inst, value):
Set the value on the instance in a volatile attribute
setattr(inst, self._volatilename, value)
def __del__(self, inst):
Clear the volatile attribute
delattr(inst, self._volatilename)
And here's how it would be used.
class JabberClient(Persistent):
... (other code) ...
client = volatile('client')
--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Applying schema data on an object
On 12/13/06, Christian Theune [EMAIL PROTECTED] wrote: Hi, I've been trying to DRY some code and found that the following pattern keeps popping up: class SomeObject(object): def __init__(self, many_keyword_arguments): self.y = y self.x = x self.z = z From the outside this then is called from a view (where data comes from a formlib AddForm: def create(self, **data) return SomeObject(**data) I'd like to remove the explicit assignments from the constructor and use a function to do this in a generic way. I didn't find anything that does this yet, except from a formlib function that requires FormFields instead of a schema, so I wrote my own: - def set_schema_data(context, schema, data): Update the context's attributes with the given data that belongs to the specified schema. for name in schema: field = schema[name] if not zope.schema.interfaces.IField.providedBy(field): continue if name in data: field.set(context, data[name]) - I've used a similar pattern for a while - especially in a couple of non-zope experiments that used interfaces and schema. I've noticed that I seldom write initializers for my persistent objects anymore, as I often have formlib or some other function applying data. That's probably a bad habit. One thing that I like about formlib is the ability to combine fields from multiple Interfaces together, and have adaptation apply them. Outside of form usage, however, this might not be as necessary. With forms, it's excellent, as DublinCore fields (like 'title') can easily be included in the field set. There are more complex things you could do in here, such as validation or setting of defaults. Even without that, here's what I would do:: import zope.schema def applyschema(target, data, schema, validate=False, applydefaults=False): for name, field in zope.schema.getFieldsInOrder(schema): field = field.bind(target) if name not in data: if applydefaults: field.set(target, field.default) continue value = data.get(name) if validate: field.validate(value) field.set(target, value) There is a function around already which comes from zope.formlib and requires the schema to be specified as a FormFields setup. I'd like to not have the formlib dependency in this code. I propose to include the given function in zope.schema or zope.interface. Eventually this could also be spelled as a method on a schema (symmetrical to field.set): schema.set(object, data) Would that then be a function of Interfaces? zope.schema is basically nothing but a bunch of extensions of `zope.interface.Attribute` and some helper functions to filter out Field objects from the Interface's members. If applied to zope.interface, you'd have to either move the basic definition of a 'schema field' to zope.interface (which I believe is beyond its scope), or have 'schema.set' work for Attributes (but not interface.Method, which is also extensions of Attribute). I'd propose putting this in `zope.schema._schema` or some other module in zope.schema for utility functions. It could also include my favorite trick - a schema-to-dict-by-way-of-tuple-pairs iterator! def __iter__(self): Yields pairs of (name, value) reflecting IStreetAddress for name, field in zope.schema.getFieldsInOrder(IStreetAddress): yield (name, field.query(self, field.default)) Since ``dict(iterable)`` works if the iterable produces (key,value) pairs, this is a handy to get consistent mappings out of objects. I use the above heavily to copy / move address data around between ZODB, RDBMS (via SQLAlchemy), and CSV files. Maybe made as a general function like this? :: _marker = object() def pairs(source, schema, applydefaults=True): Yields pairs of (name, value) from `source` based on the schema fields in 'schema'. If 'applydefaults' is True (default), missing values will be replaced with the default specified on the field. for name, field in zope.schema.getFieldsInOrder(schema): value = field.query(source, _marker) if (value is _marker) and applydefaults: value = field.default yield (name, value) address = dict(pairs(contact.address, IStreetAddress)) # or pprint.pprint(list(pairs(contact.address, IStreetAddress))) that latter one is handy when debugging. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Bugday today
On 11/15/06, Christian Theune [EMAIL PROTECTED] wrote: Hi, just a quick reminder: Today is a bugday to help get Zope 3.3 virtually free of bugs (by handling bugs from the collector.) Any status report on this? The collector state(s) seem unchanged. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re: [Zope3-dev] Zope 3.3.0 - Why is the minimum generation for 'zope.app' 1? What's a good practice to update to generation 5 prior to my own evolver?
Oops; I think I sent this reply (initially) only to Christian. I'm sharing it now with the group. I still don't know what's going on. I finally got it working (it appears) for us by writing my own evolver that forced removal of all old Utility Registrations and also forced removing the Dependencies on the local utilities themselves. But it wasn't enough. We have to go back to Zope 3.1 for this particular project. We've lost way too much time wrestling with obscure issues last week, and I've declared Zope as hazardous to my health as it was the final straw that got me smoking again after two months clean. On 11/3/06, Christian Theune [EMAIL PROTECTED] wrote: Jeff Shell wrote: On 11/3/06, Christian Theune [EMAIL PROTECTED] wrote: Hi, what about calling the evolve() scripts from your generation? That would be reasonable IMHO. I'm trying to do that now. And now it seems that evolve3 (for zope.app) is failing because it wants to use the new Registrations system to do something to Pluggable Auth group folders...? But of course, the new registrations system won't work until evolve4! Blargh. I was hoping to run the zope.app registrations fairly properly through the schema manager, starting from the current until I got to the level I require... But it looks like I'll have to manually monkey with the order... Humm. I know that. I thought we evened that out during beta. Out of curiosity: did you try bumping the minimum version to 5 so all generations get run at once? I tried running the 'evolve-maximum' subscriber, and set my product's maximum to just be '1' for now instead of 2 (2 being the one that wants to use the registration system). It still errors out in zope.app generation 3... Waaa! -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope 3.3.0 - Why is the minimum generation for 'zope.app' 1? What's a good practice to update to generation 5 prior to my own evolver?
I'm working on moving an old customer to our updated CMS. Their current site is running on Zope 3.1, with our new work being done on Zope 3.3. I've gone through their project, removing deprecation warnings, and watched the code work against a fresh / clean ZODB. But when I moved one of the old development databases over, things started blowing up immediately. It appears to be coming from our CMS core's evolver code. The latest generation (2) removes the old zope.app.catalog instance and replaces it and its indexes with a new zc.catalog Extent Catalog and indexes. On the last job I worked on (the first customer developed with our revised CMS), this evolver script ran fine. But that customer's ZODB started out fresh on Zope 3.3. New customer (on fresh ZODB):: connection = debugger.db.open(); cr = connection.root() cr['zope.app.generations'].items() [(u'br.cms', 2), (u'zope.app', 5)] Old customer (old ZODB, trying to evolve to new, running on Zope 3.3). This is the report _FROM_ the Zope 3.3 instance:: connection = debugger.db.open(); cr = connection.root() cr['zope.app.generations'].items() [(u'br.cms', 1), (u'zope.app', 1)] I would like those numbers to be 2 and 5. But Zope's default evolution mechanism is to evolve to minimum, and the zope.app schema manager is configured like this:: ZopeAppSchemaManager = SchemaManager( minimum_generation=1, generation=5, package_name=key) Great. Well it turns out that generations 2 through 5 do some pretty important things. In my case, I'm interested in generation 4 which evolves the Registrations so that I can unregister and delete an old catalog and replace it with zc.catalog. Unless my ZODB is updated to at least generation 4, I can't even do this from the ZMI. I downloaded Zope 3.3 again just to look at the docs to see if there was any tidbit that I missed about using generations. Because this 'evolve to minimum' scenario is just raising hell. Go ahead - find an old ZODB, run it on Zope 3.3, and try to unregister or remove a Utility in a ++etc++site/default scenario. I doubt it will work. Has no one else run into this? This is another element that seems very broken: there's this code to update one's ZODB instance when moving to a new Zope version, but it's not configured to ever execute by default. And there isn't any how to update your ZODB documentation that even mentions you may want to add the following to your overrides.zcml to ensure that the ZODB is updated to its current generation, as the minimum generation may not work on your data. Is there a reason for this? Finally, is there any way that I can easily add guards in my own scheme manager evolve() scripts to ensure that other evolutions have happened first? My `br.cms generation 2` evolver depends on the new registration system, which isn't in place on older ZODB instances unless zope.app is at generation 4 or later. This is a huge issue. I promised my boss that we could update and upgrade this old customer's code in less than a day. The customer's code now loads up without deprecation warnings on a fresh ZODB, but I'm struggling to load up an old ZODB copy with real data, and am now suddenly behind schedule. We have at least three more customer code bases beyond this one that we want to update as well. I'm trying to think of a better way to automate this situation for us so that development and deployment can be pretty transparent. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re: [Zope3-dev] Zope 3.3.0 - Why is the minimum generation for 'zope.app' 1? What's a good practice to update to generation 5 prior to my own evolver?
On 11/3/06, Christian Theune [EMAIL PROTECTED] wrote: Hi, what about calling the evolve() scripts from your generation? That would be reasonable IMHO. I'm trying to do that now. And now it seems that evolve3 (for zope.app) is failing because it wants to use the new Registrations system to do something to Pluggable Auth group folders...? But of course, the new registrations system won't work until evolve4! Blargh. I was hoping to run the zope.app registrations fairly properly through the schema manager, starting from the current until I got to the level I require... But it looks like I'll have to manually monkey with the order... :( I blame myself. I should have gotten more involved during the beta testing period for Zope 3.3, just to test it against our old databases... It's been a rough week. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Big Problem with FTP in Zope 3.3.0, seems to be the result of using `v = self.get(name, self); if v is self...` in a land where Proxy objects can kill identity comparison
first try - Let's see if IReadDirectory is doing the right thing by firing up debugzope.. - worked as expected. Moral of the story: don't use ``query/get (..., default=self)``, ``if value is self`` paradigm? Be careful of identity comparisons? Is there a moral? Is there any reason why the ``_marker = object() get(..., default=_marker)`` paradigm isn't used? After encountering this, I am rather uneasy about the number of places in which I see this self as default marker check paradigm. My biggest unease comes from not knowing proxies and when things are proxied and when they're not and when I have to be careful about them and when I don't. Anyways, for our particular FTP problem, I can patch around it since we have a custom Read Directory adapter anyway. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Big Problem with FTP in Zope 3.3.0, seems to be the result of using `v = self.get(name, self); if v is self...` in a land where Proxy objects can kill identity comparison
I have to follow this up. While I thought I was doing a good job
reporting and testing the problem, I didn't do a hard enough
control-group study. So, I started to investigate further:
Even though I saw absolutely nothing about our ReadDirectory subclass
that would cause the strange behavior, I decided to double check the
behavior against a fresh install of Zope 3.3.0, with only my
pdb.set_trace statement in place (this time I placed it in
``zope.app.filerepresentation.ReadDirectory.__getitem__`` so I could
watch traversal).
Trying to chdir to '/customer/bogus' in FTP yielded the desired result::
ftp cd customer/bogus
550 /customer/bogus: No such file or directory.
After seeing that, I stepped through the debugger. Sure enough, the
``if v is self`` failed in ``ReadDirectory.__getitem__``, causing the
situation I explained before:
Basically, in the FTP situation (or any situation wherein proxies are
being made), the following scenario happens. The _dir is used in place
of 'self' to show that it's what ultimately gets returned to the
publisher::
1. publishTraverse('bogus') from customer
2. _dir = IReadDirectory(customer)
3. _dir['bogus'] is called
a. v = _dir.get('bogus', _dir) [returns _dir]
b. ``if v is _dir: raise KeyError('bogus')`` fails, as v and _dir
are the same proxied objects, but have diferent identities at the
Python level.
c. Instead of raising a KeyError on the bogus (ha!) name, ``_dir``
is returned.
So this phantom ReadDirectory object gets sent out to the publisher.
The same situation is happening on a clean Zope 3.3.0 instance and on
the instance on which we found the problem (which provides a
subclassed ReadDirectory adapter for our container objects). If Zope's
ReadDirectory and Bottlerocket's ContentContainerReadDirectory are
being pushed up to the publisher as phantoms in each case, why does
the default setup return the proper FTP No such file error where the
Bottlerocket setup allows one to enter this non-existing directory?
I traced the behavior down to
``zope.app.publication.ftp.FTPPublication`` and the *callObject*
method. `callObject` essentially is doing this (staying with the
'_dir' object mentioned above)::
_dir = ob
view = queryMultiAdapter((ob, ftprequest), name='ls', default=self)
Ignoring the ``default=self`` here, `queryMultiAdapter` **fails on the
default setup, but returns FTPView in our custom setup!** Again - we
do nothing special in our ZCML registration, and our custom setup
subclasses from the default ReadDirectory, what's going on? I decided
to look at the list of provided interfaces at the moment of
``FTPPublication.callObject``
The behavior of a *clean setup*, doing ``chdir ... bogus``::
(Pdb) pp list(providedBy(ob).__sro__)
[implementedBy zope.app.folder.filerepresentation.ReadDirectory,
implementedBy __builtin__.object,
InterfaceClass zope.interface.Interface]
Hmmm. So I tried this on our *custom setup*, and got this::
(Pdb) pp list(providedBy(ob).__sro__)
[implementedBy br.cms.folder.ContentContainerReadDirectory,
InterfaceClass zope.filerepresentation.interfaces.IReadDirectory,
InterfaceClass zope.app.container.interfaces.IReadContainer,
InterfaceClass zope.app.container.interfaces.ISimpleReadContainer,
InterfaceClass zope.app.container.interfaces.IItemContainer,
InterfaceClass zope.interface.common.mapping.IEnumerableMapping,
InterfaceClass zope.interface.common.mapping.IReadMapping,
InterfaceClass zope.interface.common.mapping.IItemMapping,
InterfaceClass zope.interface.Interface,
implementedBy zope.app.folder.filerepresentation.ReadDirectory,
implementedBy __builtin__.object]
Well it turns out that there's one place wherein we diverge from the
base ReadDirectory: we include a ``zope.interface.implements``
declaration::
class ContentContainerReadDirectory(ReadDirectory):
implements(zope.filerepresentation.interfaces.IReadDirectory)
Between the screaming and the sobbing, I commented out the
``implements`` line and tried again::
(Pdb) pp list(providedBy(ob).__sro__)
[implementedBy br.cms.folder.ContentContainerReadDirectory,
implementedBy zope.app.folder.filerepresentation.ReadDirectory,
implementedBy __builtin__.object,
InterfaceClass zope.interface.Interface]
And lo and behold, our custom setup worked::
ftp cd /customer/bogus
550 /customer/bogus: No such file or directory.
So!!! This situation happened because our class had the audacity to
declare its instances' provided interface! The same interface that the
ZCML adapter declarations say they provide. It seems to change the
interface / specification order in a way that then elicits different
behavior. The FTPView commands are registered for IReadContainer,
which is the direct parent of IReadDirectory.. So when I had the
``implements`` line in our custom setup, we could change into those
non-existing directories since the IReadDirectory adapter of the
parent directory
Re: Re: [Zope3-dev] Grrr. zope.org wikis are evil.
On 10/7/06, Jim Fulton [EMAIL PROTECTED] wrote: Fred Drake wrote: So whatever the ZF's plans for dealing with zope.org, I think there's no way to go wrong with the wikis except by keeping what we have now. While it's nice to use a Zope-based solution, I think we need to just get a solution that works. That could be a Zope 2 installation with a recent version of ZWiki, or something else (MoinMoin would make me happy as well, and has good reStructuredText support these days). reStructuredText support would be greaet. As well as EXPLICIT Wiki links. All those damn question marks on things that shouldn't be drives me absolutely batty. I believe that Wikipedia is incredibly useful because its links have to be explicit, and not accidently by way of FunNy SpellIng. Yeah, I'm grumbling. It's Friday night, and I've had it with the archaic StructuredText. If we end up using Trac, we'll be using that wiki. I have some wiki desires of my own that I'll probably never realize: - HTML WYSIWYG Wikis that don't use any form os structures text (small s) and just use an HTML editor. I think that structured text of any kind is an obstacle to Wiki use. Moin moin's markup rules drive me as batty as old Structured Text drives other people. ZWiki supports EPOZ editing and I'd love to see that used. Of course, this sort of experience avoids the need for preview or structured-text documentation. I think reStructuredText and Markdown are quite acceptable structured text syntaxes, especially for an audience that is largely technical. I think a system that facilitates easy copying and pasting from doctest documents, formatted doc strings, emails, etc, is ideal. We have a Knowledge Base application developed in-house that allows use of Textile, reStructuredText, Markdown, Plain Text, etc. The big benefit is that its easy to bring in data from sources ranging from Writeboards (Textile) to Zope 3 doctests and our own docstrings and other in-code documents with just a copy and paste. WYSIWYG editors for browsers are getting better, but they can still be a bit slow, taking me back to using geoWrite on the Commodore 64. Type'n'wait :). But yeah... I've found it much easier to share and upload technical documentation when the Wiki / Knowledge Base / Whatever supports the structured text syntax I've been writing in. Oh well. I absolutely agree that we need to replace the existing wikis. One other thing we'll need to consider is anti-spam capabilities. I'll agree with this agreement. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re: [ZF] Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
On 9/29/06, Steve Alexander [EMAIL PROTECTED] wrote: On a small aesthetics side, I find Launchpad's side bars incredibly distracting, and I don't like looking at the page because it feels like there are too many things vying for my attention and I have a hard time really reading the text in front of me. The content gets squished. And then I find myself looking at all of these links and buttons around the page trying to figure out what has the information I'm interested in. The sidebar on Zope.org bothers me in the same way when I try to read the Zope 3 wiki - but Zope.org feels nowhere near as noisy as Launchpad. I'm sure their tools are great, and the hosting service is a good feature. I understand what you're saying about the Launchpad UI, and I agree with it. There's a significant re-design of the Launchpad UI underway right now that ought to address many of these issues. It won't be on the live site for a couple of months, though. I see that you have Matthew P Thomas involved. I know he's had some good writings in the past about usability and consistency. And after looking at `help.launchpad.net` really quickly, I now realize the big seller for Launchpad: bug tracking across multiple projects. With all of the little Zope things out there (zc.catalog, zc.buildout, etc), it would be good to be able to share such data between them. Actually, this is an issue that my very small company runs into frequently - needing to focus on specific projects while also keeping an eye on the underlying tools and frameworks. So many other systems seem suited for just-one-project-at-a-time, and it's frustrating to try to keep track of issues four layers down from customer-specific code. So: I really like Launchpad's goals and intentions. But its a usability nightmare to me as a casual visitor. And I've found that for me, personally, it's hard to stay involved with or on top of a project in that situation, especially when I'm stressed out (like I have been the past few days). I look forward to seeing the re-design. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Python version for Zope 3.4 ?
On 9/28/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Christian Theune wrote: Morning, Baiju M wrote: Hi, What is the target Python version for Zope 3.4, is it Python 2.5? Right now it's still Python 2.4, as Zope 3.4 is scheduled for next year, we should consider using Python 2.5 though. We should definitely try to *support* Python 2.5, but we can't require it till Zope 2 has been certified for it. Why isn't Python 2.5 even supported at present? Does Zope 3.3.0 flat-out break when run on 2.5? Or does Zope 3.3 + Python 2.5 work, but it hasn't been tested enough to say it's usable, but not required? -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re: [Zope3-dev] Python version for Zope 3.4 ?
On 9/28/06, Martijn Faassen [EMAIL PROTECTED] wrote: Jim Fulton wrote: Baiju M wrote: Hi, What is the target Python version for Zope 3.4, is it Python 2.5? That's a good question. I fear it will take a fair bit of work to get to it and, frankly for me there are higher priorities. I think we'd be okay in not supporting Python 2.5 yet for this release. Python 2.5 has just been released, and the 9 months or so will give it time to gell out, Python extensions a bit of time to catch up with the newer version, and for us to do some experimenting. Linux distributions will likely still be supporting Python 2.4 (along with 2.5) at that stage as well. Are you talking not-supporting Python 2.5 at all? Or just not wanting to require it? If Zope 3 can't at least run on Python 2.5 within three months of Python 2.5's release, I don't think that looks good for us. I would hope that by being more Pythonic and free from the old ExtensionClass magic - especially in Zope 3 - that Zope could keep better pace with Python. But nine months? A year? Can I expect the developers of toolkits we use, in some cases more heavily than Zope itself, like SQLAlchemy to hold off on requiring Python 2.5 for that long? So unless a volunteer steps up to do lots of hard work between now and march next year, let's stick with Python 2.4. Otherwise let's plan it in for Zope 3.5 and Zope 2.12 I really really really hope it doesn't take that long to be able to at least run on Python 2.5: even if it has to be with some caveats or mild warnings. If security and restricted python / security proxies are the main issue, what about if one is running Zope sites with absolutely ZERO through the web code - no page templates, nothing - can't there be a lighter weight security implementation that wouldn't take half a year of lots of hard work? -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
On 9/25/06, Martijn Faassen [EMAIL PROTECTED] wrote: Baiju M wrote: On 9/22/06, Jim Fulton [EMAIL PROTECTED] wrote: snip Finally, I'm experimenting with using launchpad for bugs: https://launchpad.net/products/zc.buildout/+bugs and feature requests: https://features.launchpad.net/products/zc.buildout/ So far this is working OK. I haven't really stressed it. Launchpad makes this very easy to set up and I don't think they are allergic to having us create lots of projects. Let's move Zope3 issue collector to launchpad? (Once this discussion came to ZF list, I think there were more +1) Before we move any issue collectors to launchpad, we need a bit more experience with the launchpad issue tracker and its capabilities. I'm also wonder whether launchpad has good issue export facilities in case we want to move to another system. With Tres, I think we should also explore options like Trac. I personally think Trac has attractive features in the way it integrates the development process into things like an issue tracker. I love Trac. I've never installed it or used it to manage any projects on my own, but I find that I stay on top of open source projects more if they're using Trac. On a small aesthetics side, I find Launchpad's side bars incredibly distracting, and I don't like looking at the page because it feels like there are too many things vying for my attention and I have a hard time really reading the text in front of me. The content gets squished. And then I find myself looking at all of these links and buttons around the page trying to figure out what has the information I'm interested in. The sidebar on Zope.org bothers me in the same way when I try to read the Zope 3 wiki - but Zope.org feels nowhere near as noisy as Launchpad. I'm sure their tools are great, and the hosting service is a good feature. But my temper is short these days. My attention span is not: if I can find and read a page that's not full of distractions, I'll stay and read it and learn. But when there are boxes on all sides chock full of colors and links, reading is much harder. A nice simple example is this nice page in SQLAlchemy's Trac wiki (a page I read over and over as I migrated code to 0.2): http://www.sqlalchemy.org/trac/wiki/02Migration It's very nice. I can read that page, print it, save it to a local permanent archive, etc. There is something about Trac's feature set, implementation, and in how it's installed (in most cases) that make it very nice for a cantankerous, stressed out, often overburdened worker like me to stay on top of and even want to get involved (even on some small level) with a project - and that I can do this in small amounts of time. The Zope 3 wiki, collector, and even subversion browser, all feel like they require more of a full time job to stay involved. And if not a full time job, then at least some seriously set-aside time. It's very hard to get answers to what's gone on recently?, what are all of the bugs, and let me see and sort them quickly on some different criteria, and let me then see how they were fixed, and then let me quickly find some minor annoyance issues that I might be able to fix. With a Trac setup like SQLAlchemy is using, I feel like I can do this at home in the morning during my browse-and-drink-coffee-time. With the current Zope tools (and my limited experience with Launchpad's tools), it does not feel casual at all to keep up with everything going on. And that makes it hard to stay enthusiastic and energized about a project. Compare: - http://dev.zope.org/Zope3/RoadMap - http://www.sqlalchemy.org/trac/milestone/0.3.0?by=severity I wish there had been something like that Trac milestone page for Zope 3.3. Of course, it doesn't show everything going on. But it would have made it much easier to find out what may have been slowing the release down so much, and then easier to want to get involved and make it happen sooner. The lack of distracting side columns, the integration of the Wiki, the Roadmaps/Milestones, the Subversion integration (being able to refer to tickets, wiki pages, etc in commit log messages and having the links generated in the web. [ticket:309], etc), the custom issue tracker reports: it's a very nice system to use, even casually. The Timeline is like a Wiki's Recent Changes on crack. Except the crack is filled with helpful vitamins: recent wiki changes, recent checkins, recent issue tracker activity (bugs submitted, opened, closed). It just feels so much more alive. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Riddle: zope.interface versus zope.formlib
haven't explained the situation adequately. I understand what you're saying: Oh, suddenly I wanted/expected IBar['title'] to be bound to IBar when really it was bound to IFoo, but I don't understand the solution that you're trying to get to and why. Specifically, I don't get how it hurts formlib. I think a good copy-and-modify tool for zope.interface.Attribute (or at least zope.schema.Field) objects would be a more useful tool. I think it should be part of the Field interface so that complex fields (like the vocabulary-using ones) can do extra work if required. And I think that some more clarity about how adaptation is used in formlib's different setUp*Widgets and applyChanges methods might be a good thing to have. I really like the pretty-much-automatic adaptation that goes on, most of the time, but I find myself having to mind-trace the source quite a bit just to remember the impact of different options, parameters, or methods. I think it would also be nice if it were easier to register/use one-shot adapters that are made for just one form (I've done this in the past, and it feels like a waste of typing and time and effort to go through all the joys of ZCML registration and naming and thought just to use a particular Adapter class/factory once - especially if I'm doing the adaptation for just two fields out of, say, eight). -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] ZCML, Paths, and the Things You Actually Want To Change At Configuration Time
No sir, I am a real horse Another frustrating aspect of ZCML is that the things you actually WANT to have sys-admin style control over the configuration of seem to get buried. I'm talking about things where the configuration is always specific to the running environment, things like: * RDB adapters (database name, connection/login information, etc) * Mailers (hostname, port) and Delivery systems (queue directory, etc) * Additional browser Resources (ie, using a special directory outside of instance home as a drop-zone for a webcam, so that a zope application can just refer to the resource like @@/webcam/latest.jpg or whatever). These are the things that can easily get buried in source code, in the midst of enormous ZCML files or lost within a large package hierarchy. And it's not until you move from a development server to staging (or back) that you realize oh crap, can't load up, that directory doesn't exist here!) Is there any good pattern for dealing with this? The best we can think of, right now, for our policy at Bottlerocket is to have an INSTALL.txt file that provides descriptions / examples of expected mailers, rdb connectors, etc, so that they can be put into overrides.zcml (I guess that's the right place?) and set up easily for their target environment. We've also talked of having an etc/ or environments/ directory in a package/application that would house ZCML files that configured the machine-specific resources, would keep them in source control, and in each deployment the includes would include something like: include package=example.environments file=staging.zcml / This is an area where I would like to see ZCML really provide help for configurations - where the application's configurations (sigh) could specify expects mailer utility with name 'example-mailer' or expects an RDB adapter with the name 'example_db', and at startup time the ZCML could complain if at the end of all of the meta, configure, and overrides loading it never came across an 'example-mailer' declaration and could say The Example package requires an email utility with the name 'example-mailer' - set one up by putting something like this in overrides.zcml to configure mail support something that'd make it obvious that a machine specific resource was missed, or not configured. These are the little things we forget about (especially when more than a couple of months have gone by since active application development), and whenever code has to be moved between machines, we deal with all of these bits blowing up because they were just forgotten. Speaking of mailers. The path support in ZCML is lousy and fights against customization and environmental configuration. Tools like the Queued mail delivery should *probably* be putting things in $INSTANCE_HOME/var. At least, that would be a good option to have. Then one could configure some of those things in the application's configuration and generally have it work anywhere. As it stands right now, the queue directory and other such paths are local to the configuration. And I had many a CVS update blow up because I didn't have a 'mail/...' directory inside a package I had checked out. It would be nice, I think, to expose some sort of environmental variables to the Path field in ZCML to refer to the instance home and maybe to other variables that could be set up in ZConfig (other common roots), since ZConfig actually supports the ability to define new variables for things like that. I also suggested, a long time ago, to support a way to address paths relative to packages. I remember in early Zope 3 experiments making a little product, and then trying to make a product that built on it. In one product, I'd have something like: package: example1: browser:page class=Foo template=foo.pt ... / In another package, I subclassed Foo and wanted to register that as an alternate view. class SubFoo(example1.Foo): ... browser:page class=SubFoo template=??? / You can't refer to foo.pt here! You have to copy it! This really bit me when it came to using the browser:*form directives in a base framework we used to build our apps, and then tried to use in other packages. This is one of the HUGE reasons why I grew to hate the browser:* directives and found them to hinder reuse much more than they ever helped it. But anyways, I thought (and still think) there should be - if this kind of ZCML is to continue - a way to address package relative paths. I swear someone made an implementation of this at some point. browser:page class=SubFoo template=example1:foo.pt/ As far as I can tell, the 'Path' schema field is not much more than a string. For a 'configuration' language, that's rough. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: a plan for widgets?
On 3/17/06, Fred Drake [EMAIL PROTECTED] wrote: On 3/17/06, Martijn Faassen [EMAIL PROTECTED] wrote: As far as I understood, vocabularies are on the way out in Zope 3.3: in zope.schema.interfaces: # BBB vocabularies are pending deprecation, hopefully in 3.3 That's correct. Gary and I invented vocabularies to solve some problems. Jim followed up with sources, which have fewer warts. In Zope 3.2, Benji and I added iterable and named sources, so I think sources now have the same basic range of functionality as vocabularies. It should now be possible to use a source wherever a vocabulary was used in the past. And it's all incredibly confusing. Gluttony of choice they call it. I settled on Vocabularies for an interesting widget/requirement because they were documented in the book. Trying to translate doctest-speak to how-do-i-make-this-work-in-my-project-speak on Sources was hard. Many ways of doing things, no way to understand when to choose one over the other. And it was frustrating to finally figure out vocabularies and see the oh, but they'll probably be deprecated soon comment in the code. Not that I have anything against Sources. But for me, sources and vocabularies were another long headache. My fancy vocabulary and widget implementation is *GREAT* and now I understand the reasoning behind the design. But the road there was very long. And I still have absolutely no idea how the queriable stuff is supposed to behave. I may have this wrong, but that's what I read in the code. We've used vocabularies before, but apparently they're deprecated. Please try to revise your applications to use sources. If there's anything missing for sources, it may make sense to delay the deprecation of vocabularies. It would also indicate that what needs to be added to allow sources to replace vocabularies. Vocabularies are at least documented in the Zope 3 books that are out there. It took me a couple of re-reads of the chapter just to understand *them*. I printed out the Source doctest docs and started down an implementation path in a different application, but I didn't get far (mostly due to that experience being an experiment). I'm going to keep pushing the guys I work with to let me have a sandbox where I can put up a site with recipes and tips and whatnot. If I'm supposed to try to revise my application to use sources, there needs to be a couple of good narrative pieces about what this means. I depend heavily on custom vocabularies for a customer application I'm about to resume work on this week. I don't think I'm going to have time to do any such revision. But I would like to know (or help others know) how to apply such a revision in the future. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: a plan for widgets?
On 3/17/06, Tres Seaver [EMAIL PROTECTED] wrote: Jeff Shell wrote: By the way, isn't it pretty easy to provide straight up values anyways for those quick drop-down situations? snip Python example You're missing the point -- the vocabulary is *not* software, and Python is *completely* the wrong place to define it: it is *pure* policy. THe fact that you are administering all the sites you build blinds you to this fact. My examples move the definition of the vocabulary out into integrator / administrator land, which is where they belong. No. I think they are software. Or can be as much software as anything else. Sometimes I don't care what the values I get for a Choice field are. Sometimes I care very very very much. With the interfaces, vocabularies can come from a lot of sources. Personally, if I were giving someone an editable vocabulary list in text because they were an 'integrator/administrator', I'd write a Vocabulary object that used something like YAML. Or CSV if that's what the user that's meant to maintain it is. But I'm not going to turn over site.zcml or overrides.zcml with all of its other crap just to let a secretary add an airport code to a preferred destinations vocabulary. There's nothing in the Zope 3 implementation stopping you from having the definition come in from outside. But don't restrict me from using Python just to make a bone stupid simple list of values when I have 100% or even 80% surety that it's *not* something that needs to be an editable policy. It's a waste of time, it's another layer of confusion, and as I said above: this is another policy thing that may not even be maintained by any 'administrator/integrator'. So if there was just one concept of a registered Vocabulary: that of a named utility providing the IVocabulary (or a derivative) interface, then it's easy: write one for your integrators/administrators that sources itself from ZCML, OPML, RDF, whatever. I don't need it. For me, it becomes a maintenance nightmare, or just a roadblock early on. So maybe I am blind. But I **absolutely do not need to worry about integrators/administrators**. And I absolutely hate wasting time writing something that hurts me to write and maintain for a role that I, nor my colleagues, nor my customers, really have to play. Maybe you do. But then, you should do like I do and build yourself some frameworks on top of Zope that suit your world, your customers needs, etc, and work through those. Don't make me have to jump through hoops and XML pain just to make a yes/no/maybe option list just because there's this theoretical person out there that might want to add a maybe not after they find it buried deep within the trenches of XML files buried in an Egg. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Coarse-grained reuse.
On 3/16/06, Martijn Faassen [EMAIL PROTECTED] wrote: Jeff Shell wrote: I don't think there's anything wrong with custom Python code to set this up. It's programmatic, isn't it? A lot of it may be repetitive, and if that's the case, functions/methods can help. Are we all just so used to writing big long blocks of code in Zope 2 Python Scripts that we've forgotten we can do this? Writing Python code for setup is very handy, but we've also seen where it went wrong in Zope 2. Writing Python code for setup therefore worries me. What's the Zope 3 idea on this? It used to be simple: we had ZCML for such things. But when I started using Zope 3 ZCML turned out to be insufficient from the start for this activity, so I used Python code (with an event hooked up to the site add event, too). And now, ZCML is not going to be used for some of this anymore, so I become less certain. Where I think just using Python code starts going wrong (potentially) is when I want to combine my setup Python code with your setup Python code to build a larger application. Then you write a third batch of Python code that further tweaks, removes, or adds to what the combination of the first two do. This is only kindof setup. ZCML, again, is registering very very very core things. Like in Formulator's initialization code: set up the registries, register the core fields. That doesn't stamp out a form. When I build a Knowledge Base site, I'm going to need X and Y and Z in order to use it. I'm going to need each of those to be configured according to how I designed the knowledge base. Python gives me the best option for automating that, because it is (in a way) a kind of business logic: I'm indexing on these fields, I'm building Extent catalogs on these, uh, extents, I'm setting up groups and roles for user management according to these requirements. I'd like there to be common patterns so there's at least a reasonable chance that you can plug my TTW UI for user management into your application without having to rewrite large parts of either. I'd also like this pattern to be there when I'm *writing* my larger application, so I say, 'okay, this is all for TTW user management' then, and then more easily extract it later. I don't want your TTW UI for user management. No offense to your TTW UI for user management, but the chances of it meeting my requirements for style, presentation, ease of use, look and feel are not high. If you have tools that make it pretty easy, I'd probably love to use them. But I'm going to be customizing it to my application anyways. Now - this is for applications whose user management may be turned over to the customer, or is expected to run within the user interface of my custom application. If I were using a more generic data management interface for administration (ZMI, etc), it might be a different story. I'm trying to abstract some common Bottlerocket patterns out into new base framework/library for my company to use, and this is actually one of them. I was trying to come up with something last night for just this issue. Basically, I thought of writing a couple of interfaces that would do something *like* zope.app.generations, but instead of being a 'database opened' event response, used to automatically patch persistent data with the expectations of code, these things would work on a 'site added' event. What I didn't spend any time thinking about was whether to have future upgrades go through this tool, or through generations. This may be in the direction of a solution. I haven't studied generations in detail, myself. Anyway, any such solution needs to be in the common codebase, otherwise we're going to end up with a lot of custom ones. Maybe. But I don't even know what the common codebase is going to be or wants to be these days. This is also a chance for someone to offer a here today alternative for others to install and use. [snip design ideas] * Using an adapter to bind the configurator to the site allows the 'framework' to handle when and how the configuration gets run for a particular site / added object, but doesn't worry about what it does. * Use the wonders of object oriented technology to provide a base class with helpful methods for the common configuration chores. * Use this same wonder to allow common sites to share common tasks for establishing local utilities. * Still have the power to be as programmatic as needed, which can ensure that the utilities are established in a proper order and deal with specific situations regarding their establishment. Or just to handle dealing with very repetitive situations in an easier fashion. I think ordering may become important eventually. I.e. I can only install my Foo thing into a site if Baz is already installed. I'd think I'd like to be able to express such ordering in some declarative way. Why not keep a lot of that declaration in Python? It has
Re: [Zope3-dev] what is ZCML?
On 3/16/06, Martijn Faassen [EMAIL PROTECTED] wrote: Shane Hathaway wrote: [snip] But the ZCML I've written gives me a sick feeling, because I don't know how to refactor ZCML. The sick feeling doesn't go away, so I get scared of Zope 3. Then I come here, hoping to find comfort. I share these sentiments. Not that I have a particularly sick feeling (I've been immunized by too much exposure? :) but because I'm grasping for ways, patterns, to make my code look better, briefer, shorter, less repetition, more reuability. Reuse is overrated. :) Honestly, I think reuse best happens in Python. I've found it easy to wrap and roll things up into more common APIs for personal use. This has been one of the really positive things of Zope 3. But for that sort of roll up to happen, the environment needs to support common refactoring patterns (extract method/class/etc). I do not believe that ZCML supports that. I would feel more comfortable if one of the following things were to happen: 1. The group acknowledges that repetition in ZCML is bad. I definitely acknowledge his one. 2. Someone shows me how to avoid repetition in ZCML. Use less ZCML. Be creative. Have fun. This answer doesn't work for everybody, and isn't as easily applicable as I would like. 3. We decide that ZCML is a failed experiment. On the one hand, I'm not willing to do that. On the other hand, if ZCML is to be a simple registration language, I am starting to idly wonder why a bunch of CSV tables wouldn't do (and might not be clearer and simpler). Because editing CSV tables sucks an even bigger electrical outlet. (Honestly - I'm too stupid to understand Excel... But maybe I'm saying that after spending a week writing an CSV inventory importer. Ugh). If ZCML is to be a simple registration language, I'd also like there to be a 1 to 1 mapping of ZCML statement to Python code. Right now there is a mapping and while it may be reasonably straightforward, I personally am still lost in APIs (and it looks like Jeff Shell is too). This learning curve should be smaller. I agree. I think Jim said early on that ZCML should be theoretically replaceable. Looking at many of the directive implementations, I do not see this. If the Zope 3 CA vision that I had is to have a good chance of succeeding outside of this community, I'd hope that it doesn't ship with or require ZCML. Whatever we do, if ZCML is to be replaced we need to replace it with something. I think many of the notions of ZCML are dead on - this registration shouldn't be happening in normal Python code mixed with the rest but as a separate activity. It should allow overriding. It should be amenable to analysis. I'm mixed about whether this should happen in normal Python code. A few months ago I laid out a vision for how I think it would work. Basically, configuration would have to be a very locked-down module: it couldn't really be imported by regular code, wouldn't really execute when called from 'regular' code. It would, in short, try to somehow enforce the importing a package should NOT automatically register its components. 4. We decide that ZCML should gain more qualities of a high level language. I personally am quite interested in exploring this, but I'd like to see some examples of what this would actually look like, concretely. We have a high level language. It's Python. I think that people just have gotten bad at thinking in objects and usable APIs and have somehow developed a strange fear of the language. I don't get it. class ArticleEditForm(form.EditForm): form_fields = fields.FormFields(IArticle, ITaggable) form_fields['tags'].custom_widget = ... Wow. So much better than browser:editform. It's possible to design other parts of the system like this. I just know it is. like this? yes what is this? respects the Python developer. Now I know forms are a special case, as Tres or Shane or both brought up. I was just impressed by the amount of actually-helpful objects, APIs, and base classes in formlib. That one package has made me more productive and flexible than most of the rest of Zope 3's default elements (zope.interface/component/schema/app.container excepted). I think we can learn something from it. At least, I hope we can. Zope can, at the end of the day, only provide some good core tools. I think those tools, and the concepts behind them, should be simple. Then if someone wants to build the giga-framework on top of it, they can. But also, if I'm writing what should be a simple application like the PyWebOff example, I don't have to waste time on countless elements that don't apply. I don't have to waste time editing more XML than Python. Etc. Honestly: Rails is very appealing with its we use Ruby for everything message. But Ruby's syntax and use of blocks seems to make this more tenable than it is in Python. I'm not a big fan of their convention over configuration design, but it's winning me over slowly. The more I fight
Re: [Zope3-dev] Re: a plan for widgets?
On 3/16/06, Tres Seaver [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: snip * sources and terms are nice, but we should at least provide some basic sources and register some basic terms for them; that bit is completely missing in Zope 3 right now. People should be able to at make a simple drop-down widget happen without having to figure out how to tie all these components together - they should just import and use the right source, perhaps import, use, and register the right term, and there they go. Um. Straight up sources are pretty easy, especially when you use terms directly. We have a few Choice (and our own 'RelaxedChoice') fields in one application that get their values, at present, from tuples in a ``values.py`` file. ``values=values.area_codes``. Works fine for straight and simple sources. The problem I have with vocabularies is, ahem, the vocabulary. they should just import and use the right source, perhaps import, use, and register the right term, and there they go... what? As I mention below, I've ultimately started to find Vocabularies very useful. But I also found them incredibly daunting with a surprisingly high entry barrier. Terms, Tokens, Titles, deferred vocabulary loading and binding, direct vocabulary-field binding, the vocabulary registry (versus the Utility registry), the different vocabulary registry set up in zope.app, ... It's been hard to control and understand. And especially (strangely) hard to learn by interaction in the Python interpreter. zcml:ktupema_necro_halogo Hmm, another case where high-level ZCML support would be useful: defining simple terms for a vocabulary. Why should somebody who wants to tweak a vocabulary have to edit software? E.g.: vocabulary name=philosophers term id=platoPlato/term term id=aristotleAristotle/term term id=kantImmanuel Kant/term /vocabulary Of course, we could also keep the vocabularies in another data file, and merely have the high-level directive source it: zope:vocabulary name=philosophers file=philosophers.csv / /zcml:ktupema_necro_halogo If - and only if - and really really really really really only if - you mean to do this, fix the HELL up the vocabulary registration stuff. That's where most of my time got lost when I had that debugging session the other week that pissed me off to no end about ZCML. I have no idea how I fixed my situation either. By the way, isn't it pretty easy to provide straight up values anyways for those quick drop-down situations? trip_type = zope.schema.Choice( title=_(uTrip Type), description=_(uTrip Type), default=uBusiness, required=True, values=(uBusiness, uPersonal), ) replacementOptions = SimpleVocabulary(( SimpleTerm(value='none', title='No - keep all current articles'), SimpleTerm(value='matching', title='Only replace matching IDs'), SimpleTerm(value='all', title='Yes - replace all existing articles'), )) class ImportSchema(Interface): importfile = zope.schema.Bytes( title=uImport Zip File, description=uZipe file of items to import., required=True, ) replace = zope.schema.Choice( title=uReplace existing articles?, vocabulary=replacementOptions, default='none', ) class ImportArticlesForm(form.Form): ... @form.action(uImport Articles, failure='handleFailure') def importArticles(self, action, data): replace = data['replace'] zipped = self.openZip(data['importfile']) if replace == 'all': self.clearExistingArticles() ... Maybe someday I'll force us at Bottlerocket to make the time for me to at least put up a version of my knowledge base app so I can publish recipes I put up on the mailing list. I think that a lot of the easy / relatively easy aspects get obscured or lost. A recipe or tip for how do I make a simple drop down? would be nice. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: a new zcml directive?
On 3/15/06, Martijn Faassen [EMAIL PROTECTED] wrote: In the new world for ZCML, ZCML as a language falls apart in a minimalistic XML language, and some support code (such as zope.app.annotation.AnnotationFactory) to help it do more advanced things. That's what I'd like to see! :) One remaining benefit of higher-level ZCML is that it gets picked up by apidoc and thus can be discovered fairly easily by developers as part of the configuration story. While AnnotationFactory is doing definition and is in Python code in the new world for ZCML, this act of definition is closely associated with the act of registering it in ZCML. I agree with that benefit of higher-level ZCML. But I've found in practice that documentation is still terse and sparse. That alone is what has had me digging into the code to try to figure out ok, what does that mean? name - TextLine (default = None) Name Adapters can have names. This attribute allows you to specify the name for this adapter. So, yay for documentation. That bit's good. But things like this could really really benefit from some examples. Especially on core things like adapter, whose 'locate', 'permission', and 'trusted' properties and their impact on each other are a bit tricky to figure out. But Python code and interfaces get picked up by apidoc too. Well, most of them (schema fields have gone missing in action.. I think a search will turn them up, but they can't be browsed to directly). One of the biggest downsides of higher-level ZCML to me is that it feels totally disconnected from Python. The documentation, as it stands now, generally documents the fields. But it doesn't go into what's being done behind the scenes, or why I should be using directive X, or how to use the results of directive X. The other downside is that higher level ZCML needs the ZCML 'runtime' in order to work. Besides, AnnotationFactory isn't just associated with registering something in ZCML. It can be associated with registering something with:: zope.component.provideAdapter(...) I know that the adapter directive does a bit more than just provide an adapter. But the point is that it could be used outside of ZCML. It would be nice if we somehow retained discoverability for APIs that are meant to work with ZCML - it's obvious from this subthread that it takes some idiots^H^H^H^H^H^Hpeople a while to pick up an API... We'd like people working with annotations to be able to find out that we have this available. Perhaps a README.txt in the annotation package is enough for now, though. Perhaps we can think of other ways to help make this discoverable... I don't know the status of the static-apidoc tool, but maybe that could help in some ways... By having http://api.rubyonrails.com/ , not only is there a great online API reference, but it's (of course) searchable by the search engine of choice. Hopefully there will be a day when a search for 'zope annotations' will have the API reference and a couple of darn good recipes/articles/tips as the first set of results. I know it's been helpful to see a reference to something in Rails and google ``rails validates_presence_of`` and usually get to the api reference first. (Not that I'm leaving Zope for Rails, but I have been toying with it a bit, I admit). -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: what is ZCML?
for=kbase.interfaces.IKnowledgeBaseSite class=.export.BatchImportViewlet manager=kbase.skin.viewlets.IMultipleFormsManager permission=br.cms.AddAndRemoveContent layer=kbase.skin.KBase / on line 294 of browser/configure.zcml is NOT going to be foreign? It's only marginally (and I mean *marginally*) better than the following anyways:: adapter name=kbase.importzipform factory=.export.BatchImportViewlet provides=zope.viewlets.interfaces.IViewlet for=kbase.interfaces.IKnowledgeBaseSite kbase.skin.KBase kbase.skin.viewlets.IMultipleFormsManager locate=yes permission=br.cms.AddAndRemoveContent / What kind of non developer are either of those options going to appeal to? If I'm deploying an application, I'd probably prefer to have: 'import zip = off' As a developer, I can at least from the second ZCML example above, I can translate that 'for' into a 'getMultiAdapter' call. Which any 'integrator' whose doing their integration in Python may care about more anyways when they're trying to look something up programmatically. Besides, looking at any of the above, you're probably going to have to consult code at some point to really know what's up with the above. I don't see anyone who doesn't understand Python and Zope 3 as someone who would prosper in a land ruled only by ZCML. And I don't see anyone who understands Python as not getting infuriated with ZCML's roadblocks at some point of ZCML grows towards a more specialized language. The fact that such developer-admins are the primary users of ZCML so far is due to the small size of the Zope3 market to date. I actually see very little of ZCML as it stands now as being beneficial to admins who don't have some degree of developer in their blood. ZCML feels more developer oriented. But it also feels like it tries to coddle the developer to help them get up to speed faster. The downside of that is what happens when you're at full speed and ZCML locks you there. Besides, I think some of the reasons for the small size of the Zope 3 market (to date) is that ZCML is intimidating, or just annoying, to Python developers looking in from the outside. I still think that appealing to good, intelligent, passionate Python developers is what's going to grow Zope 3 by allowing many different kick ass products, sites, and applications to be built. Making it easy for a site administrator to install a couple of components isn't going to do much if there's not a lot of appeal for other developers who haven't already drunk the kool-aid to write those components. If you could get all of the lines of XML required to register a viewlet (in a readable style) down to: adapter name=kbase.importzipform factory=.export.BatchImportViewlet permission=br.cms.AddAndRemoveContent locate=yes / And have everything else in the Python code:: class BatchImportViewlet(ViewletBase): implements(IViewlet) adapts(...) I think it's then a lot more appealing to a Python programmer. There's nothing stopping a knowledgeable administrator from overriding that adapter configuration call and establishing different permissions, or different 'provides'/'for' settings. Or a different name even. But I would expect such a person to be knowledgeable. Since most web sites and applications are matters of some degree of custom development and *not* just configuration, I think ZCML should be a thin layer and the Python layer should be robust. I think it would promote better code, components, applications, sites, etc, if the Python developer remained the chief focus of the current round of development. The community of developers will then provide the kick ass automatic-generated interfaces, or the 'ez-system-configuration' toolkit, and those will appeal to and be used by their specific audiences while a strong, clean, and powerful Zope rules all. And then I never have to lose a day finding out why my Choice field doesn't work. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Coarse-grained reuse.
plugins (default groups). There's no way I'd want to automate that in anything BUT Python. (Plus, in its current form, this code can also be used by a view that responds to there being no auth system setup). -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/13/06, Alec Mitchell [EMAIL PROTECTED] wrote: On Monday 13 March 2006 10:59, Dieter Maurer wrote: Note, that configuration files should be understand and adaptable by administrators. Therefore, they should be readable and understandable -- without an understanding of the implementation (but with reading of the component documentation). +1 The first time I saw: adapter factory=.MyFactory / I was a bit disturbed. What's the point? It tells you nothing unless you refer to the actual implementation. Why not just put the registration in python alongside the implementation if that's where the configuration of provided and required interfaces is going to be? I had considered one of zcml configuration's greatest benefits was that it could give a high level overview of how pieces of a package were interconnected. Of course it's still possbile to do things the old way, but I get the impression that it's discouraged. Brevity is not always a boon, though that cuts both ways here (adding a new magical seeming zcml declaration to save a copy/paste here and there may not be the best idea either). I consider one of ZCML configurations greatest detriments is that it does many things that cannot be easily replicated in Python (one day, you'll probably come across having to set up just the right unit test harness and you'll realize what I mean). I consider one of it's greatest detriments is that it completely destroys Don't-Repeat-Yourself. You can do: adapter factory=.MyFrank provides=.interfaces.IFrank for=.interfaces.IBun .interfaces.IRelish / class MyFrank(object): def __init__(self, context): # ... See? No declarations on MyFrank that says what it does. Or you can do: class MyFrank(object): implements(IFrank) adapts(IBun, IRelish) def __init__(self, context): # ... And do the full adapter line in ZCML. But then you've just said the implements / adapts twice. Using different words, I should point out. Or you can do the adapter line the short way and let the Python code say what it does. Three options. I know I'm not consistent with the ones that I choose. I just know that I spend more time looking at Python code and I'd rather understand what the Python code is doing by looking at the Python code. Three options. That sure kills the there should be one, and only one, obvious way to do it theory too. Don't even get me started about when I might want to use 'zope:view', 'browser:view', or just plain old 'adapter' (since a view is just a multi adapter, as are content providers and viewlets and all sorts of other fun and useful combinations). Anyways - for me, the point of adapter factory=.MyFactory is that I already said in MyFactory that it implements and adapts certain interfaces already. I don't want to say that twice. And I think it's very important for the Python code to say what it does, so when I come back to a module five months later I'm not staring at MyFactory going yeah, but what is it? And I also think it's important for code to be debuggable, inspectable, so that when there's a bug from ... well, wherever it came from, code can be traced. It's very hard to trace through ZCML statements, and what they've produced. From dynamically made classes to the weirdness of the metaconfigure.py code (handlers, discriminators, etc) - all of those things get in the way of a productive pdb or why is this thing blowing up? session real fast. In my experience anyways. So I figure - the less ZCML I use, the better it will be for me to maintain in the future. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/13/06, Dieter Maurer [EMAIL PROTECTED] wrote: Martijn Faassen wrote at 2006-3-13 17:15 +0100: ... A newer interpretation of ZCML is: ZCML is a configuration language that configures a number of basic directives for configuring the component architecture and security: adapters, utilities, security requirements, and little else. Everything else should be done in Python code, as configuration in Python code is more flexible and packages can form a more self-contained whole. ZCML should reflect the underlying universality of the component architecture. If two directives work with, say, adapters underneath, they should really be one directive. ZCML should be simple and minimal so it is easy to grasp. ZCML is not readable standalone. ZCML is simply used to turn on various adapters and such, hooking them into the system, but we do not get a clue what the adapters are doing by just looking at the ZCML - Python code needs to be consulted. I believe that this interpretation is the up-and-coming interpretation of ZCML. I hope not... Note, that configuration files should be understand and adaptable by administrators. Therefore, they should be readable and understandable -- without an understanding of the implementation (but with reading of the component documentation). I think differently. ZCML is primarily for programmers. ZConfig style configuration is what administrators deal with more, isn't it? Maybe ZConfig and the things in the root $INSTANCE_HOME/etc/ ZCML files. I don't think of ZCML as administrative configuration. I'd rather have Python files that I can read and understand what's going on without having to consult ZCML files, directives, documentation, and so on, just to understand why a certain class whose code I'm looking at is getting its behavior when I can see no superclass. I'd like to know that a class I'm looking at is an adapter and what it provides and what it adapts without having to dig through a large ZCML file. An administrator is not likely to override my 'inplace_editor' view. He may want to configure global services (if my application is written that way) such as RDB connection parameters and mail services. But beyond that, just loading it up in package-includes or in a specific file is likely to be the bulk of 'administrative' effort. Did administrators go into your ``initialize(context)`` functions in your Zope 2 Product's __init__.py files and change things? That's what I view ZCML as being - a better version of that. (Better in only that configuration and initialization can be executed separately from Python imports) -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/13/06, Shane Hathaway [EMAIL PROTECTED] wrote: Martijn Faassen wrote: A newer interpretation of ZCML is: ZCML is a configuration language that configures a number of basic directives for configuring the component architecture and security: adapters, utilities, security requirements, and little else. Everything else should be done in Python code, as configuration in Python code is more flexible and packages can form a more self-contained whole. ZCML should reflect the underlying universality of the component architecture. If two directives work with, say, adapters underneath, they should really be one directive. ZCML should be simple and minimal so it is easy to grasp. ZCML is not readable standalone. ZCML is simply used to turn on various adapters and such, hooking them into the system, but we do not get a clue what the adapters are doing by just looking at the ZCML - Python code needs to be consulted. IOW, most of the directives we need have already been invented. [1] We don't want to build high level directives; ZCML will follow the BASIC school of language design. :-) [1] http://www.inventionmysteries.com/article4.html While I was initially on board with the idea of reducing the number of directives, I've changed my mind. I think we want high level directives and we want people to feel free to write new directive types. We want tools that let us inspect and search the resulting low level directives. If we have to use ZCML, then ZCML should be expressive. Then why do we have Python? Is Zope going to be a write ZCML directives to write your Zope app system? Or is it going to be write Python code to write your Zope app system? I don't know if it's possible to use a ZCML configuration-execution outside of ZCML, which makes testing an awful hard beast sometimes. There's functionality that's locked away inside the directives that you then have to have not only the Zope environment set up to run, but a ZCML environment too. Pain pain pain pain pain. Unlock the magic. If it must exist, make it available and understandable to me. Don't hide it under more layers and verbs and nouns that conflict and change meaning depending on if you're using ZCML and Python. Make ZCML More Expressive - did we learn nothing from DTML Expressions? It starts out simply enough, but how long until we have more and more logic in ZCML? We already have this conditional that I barely understand (but appreciate in theory). Why design a language at all? I only want ZCML to allow me not to take on a packages provided components when I import it. I don't want to start thinking I can write an enterprise workflow and document management system in it. Let Python be the language. Let ZCML exist to do the final step of loading/registering registerable objects in a predictable manner, and to provide the few things that we don't want to pollute our (or others) Python code with, like security declarations. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] a new zcml directive?
On 3/10/06, Shane Hathaway [EMAIL PROTECTED] wrote: Martijn Faassen wrote: If I'm doing this quite a bit, this looks like something that would be better expressed in a... new ZCML directive (..waiting for the crowd to start flinging stones). A possibly valid direction we haven't discussed yet is to embrace ZCML's flexibility and make new high level directives often. For instance, every time I feel like I'm repeating myself in ZCML, maybe I should make a new high level directive to eliminate the repetition. The risk is that configuration ends up more magical, but maybe new tools can mitigate that risk. Thoughts? No. No no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no. There are very few ZCML directives whose code I can read. It's way too mystical and magical and full of weird things that I *still* don't understand like 'discriminator'. And there are leading and tailing underscores all over the place. This bit me like a mother recently when I was trying to write a unit test to cover a bug I found in my own code. It depended on me setting up enough of the test environment to mimic what was happening. It wasn't quite 'smallest unit of work' type unit testing as could/should often be done. But it was the amount of detective work and pain and trial and error and trial and error and trial and error to follow so many ZCML trails to set up what I needed for my test that really kicked off my recent round of frustration. A 3 line test, a 4 line fix, and over a hundred lines of imports / helpers / harness support from a long day's work into the night to support those seven lines... And really, so much of it was just trying to figure out what the ZCML was doing and how to mimic enough of that to set things up for my test... That's where the time was lost. I still steam up thinking about it. Why not provide helpful classes and functions, and make it obvious that they're there to support programmer code, not ZCML? (I noticed this with some of the odd little deferred factories around that get registered as utilities for things like vocabularies). Automate repetitive tasks with Python. I see something, theoretically, like this as a possibility: class AnnotationsAdapter(object): def __init__(self, annotationsKey, factory, assignName): self.annotationsKey = annotationsKey self.factory = factory self.assignName = assignName def __call__(self, context): annotations = IAnnotations(context) try: return annotations[self.annotationsKey] except KeyError: obj = self.factory() annotations[self.annotationsKey] = obj # to please security... zope.app.container.contained.contained( obj, context, self.assignName) return obj # In some other module from zope.annotations.helper import AnnotationsGetter FOO_KEY = 'foo.key' FooBarAnnotationsAdapter = AnnotationsAdapter(FOO_KEY, Foo, 'foo') And then in the zcml:adapter registration, or directly in the Python (either place above), declare the provides/adapts for this thing. I'm sure it can be done without requiring another ZCML directive. The bulk of my frustrations with Zope 3 have involved going down the rabbit hole of ZCML. Whether it's just trying to understand how something works, how I can provide a slightly different version of 'something' (ie - menu items with javascript actions), or trying to determine whether some erratic behavior is a bug on my part or Zope's, I inevitably end up in metaconfigure.py land. And it's the hardest code in Zope to read - even the metaprogramming in Interface and the sys._getframe tricks are easier to follow! So, please no. No more ZCML for automation. Please yes only for registration control. Please yes (or maybe) for global utility configuration like how to connect to an RDBMS (watching the Turbogears community start to realize that 'config.py' may not be a good thing because certain test and documentation tools will try to run it as Python and not set up its magic made me chuckle). But I beg you not to add to the ZCML pile because you had to copy and paste 12 lines of Python code. I think annotations are useful and I ran into having to write a similar bulk of code the other day - although my adapter and annotator had a larger separation (so 'zope:annotation' wouldn't have helped me anyways). I would argue that most situations requiring some sort of automation can be done by Plain Old Python Objects and Helpers and Plain Old Adapters and Utilities that can, wherever possible, be registered in short form adapter factory=blah. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope Eggs
Cool effort. One thing that I noticed in Rails when I downloaded it this weekend was how you installed plug-ins. Very easy. There are various 'sources' that can be loaded up which work, I assume, in a similar manner to how you can point easy_install at a web page and tell it 'find links'. To install a plugin into an application instance (similar to a Zope instance home), it's just an effort of: $ script/plugin install acts_as_taggable The plugin is found, and installed in the instance home equivalent. This uses 'gems' under the hood from the looks of it, and adds in the knowledge of a Rails application layout. It was pretty gratifying, being able to start adding in functionality so easily. I think a good goal would be to have something like this: A Zope instance home aware package/egg loader, so that in an instance home you could add in packages like this: $ bin/package install zc.catalog $ bin/package install hurry On 3/5/06, Nathan R. Yergler [EMAIL PROTECTED] wrote: During the Zope3 sprint following PyCon, Paul and I, with Jim's guidance, began work on exploring how Zope can utilize eggs and be packaged using eggs. Since we're still experimenting with how eggs will be used, I wrote a script, zpkgegg, which reads the zpkg configuration information for a package and generates a standard setup.py from which an egg and vanilla sdist can be generated. You can find the script in subversion in the projectsupport project. For a brief overview of how the script is used, see README.txt (in http://svn.zope.org/projectsupport/trunk/src/zpkgegg/). The eggs generated by zpkgegg do not attempt to distinguish between runtime, testing or development dependencies, so almost all packages will want zope.testing. README.txt contains a brief example of how to point easy_install at the appropriate folders so that easy_install can resolve the dependencies. Note that at this point we're still experimenting with how we'll use eggs, so suggestions, feedback and comments are welcome. Thanks, Nathan R. Yergler ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.com -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Re: Two visions
On 3/3/06, Chris McDonough [EMAIL PROTECTED] wrote: On Mar 3, 2006, at 3:08 AM, Max M wrote: Splitting up Zope to let people use seperate pieces of Zope aka Zed is not a valid reason. Good software practise is a valid reason. But catering for those few developers that wants to use just a few pieces is probably not worth the effort. Here's one of the reasons I want good packaging: I'd like to continue using Zope-the-technology even if the Zope-the-brand loses all recognition. Whether in the future I'm working on DjangoRailsGears 3.0 or Zope3006 or Plone-NG, I'd like to be able to carry the various bits of technology that make up Zope around with me reasonably easily and run it under different Python platforms. I say this with my cynical and Zope-bigoted consultant hat on. There. I said it. ;-) Today I tried installing Ruby on Rails 1.0 and TurboGears 0.9a1. And now I'm really with you on the good packaging bit. $ gem install rails --include-dependencies $ easy_install -f http://www.turbogears.org/preview/download/index.html TurboGears Although, I also really like Zope's configure/make/make install process and the fact that I don't need to set up no stinkin' mysql server to use Zope. But as I watched TurboGears install and saw all of the pieces it's pulling in, I have to admit that it was really impressive. That page in the link above is intimidating to look at - there's just a lot of links to lots of different packages with version numbers like 0.5.0a1. But the easy_install thing worked. I've been avoiding Eggs and the like for a while now (The name 'eggs' bugs me for some unknown reason, and I'm petty enough to avoid something just for that reason). Seeing them in action was impressive. One of the impressive things: having/extracting PyProtocols and RuleDispatch out of PEAK has made those things widely used. PEAK has some interesting ideas in it, but it's big and scary to me, and I'm sure it is to others as well. PEAK has some web stuff in it, from what I can tell, so in some ways TurboGears is a competitor to the full PEAK package. But since PyProtocols and RuleDispatch are available separately, TurboGears can include them and use them. And maybe that's a good argument for renaming some of the core stuff. I just think 'Z' and 'Zed' are terrible names. But it's a good argument for packaging, especially fine-packaging of the core tools. From those core tools, lets build and let others build wild and crazy applications, app servers, and even competition. One of my thoughts for some weekend hacking was to look at zope.bobo, or play with my own concept just to see if I really understand how the publisher/publication interact. As I started thinking about that, I started wondering (a) how to get the pieces I needed and only the pieces I needed, (b) how/where to install them while I was developing, and (c) how to package them up if I was able to come up with anything successful. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Notice: zope.interface is now a separate project
On 3/3/06, Thomas Lotze [EMAIL PROTECTED] wrote: Am Mon, 27 Feb 2006 15:56:16 -0600 schrieb Paul Winkler: We are planning to do this to a number of other packages: zope.i18n zope.i18nmessageid zope.deprecation zope.exceptions zope.tal zope.component What was the reason for choosing these and not choosing others? What about, e.g., zope.schema? I think that one's as interesting for non-Zope use as, e.g., zope.interface and zope.component. I agree. I think zope.schema is integral. It has so many potential uses, not to mention that it really makes 'zope.interface' a complete design by contract system since it can be used to enforce constraints on data / arguments / etc. It's also fiendishly good for formatting and translating data to/from objects. I've used zope.schema to serialize values to and from reStructuredText style fields, as a way to do fancy declarative programming in Python through deferred object constructors that used zope.schema to enforce/convert arguments. This latter one was in an experiment in using the zope component architecture in a totally not-Zope application. I highly recommend adding zope.schema to this list. I believe its dependencies are pretty small, and I think it's a good system to use for people who like the concept of 'static type safety' while being much more adaptive, useful, usable, and flexible than most basic type systems. I think that zope.schema, zope.component, and zope.interface could be highly effective when combined with a tool like 'sqlalchemy'. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Visionaire! (All your problems, solved)
, while sticking with the current timed release plan as well. And it would finally make a useful and usable Zope Without Zope downloadable option available as Zope 3 CA. I can envision the web site now, and may mock a simple and sexy text based one up later this evening. We could even get it up now (zopesuite.org anybody?). - Zope 3 CA: Provides the core elements and concepts for building and sustaining loosely coupled Python programs, as well as the fundamental object publishing toolkit that's been powering Zope based web sites since 1996 (1995?). [download now | more information] - Zope 3 AS: The Zope 3 Application Server. A new approach to Zope web sites built entirely on the Zope 3 Component Architecture and Zope Object Database. A full stack for developing custom web sites and applications using only Python and your imagination. [download Zope 3.2 now | more info ] - Zope Suite: Built on Zope 2 and leveraging elements of the Zope 3 CA and Zope 3 AS, the Zope Suite provides a robust and mature web development environment that is in place already behind many web sites and applications worldwide. [download zope 2.9 now | more info | roadmap ] Thoughts? I think this keeps Zope 3 as we know it alive, keeps the Zope brand intact, and offers a future for Zope 2 and similar caliber desires for a Big App Server while not interfering with the more pure and simple concepts that makes Zope 3 appealing for developers like me. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Visionaire! (All your problems, solved)
On 3/1/06, Shane Hathaway [EMAIL PROTECTED] wrote: Jeff Shell wrote: - Zope 3 CA: The Zope Component Architecture. Core services. Would include zope.publisher and most other current top level zope.* things. Usable as a library, as a publisher for other environments, perhaps as a simple standalone server. Easy to deploy against WSGI, Paste.deploy, whatever. - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack using the ZODB, ILocation, and most of the zope.app services but without any content objects. Perhaps only an application server configuration skin (process management) but no ZMI. Maybe have the current configuration installable as an option. - Zope Suite (or Zope Web or Zope DE): This is the full application server perhaps Jim is envisioning. A comprehensive web based user interface, based on features (and implementations) of both Zope 2 and Zope 3 application servers and offerings. That's quite appealing, IMHO. Could you agree with the following distinction? - Zope 3 CA expects the model (and the method of persisting the model) to be completely defined by the Python programmer. Yes, although Zope 3 CA could also be used in non-web environments (I've used it in an internal package manager experiment, for example). I'd like the Zope 3 CA download to include some useful examples and/or skeletons (possibly configured for Paste Deploy) to show some of the different options - use with SQLObject, other template packages (page templates would be included with the core though), etc. It could also include some other publisher/publication objects that could show integration with tools like Routes, for example. These extras would be outside of the core library, of course. For purposes of documentation and evangelizing, the Zope 3 CA can provide improved documentation about core Zope concepts like object publishing, without having to put Zope 3 AS expectations or terms on the programmer, giving them an entry point to the larger world of the Zope Application Servers without being overwhelming. Then we (or someone else) can write Python on What Have The Romans Ever Given Us, which would show how you can do a rails programming by convention style system using the component architecture. The CA would automatically create adapters/views to bind ``models/person.py``, ``controllers/person.py``, and ``views/person/list.pt`` together. How those adapters are registered and used by the publisher would show off the CA. - Zope 3 AS expects most of the model to be stored in ZODB and implement ILocation. However, it still expects model objects to be defined by the Python programmer. Yep. Zope 3 AS might also yield a solid foundation of base interfaces to allow easier use of 'sqlos' and/or 'sqlalchemy' backed objects that still provide a core set of useful and usable information (dublin core, etc), and could offer the option of using one of those instead of the ZODB while providing the caveat that use of other (third party) 'model' components may require additional work to map. Essentially, Zope 3 AS would be the option for those who like the Zope 3 + ZODB way. So many of these other web 'frameworks' with their O-R mappers show off applications that don't really need the full power of SQL. If you don't need it, why go through it? The ZODB is very credible - perhaps more so now than ever. Zope 3 AS would also downplay or replace the ZMI. I think there should be a skin available for configuration - ie, for adding a site (a complete application like Schoolbell, a customer CMS, etc) and maybe giving access to configuration options, like the stuff in ++etc++site, but that's it. I think the current ZMI suffers from being both a system administrator tool and application / data entry tool. I know that security settings can filter out a lot of the administrative features, but the interface that's left still feels a bit incomplete. And it raises the question should I provide for it? should I define some zmi_menu menu items, just to be useful? should I use it as my user interface? Django is killing us on automatic data (not system) administration pages. If web based configuration/administration (add a site, set up users, maybe select that site's skin, flush caches; process administration) was separated, then someone could build and provide something like Django's admin screens or Turbogear's Catwalk for doing the data entry. But it would be an option to use that as a view/skin/tool, and clearly marked as such. Some applications, like many CMS's, need something like the ZMI as they often separate the concept of data entry/management from how it is presented to the site's visitors. But an application like Schoolbell or a Knowledge Base may have just one skin. All data entry, display, etc, is managed through that. Having to support (or wonder about supporting) the ZMI shouldn't be a concern of those applications. It's just a point of removing
[Zope3-dev] Django, Catwalk, nice admins (was re: Visionaire! (All your problems, solved))
On 3/1/06, Gary Poster [EMAIL PROTECTED] wrote:
On Mar 1, 2006, at 11:02 PM, Jeff Shell wrote:
[...]
Django is killing us on automatic data (not system) administration
pages.
[...]
I didn't follow this, probably because I don't know Django. Do you
mean they excel in automatic data entry forms, a la Zope 3 edit forms/
formlib? As in Ruby-on-Rails slick SQL-driven AJAX forms? Or...?
It's not just formlib, but it's on the contents screen. This effbot
post summarizes it pretty well:
http://online.effbot.org/2006_02_01_archive.htm#20060215
It includes example code and a screen shot. In a very few lines of
pure Python, he has an edit screen for announcements. There's a search
field, the columns are sortable, etc. There's also a 'date hierarchy'
which gives clickable years across the top of the listing to filter.
Django comes out of newspaper focused content management, and has a
polished CMS style UI (based on the screen shots I've seen, I've never
actually used it) and ways of rapidly putting it together. I'm not
fond of the way they put it together in the code, but the results are
impressive.
A low priority project I have is to make a new base 'admin' skin and
collection of components/tools for us at Bottlerocket. One of the
things I really want to do is create a formlib inspired contents
view(let). The contents view we have in our current CMS is based
(stylistically if not subclassed) on the one in
zope.app.container.browser.contents. It has ajax elements (inline
renaming and title editing), and no copy and paste. But it does have
delete. Delete (and the other things) are methods of the contents
view, and a lot of the display is bound up in the template. When my
co-worker wanted to adapt it for more specialized content listings,
where he wanted grouping and no renaming, it was quite a bit of work.
It's late, and I've been watching nothing but South Park and Monty
Python's Personal Best series (an hour of Terry Gilliam animations -
dada enlivened!), but I envision something like:
class AnnouncementContents(ContentsView):
contents = JSSortableContentsTable(
listOnly=IArticle,
columns=ColumnFields(IZopeDublinCore.modified,IZopeDublinCore.title),
actions=ItemActions(
ViewAction(icon=Resource('rsrc/delete.gif'), viewname='delete',
title='Delete', post=True)
)
)
contents.order(table.columns['modified'], reverse=True)
contents.columns['title'].widget = InPlaceEditor
*shrug*. That's a bit messy. But it's also only fantasy right now. :)
Anyways, Django has a very nicely polished 'admin' interface. Which,
as I mentioned earlier, is something that is very attractive for
certain application types. It allows the focus to be on the
application's real skin, and offers an easy almost-no-brain data entry
skin to be made that's also quite usable.
Something like this would be a great option, emphasis on option. It's
not usable for every situation. At Bottlerocket, we want to brand and
customize and this has often been one of the reasons we've made our
own apps instead of using something like Plone. Hmm. Looks like
Plone. We don't want something that looks like Plone... (This was
only really bad when it came to trying to figure out how to publish a
site that didn't look like plone to end users, but did for data
entry). This is one of those issues that spirals out of control, and
easy usability - wrap this interface around all your models in one
line of code! - and customizability start to clash. But having it as
an option to startup could be priceless.
An even more interesting application is CatWalk, which is now part of
the TurboGears 0.9 toolbox. One metric I saw was that it's 1200 lines
of Javascript, 900 lines of Python. It does a LOT via Ajax/JSON. And
it's _extremely_ impressive, especially when it can actually be
wrapped around your model objects in a single line of code (or just as
a launch option!).
http://checkandshare.com/catwalk/
(he also has a model designer running -
http://www.checkandshare.com/modelDesigner/ )
The nice thing with TurboGears and these tools is that they feel like
*additional options*. At least, that's the feel I get just from some
semi-casual observations on my part. They don't feel like the default
UI that you don't know if you have to support or not.
Anyways, the other communities have things like this going on and
we're still debating over release / roadmap / naming strategies?
--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope3-Users] Visionaire! (All your problems, solved)
On 3/1/06, Terry Hancock [EMAIL PROTECTED] wrote: On Wed, 1 Mar 2006 21:43:10 -0500 Chris McDonough [EMAIL PROTECTED] wrote: From a marketing or user convenience perspective, labels like the ones proposed remain useful, however. Personally, I think they're fine. I'm not sure I wouldn't ditch the 3 though, and just call it Zope CA/Zope AS or even Zope Component Architecture and Zope Application Server -- would there actually be any ambiguity? Yes. There's a dominant Zope name out there. It's not the Component Architecture nor is it built on it. It's starting to use it, but it's not based on it. However, since the project that Zope 3 [AS] came out of is still identified in the Wiki as the 'Component Architecture' project, maybe the '3' can be dropped for that one. But not for application server: That dominant Zope, aka Zope 2, is also an application server. So there really needs to be a separate definition. This was discussed here a couple of months ago when people were enamored with the concept of totally different names or code names or release names, which I was against. Zope 3 is Zope. But Zope 3 is Not Zope. Zope 3 has *some* degree of buzz around it, more than something with a new name. I still believe that the '3' has meaning, at least for now. Maybe it can disappear over time. The Zope 3 Application Server can be defined, I think, as the result of the Zope [3] Component Architecture Project, Zope 3 AS builds a new Zope application server and library purely on the core Component Architecture and its principals. It is not meant to be a replacement for the popular Zope 2 server or the new Zope Suite. Instead it provides a smaller subset for developing new custom web applications that take advantage of Zope's core concepts while providing the blank slate to build the system you want. Zope 3 AS is targeted primarily to Python programmers, and is a powerful toolkit for building the web application of your dreams. *shrug* I think keeping the 3 in that one is important, and keeping the 3 in 'Zope 3 Component Architecture' ties those two together, and puts them out there as the tangible results of the Zope 3 project. The Zope 3 as a someday successor to Zope 2, maybe message goes away. 'Zope 3' becomes less of a product name on its own and comes to stand for the work done to re-imagine Zope as a loosely coupled collection of components, and the possibilities that it opens up. The message then becomes Zope 3 CA and Zope 3 AS, and the individual packages that make them up, are the products available now from the Zope 3 group. The Zope Suite leverages that work into the established Zope 2 project. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
On 2/28/06, Martijn Faassen [EMAIL PROTECTED] wrote: Gary Poster wrote: [snip] On Feb 28, 2006, at 10:06 AM, Philipp von Weitershausen wrote: I think focusing on one app server and a dedicated set of libraries would be a good alternative to two concurring app servers. ...if the single app server is based on acquisition, __bobo_traverse__ and friends, objectValues and friends, ZCatalog, and so on, I'd rather have two, thanks: at least I can have one I like. I can see where Philipp is coming from: yes, it would be good to collapse the Zope 2 and Zope 3 communities into one if that frees up more development resources and lets us do less duplicate work. I still fear collapsing them into one. This is no offense to any of the hard work people are doing on all projects. Someone said Zope 2 + Zope 3 + Five is big complexity, and I agree. A lot. It's easier for us to use only one or only another. I prefer Zope 3. It's simpler. But already there are some design decisions that have happened in recent months that make me less comfortable about that. All of these big features are neat and well. But I want less. I don't know how to use less. There are dependencies on zope.app creeping into packages allowed in zope.*, and I understand that more of that is likely to happen in the future. And that terrifies me. An acknowledged Zope 2 problem is the large inheritance structure that objects have to support to be useful and usable, and that it creates a tight coupling that can't be broken. But having a large collection of loose couplings that can't easily be broken is not a better solution. Having to load up and configure 80% of the zope library to use 30% of its features isn't tenable. The size of Zope 3 app server as it stands now is still overwhelming to me. I think we could still stand to do with some smaller cleaner core features first. The part of this vision that worries me tonight is that it gives priority to the Big Complex Application Server With All It's Features (as good as they may be). Instead we could do good by giving that thing a better base to use, and benefit others among us by having a better base to use with less overhead (says the man bit by ZCML browser dynamic class generation again today). IE - move some of the *core* widget concepts out of zope.app and into formlib, and finding ways of severing the zope.app dependency from zope.formlib. Move some of the core interfaces up a level, and make the ones in zope.app.form extend those core ones. If application server (still a term I'd like to see defined in this context) becomes a priority, or a separate priority, or we just start thinking about what needs to be done to make core things simple, powerful, and sharable; and how to build the Application Server on that to give people a variety of development/deployment options or pre-built tools to help with so-called large applications then I think this could be a good thing. But if it all becomes one big overwhelming library/server/solution again, I can't stick around for that. I don't need something with the weight of Plone or the CMF to make an itinerary manager. Super terrific content management tools aren't going to help me build a state heavy e-commerce application. Getting too tied up in the concepts of containers/containment/all objects are like this mentality isn't going to help us deliver a sprawling enterprise payroll management system from five different data sources. The loose coupling of Zope 3 makes doing these different systems in Zope using a similar development technique for each possible. I want to make sure that the loose coupling remains useful and usable, that trying to use a particular widget isn't likely to make my system need to register 80 supporting components and sub systems. Hopefully some simple guidelines can stay in place and stuck to in regards to how to make sharable components sharable. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
. ;) Perhaps it's not the greatest name, but I've become enamored with *lib names like 'formlib'. 'zopelib' Hmmm. Not the prettiest thing. But it does say Zope Library. If that becomes the *core* of the mythical Zope 5, awesome. I still like having a web server with Zope 3. Advantages of this vision: - Zope 2 users don't need to leave Zope 2. yay - Zope 3 doesn't have to reproduce all Zope 2 features. yay - There wouldn't be confusion about 2 Zopes. It is important that Zope 5 be backward compatible with both Zope 2 and Zope 3, although not necessarily in the same configuration. Many people are building Zope 3 applications today and they should not be penalized. Thoughts? Would it be a significant retread or loss of traction to do this now? I wouldn't want to be stuck with Zope 3.2 for another four years. On the other hand, if this gets the zope.bobo project moving forward, and re-addresses packaging/setup, I'd be all for it. Regarding packaging/setup, I'd like to answer how do I install just part of Zope?... Or I guess, really, I'd like to see something that (I guess?) works with paste.deploy, or an enhancement/replacement of the current instance home builder. One that would provide options like: * Create skeleton zope.publisher application. Provide your own storage. Best for completely custom or small applications using other available options for templates, etc. * Create skeleton zope.publisher + zodb application. Provide your own root and skin. Develop rapidly and store Python objects naturally without a translation layer. * Create full Zope 3 application server instance. Customize skins, packages, etc, by modifying configuration. Work with other Zope 3 application server packages easily! Maybe with options regarding the server as well. (twisted, zope.server, 'I have a WSGI server already'). But this way, all of Zope could still be in a single download (no having to pick through a hundred different editions ala Microsoft), but provide entry points for web application developers and situations that don't need the full thing. I see a lot of simplicity combined with a fair amount of power in some other offerings, from Ruby On Rails to TurboGears to Seaside. But I think that many of those (perhaps with the exception of Seaside) have a mediocre or magical core architecture that could grow up to suffer problems similar to those that affect Zope 2, problems that the component architecture is meant to solve. Those are my own selfish desires anyways. I still believe that if we can build and deliver a solidly defined core, then we (or others) can do anything on top of it - a full on replacement for ZClasses, continuations based development with through the web shadowing of file system code for custom inline tweaking, continuations based programming where a page fades away as a concept and it's all just live objects on a screen with a natural flow for development of state intensive apps, something without any of that for development of state-carefree content delivery apps with nice URLs and aggressive caching, and so on. :) So again, if this would help us define that core *and make it usable in a variety of configurations*, then again I say 'yay'. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Brainstorming about browser pages
Python class
- all you needed was ZCML. But when you needed to step up and do just
a little bit more, or just a little bit different, or just run the
status message through your own page notification API, things got a
*lot* harder. (This is a common meme of mine, it seems - if you go out
of the way and make things really easy for certain use cases and take
care of too much behind the scenes, you may get a happy user for the
first two days. But on the third when he needs to do something more
than the automatic tools provide and tries to find answers and finds
brick walls or mazes of ZCML metadirective handlers, THAT's when you
lose them; THAT's when the learning curve complaints start; THAT's
when you see strange hacks in other peoples code that make you go why
did you do that? and they go I couldn't figure out any other way to
do it so I copied this from the root and changed some things but I
still don't know why it does what it does...).
Third thing:
What if someone wants to customize this view by changing the template
but not the helper method? You either have to subclass this view class
and add a custom __call__ to your subclass, or you use *named
templates* from zope.formlib:
Nh. I don't like this, but I can't tell you why. Maybe just
because it's too complicated. Same goes with your usecase 1. I
actually don't want to create a boilerplate class just to hold page
templates. And sure, if we could get rid of the automated class
creation in Usecase 3b, then I'd might opt for getting rid of this
class creation too, but now I just don't see why.
On the other hand, in most cases it means I'll create one view class
per object and tuck a lot of templates on it, but still, it doesn't
feel quite right...
I'd say it feels very wrong, in fact, had I not done something sortof
similar with head resources recently. But those were just ways of
compressing five lines of viewlet registration per javascript/css
resource that were meant to be used on every-single-page-in-the-system
into a single line of Python each. But those items aren't providing or
requiring the sort of intelligence that a view might.
Maybe I feel that way because I use page templates less and less and
have broken things out into small work units that generate HTML
through a simple generator based (loosely) on Nevow's STAN. About the
only full Templates I register any more are macro collections -
standard template, form templates, etc. I find that with almost
everything else, at least based on recent work, that I do want a view
class living along side my template. Very few objects in my system
really have the guts to format their data on their own properly, so I
always need at least *some* kind of support.
If done properly, having this::
class ArticleDisplay(PageView):
template = ViewPageTemplateFile('article.pt')
[ZCML]
browser:view for=..interfaces.IArticle name=article.html
class=.pages.ArticleDisplay/
seems pleasant enough. Then when you need to format the 'description'
field through something like newline_to_br, or present computed dates
('updated 4 and a half hours ago'), you already have a place to hang
them. Whereas with this::
browser:page for=..interfaces.IArticle name=article.html
template=article.pt/
You don't. And then you won't want to put the nice formatter on their
because your brain hits the oh, I need to make that into a class...
Ugh, not right now moment. And you find yourself staring at a page
that you want to make prettier, but there's _just_ enough annoying
effort involved to keep you away from it. At least, that's been my
personal experience, but I'm also a bit of a crank.
So this (what I show immediately above with the false 'PageView'
subclass) is effectively the pattern I've started enforcing for all of
our new work, and it can be done now in what ships with Zope 3.{1,2}.
A two line boilerplate Python class now saves headaches later.
--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 web root
On 2/17/06, Shane Hathaway [EMAIL PROTECTED] wrote: Incidentally, I find it difficult to make any argument about anything because I fully appreciate many sides of the issue. :-) You and me both :) Gary Poster: one could argue that ZODB-based TTW dev got to be so problematic *because* it was so successful. There are strengths there. That said, I'm eager to see what you might think up as an alternative: I think both paths might be fruitful. Personally, I like the idea of third party alternatives. I think one of the most extreme and interesting portlet style implementations is Seaside's halos. When they're turned on, from what I can tell from the few times I've looked at Seaside and related documentation, you have a lot of customization power. It's not for everybody. But I think it's an implementation that personalizes Zope 2 style Through The Web capability by localizing what you edit to the component that you see. http://blogs.inextenso.com/seaside/blog/learning/0cf6f89c-7824-11d8-81ca-000a27b05150 http://www-128.ibm.com/developerworks/opensource/library/os-lightweight8/ CSS, HTML, and Smalltalk Source for everything is accessible - but it's accessible *in place*, not buried in a completely foreign interface or buried deep within a master template or script... It's still object oriented. Fascinating. But as I said earlier, this is something that Smalltalk's image oriented development supports (where all of the code lives inside a virtual machine/environment, away from any concept of files). The ZODB *can* behave like this, but that only works best if all concept of code-in-the-ZODB-image is separate from any-kind-of-data that might be in it. Anyways, that's an aside. It's not something I nor any of my customers need. But it would be an interesting thing to see someone take up. The web root is my best idea for an alternative. Although I've been talking about addressing the needs of new adopters, I'm really trying to address *my* needs. I want to build a complex web site using Zope technologies, but I don't yet know enough about what I'm building to be able to do any model/view separation. I intend to write dirty, filthy, unmaintainable code. It's the right thing to do! If it works, I'll clean it up. If it doesn't, I'll throw it away and try something else. If I write it with Zope technologies, I know I can succeed at cleaning it up because Zope has the most powerful tools out there. If I write it with Apache, I'm certain I'll end up building my own framework to support whatever flavor of messiness the solution generates, it'll take twice as long, and it will be impossible to clean up, so I'll have to start over if I want it to last. Gimme Zope! While I'm writing messy code, I also invent messy processes along the way, and ZODB can't easily support my random new processes. I often write automated tests for messy code. I often think to myself, what is the ugliest possible way I can write this? Then I really do it and laugh. That gets me moving when I'm stalled. Sometimes I rewrite something ten times, relying on version control to get me back. It turns out that the CMF skins tool is much better at supporting this kind of work than Zope 3 currently is. I want Zope to encourage clean code just like everyone else, but interesting things rarely start out clean! If Zope wants to be a platform that people can use to invent crazy new things, it has to allow for messy code and processes. Where doesn't it allow this? I wrote about this in Griddle Noise earlier this week. I feel more free to mercilessly restructure in Zope 3. I feel free to write things crappy or mediocre initially. Most of our big projects have been done under hard deadlines and technical debt was accrued along the way. But much of that debt was easy to pay back, sometimes with just a day or two of postmortem reconstructive surgery. How is the skins tool better than actual Python classes as view objects? They're still on the file system. They can still be under version control. The page templates are still on the file system. They can still be under version control. I guess I still don't understand how you're using Zope 3, because it sounds like you're using it very differently than I am. I've long since abandoned the ZMI. I never see that list of addable objects (in fact, in my newest applications, I completely bypass IAdding). I basically see the Zope 3 ZMI long enough to add one of my sites/applications. At that point, my skins take over, and that's all I see. The rotterdam skin is there as last resort to get out of trouble or to tweak local utility configurations. I guess I've just made some supporting libraries and frameworks to help me. I had this with Zope 2 too, but it's been easier to do with Zope 3. I encourage everyone to do this. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman
Re: [Zope3-dev] Zope 3 web root
On 2/16/06, Shane Hathaway [EMAIL PROTECTED] wrote: Jeff Shell wrote: I agree that better integration with external data should be a priority for Zope. But what does that mean? In theory, if something's a Python object it should work with Zope 3 with relative ease... If that's not the case, perhaps we need to look at how much work is required to take some random Python object that may be created by some random data access library and get it into a Zope 3 published web page. If it kicks and screams and resists security and interfaces, or what not, maybe we need to take a look at all of that. Let me focus the discussion: I think it's nearly always a bad idea for anyone, newbie or expert, to put a template or script in ZODB. Do we have any agreement on that point? I wish we did. I enjoy ZODB for many purposes, but not for storing templates and scripts. I agree, generally. For one customer, we (sparingly) use page templates in the content space of the ZODB. But those are usually only just one or two lines. Nothing fancy, nothing programmatic. But also not a situation that would require a special view object in that space. Other than that - I completely agree. Your proposal just sounds like you want to have things like we had in Zope 2, but as pages and scripts on the file system that are executed/rendered semi-automatically. And that seems like it comes back to a problem that existed with Zope 2. Ignoring the ZODB for the moment, there's just a bit of a gulf between templates and scripts and browser view classes/components. The obvious question is, if templates and scripts are special enough to not belong in ZODB, what else is so special? It's really hard to say. In fact, I can think of rare situations where I actually do want to put templates and scripts in ZODB. Well, anything can theoretically be stored in the ZODB. You can put scripts and binary images into an RDBMS just as easily. Whether that's a good idea is a separate issue. I think that Zope 2 suffered heavily from the too many ways to do it when it came to ways of doing development, and there were gulfs between each style. Each style had its plusses too. ZClasses certainly had an appreciative audience who liked defining schemas and building forms automatically through the web with little programming required. But working with templates and scripts in ZClasses had a bit of a different feel and behavior than working with those things in the 'content' space of the site. And it was very different than working with file system based products. If there's one (and only one) dominant way of developing for Zope 3, that story is easier to tell. Do you want to make things easier for newbies by telling them well, you can just put some scripts and templates on the file system, it's that easy! and well, if you want to really develop properly for Zope 3, you need to do this...? That's where I think this web root makes things easier for newbies argument falls apart. If you want to do scripts and SQL on the file system, there are lots of other options that do the job better than us. I think we have more important things we could spend the energy on. On the other hand, if I've completely mis-interpreted your initial proposal, feel free to ignore all of the above. At one extreme, ZClasses tested the hypothesis that everything, including code, belongs in ZODB. I think experience has proven that hypothesis wrong. The persistent code idea in Zope 3 tries to give ZClasses a new birth, but it seems to have turned out even more complicated than ZClasses. There are certainly advantages that can be gleamed from image-based development. I've seen some really impressive things done with Seaside. But Smalltalk (and its developers) are used to that kind of environment. It's less natural for Python. If persistent code doesn't behave quite like regular Python code, then there's still a gulf that has to be crossed when one wants to move up from persistent code. So yeah, I agree - not everything belongs in the ZODB. I agree vigorously! And that's what I'm arguing in favor of. It's so easy now to just have: class Article(Persistent, Contained): tags = () body = u And bam - articles! No translation layer, nothing. Put those in the ZODB and go to town happy. That eliminates the two extremes, so there's no need to talk about those anymore. We have to choose what belongs in ZODB and what doesn't, and the decision is often important but not easy. I think that the decision only gets important when one is concerned about optimization of writes, reads, etc. IE - when does one really want the ZODB, and when does one want an RDBMS because it has better disk access or backup tools or supports a kind of ad-hoc querying needed by a particular application? I guess I saw that templates and scripts are there in the Rotterdam skin. I seldom even see that skin any more so I guess I just don't notice. I think I tried using a 'through
Re: [Zope3-dev] Re: Last chance to comment on Simplify skinning
On 2/15/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: I find Zope 3's approach much simpler and much easier to explain than the CMF's approach. In Zope 3 (especially with my proposed changes in place), a layer is simply a label (read: marker interface) on the request. When we now look up pages and resources (e.g. images), we take the request into account and therefore inevitably that label. We will only find pages and resources associated (read: registered) for this label. Good news is that any page or resource can be associated for this label, we just have to remember to do that in their ZCML directive. When you say with my proposed changes in place, I don't understand how that differs from what currently exists, or what can exist. We at Bottlerocket started serious Zope 3 work with Zope 3.1. We've been defining skins and layers as Interfaces since that time. I didn't understand it entirely at first, but when I was debugging some issues that arose with a fix to multi-adapter lookup that came in Zope 3.2, I understood it more, and now it makes a lot of sense to me. So coming from that world, I'm not entirely sure I understand how your proposal is really different, except for this: In your proposal, 'Skins' are just gone as a separate concept - yes? What is now treated as a Layer can also be treated directly as a skin, yes? Here's a situation from a recent application of mine. The comments and doc strings are verbatim. Notice that I leave a number of breadcrumbs behind about which is the skin and which is the layer:: # Layer class KBase(IBrowserRequest): The ``kbase.skin.KBase`` **Layer** # Skin class KnowledgeBase(KBase, CMS, IDefaultBrowserLayer): The Knowledge Base Skin. Uses the CMS layer, but **not** rotterdam. The Knowledge Base skin is very specialized and does not need as many generic features as the Content Management or default ZMI skins. The primary dependance on the CMS layer is to get its resources (javascript libraries, icons). I assign most things in my application to the KBase layer. The KnowledgeBase Skin builds from three layers. Very early versions of this app did a mix of layers and skins in the bases used for ``KnowledgeBase``, but the skin it used brought in too many views that I didn't want interfering with things accidentally, so I went with the ``CMS`` layer instead so I'd get things from our CMS layer, but not get *everything* that was chosen for the *Content Management* skin. Does that make sense? If I understand your proposal correctly, the Layer and Skin above would both basically be the same thing, right? The only thing that I guess really differentiates them right now (in my application) is how they're registered in ZCML. But they're each the same basic collection of interfaces. ``KBase`` is shallow and dedicated to the browser view/resource components in my application, ``KnowledgeBase`` is rich and pulls in components from others. The only thing that I don't understand right now is this concept of Interface Types. I don't have our Zope 3 book in front of me right now, so I'm not sure if it has anything helpful to say. But I'll just say that Interface Types have been an elusive concept for me, so far. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
On 2/13/06, Stephan Richter [EMAIL PROTECTED] wrote: On Monday 13 February 2006 07:57, Philipp von Weitershausen wrote: Yet again looking for comments, this time at: http://dev.zope.org/Zope3/OneNamespaceForZCML. -1 Here some comments: - You do not argue how the decision-making process is highly inconsistent. - I do not understand what's so bad about coming up with your 3rd-party ZCML directives. They are extremely easy to write and use. I think that 3rd-party ZCML directives are not a bad thing. And yes, I would like to keep those in a separate namespace. I am also -1. But I take issue with your second statement. ZCML directives are the hardest and scariest code in Zope 3 to understand. It was easier to figure out what was going on with multi-adapter lookup than to figure out how menuItems work! (I lost a day trying to figure out if I could just put a javascript condition on a menu item before coming up with a glorious trick). I still HATE magical ZCML. But I still think ZCML is a good thing and should be modularized. Simplified - yes. Modular (namespaces) - yes. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Selecting a code name
drive me crazy after a point because I just don't find the worth in keeping my internal translations up to date. If the next release is going to be sexy, I still think that there should be good articles written as the release approaches. From New in 3.2: zope.formlib, why it's better than zope.app.form, how to start using it to Deprecated in 3.2: i18nmessageid versus i18nmessage and how it affects you (especially if you don't know anything about internationalization) It's like the difference between this, which we have: http://www.python.org/2.4.2/NEWS.html http://www.python.org/2.4/highlights.html and this, which I absolutely love: http://www.python.org/doc/2.4/whatsnew/whatsnew24.html I know that even I would care a lot less about new Python releases if it weren't for Andrew's terrific documents. And while they're not comprehensive, they're great for quickly getting that oh, so that's what that new thing is! enlightenment. But with 3.2, some of the new big features seemed to be surprise to even some core developers: Viewlets made it? Whoa... So if Viewlets are in Zope 3.2 Xing Hua and no one knows about them, does the fancy branding make a sound? This is an important discussion and I don't think I'm saying anything new here, at least not new for me. I just want to say that 'brand' is very important, and not to be taken lightly. But also there are far more important things than coming up with fancy names. There's been a lot of discussion about packaging and releases - very important, I think. I had to write my own little semi-packaging system because I was pulling in so many disparate and useful third party tools and had our own stack and getting it all out of the various subversions and CVS repositories and into something usable and something I knew would work with the released version of Zope (or released version we're using for a particular suite of apps). 'zpkg' was way too hard to figure out. Eggs... Hell if I understand them anyways. So while it's great there are so many useful tools and libraries people have made available, who thinks they could write a page for the mythical Zope 3 web site that says You've just downloaded Zope 3.2 - Now what are some other things you can use with it? [list of packages, easily downloadable and installable] Again, knowing I have Zope 3 Clemens is of no concern if I have to spend another hour arguing with subversion and CVS and then finding out what I checked out worked with the upcoming Zope Big Muddy but not Clemens. So I say - let's focus on the points you and others have brought up about good informational resources, and just make 'Zope 3' a strong brand by making it a strong brand. Otherwise, it's like those episodes of The Wire where Stringer Bell, basically in charge of half the drug trade in Baltimore, was trying to figure out how to keep people coming to his corners when their product was inferior to the dope the east side boys were slingin'. In a business class he learned that changing the name was an option, and soon the corner boys were calling out different names every other day for the same sorry product. Without a change in quality, it doesn't help. This is the proposal that considers the most serious consideration in my opinion. The original discussion showed that a lot of people found Zope's lack of branding a problem. Now it's time to find a solution to that problem. Something that I admire about Ruby on Rails, Django, MochiKit, and TurboGears all is that they're opinionated, proud of it, clear in their message, and all seem to have a similar degree of respect for simplicity and communication. I hope that's the message that people are getting. You're right in what you say earlier - you can visit these sites and instantly get a grip on what's going on. (On the other hand, 'eggs' and 'paste' and all of these other things, I still don't understand). Alright, I've stayed up way too late on this. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Selecting a code name
On 2/7/06, Stephan Richter [EMAIL PROTECTED] wrote: On Tuesday 07 February 2006 05:09, Jeff Shell wrote: Alright, I've stayed up way too late on this. Jeff, you always make great points! I would like to nominate you as the Zope 3 Propaganda Minister! :-) No seriously, you have a great way of explaining why Zope 3 is better than the latest hype; I think you are probably the best qualified to lead the marketing efforts? Are you willing? Anyone seconding me? :-) I'm willing, if I can make the time. And if I can make the time to write the lengthy emails that I do, I can write a real document, right? :) Last night I was looking at this page: http://www.zope.org/WhatIsZope and going damn, that's nice and then damn, I wrote a lot of that! There was some pre-existing material, but I remember updating it into the form that it stands at now and has stood at since. It really makes me want to register a whatiszope3.com and putting a page like that up. I've really really really been wanting to do this, and I've talked with the other guys here about doing something.. anything... to give back to the community. Heck, I've been wanting a little server here that I could play with in making a public facing Zope 3 application. But our resources have been severely limited :\. I may still go ahead and make a static page for now, or a post in Griddle Noise. Or even make a Writeboard.. Or a page in my Backpack account.. Or.. So many options, but so many deadlines. But I'll do my part to try to do something in the next few days. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] ZCML bad ;-)
On 1/24/06, Chris Withers [EMAIL PROTECTED] wrote: Gary Poster wrote: FWIW, me too. I'm no XML guru (as Fred will attest ;-) ) but reading the namespaces on an XML file seems like basic XML procedure. Well, the reading of them is the lesser of my two complaints... I find it irksome to have to type them at the top of ever file. Is there no way that they could be pre-bound in the XML parser? That way you'd only need to inlcude them if you wanted to rebind them... It's like those damned imports in Python. Why can't everything just be available in one big honkin' namespace automatically? ;-) Seriously - it's not that bad. ZCML's use of namespaces is judicious, I believe. There's no namespaced attributes - just the directives. I too use browser: as the default namespace in my browser focused ZCML files. There's only one or two things to type, ever. The namespaces are easy to remember. I can't believe it's a big deal at all. It's certainly a case of 'explicit is better than implicit', I believe. Like with Python code and modules and avoidance of import *, it makes all names easily traceable. Are you using an editor that makes it difficult to go to the top of the file to check on the names? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: ZCML bad ;-)
and concept. I'd like to see more of a move in that direction for the core facilities. Instead of write these n lines of ZCML to auto-generate an edit form for a schema/interface, it should be write these 5 lines of Python to generate that form, and 1-2 lines of ZCML to register it, name it, and protect it. And then, as the user may need to customize the form, they can add to this class instead of having to span the two worlds of ZCML automation and Python. It's much easier to go up a good and simple base class tree and read / understand the code than it is to go through ZCML meta configurations. And it makes the distance between the main doctest documentation and how things work a lot shallower. (I liked viewlets a lot more while reading the main viewlet info file, and liked them less after reading about and wrestling with their ZCML directives). -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] schema api
I noticed that modules that begin with an underscore aren't shown in apidoc in Zope 3.2. I think (but am unsure) that Zope 3.1 showed these. I'm sure there may have been a good reason for doing this, but it makes navigating the zope.schema package for documentation even more difficult. In particular, there are the convenience functions in the _schema.py module that are useful for schema querying. getFieldNames, getFields, etc... I can never quite remember what's in there and which ones return sequences of tuples and which return mappings or lists or iterables. There's also no easily visible list of all of the fields available from zope.schema.*. The interfaces are there, but people interact with the classes in this package more than their interfaces. Since all of the fields are defined in _bootstrapfields and _fields, they're no longer visible. They can be found from the interface down in the factories/classes section, maybe that's good enough? -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Principal Comparison and/or References
I found an issue with zope.app.undo's ZODBUndoManager wherein it only
could undo principal transactions if the principal in the request came
from the global principal registry. I tried patching our copy by
changing it to look up the principal of a transaction record from
zapi.principals() (gets the nearest IAuthentication utility).
When it tries to do the undo, it compares request.principal against
transaction['principal'] with identity comparison (' is '). That
doesn't work for pluggable auth principal folder based principals,
even if by my own assumptions and simple application setup they are
the same.
With all of the other principal / group mini-proposals going on, does
there need to be a way to strongly (if that's the right word) compare
a principal looked up from an id that came out of... well, somewhere
(a transaction log record, a string stored in the 'creators' dublin
core sequence, etc), or even against each other?
b3_1 = zapi.principals().getPrincipal('brcms.user.3')
b3_2 = zapi.principals().getPrincipal('brcms.user.3')
b3_1 is b3_2
False
b3_1 == b3_2
False
Comparing the id attribute works. Is it reasonable to assume that
zapi.principals().getPrincipal(request.principal.id) should return the
same principal as request.principal? And thus if
somerecord['creator_id'] == request.principal.id, that's considered a
good match?
--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: abolishing python: expressions in ZPT TALES
On 1/3/06, Wade Leftwich [EMAIL PROTECTED] wrote: Andreas Jung wrote: To bring it to the point: _scripters_ should be able to develop in Zope 3 as easy as in Zope 2 :-) Or at least almost as easily as in RoR or Django. TTW is not a requirement; Chris McDonough's TTB posting was right on target (http://www.plope.com/Members/chrism/ttb_programming). Are those 'scripters'? I see RoR and Django going down the same path that Zope 2 went down. They're great, they're young, they're inexperienced. Django's horrible query syntax reminds me of the cryptic early index querying that Zope / Principia had that was geared primarily for input coming in from web forms and not scripting. I see both of those projects taking either shortcuts or blanket we only do things this way statements. [Django: we don't support HTTP auth. We've never needed it.]. It's not to say they're bad products at all. To work in Django, you essentially are using Django's admins, which apparently many of their target users don't mind. This is akin to just using and promoting the Plone UI, the ZMI (zope 2 or zope 3's) or whatever. Neither I nor my customers have wanted those UIs. I love Zope 3 for finally giving me the freedom of detaching from the ZMI completely (with me having the option to use it for emergencies, but our own much more focused skins should do the job well enough to not need it). There are 3 PHP developers in the group I work in, and they know they want something better, and they like Python. But when they look at Z3 they get all upset confused. I like Ruby. But when I look at rails I get all upset and confused. I still have no idea how its widgets work. With Zope 3, I was able to follow the adapter lookup chain. Granted, I'm pretty familiar with Zope 3's component architecture by now. Zope 3 needs better advocacy. It needs better web site(s). If zope3.org turns out to be a Wiki I promise to take extra medication and try to add some helpful material to it as possible, because I think Zope 3 is really lacking in different levels of tutorials from different authors who have different perspectives that may better help different audiences. *whew!* That's the problem. It's great that there are books out there. But there's no good central and well promoted advocacy sites. Many Zope 3 developers, like myself, I imagine are often very heavy with real work engagements and finding spare time to write and advocate aren't there. Is this (increased usability for non-experts) a possible project for the Zope sprint at Pycon? I'll be there. And since I am not an expert myself, I will have a head start. I still think that a great increased usability could come from a zope3 focused web site that is simple and fun. With the time based releases, it's known what's going to be in each release. My gods, I'd LOVE to see articles like Exploring Zope 3.x: New feature - Viewlets. I'd LOVE to see clear documents like Exploring Zope 3.x: what's deprecated, why, and how to fix it. The doctest documentation about content providers, forms, and viewlets are great for experts. At least there's fairly comprehensive documentation that I can read and figure out and go ahh!. But turning that into a more comprehensive non-expert story on a web site would be a good thing. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: abolishing python: expressions in ZPT TALES
-1. I use them very rarely, and expect to use them less with Viewlets now in the picture. But there are still little situations where Python expressions are handy, especially on big-macro templates where there's not a backing view. I'm not advocating programming in page templates, but there are some boolean or quick-transformation (ensuring a potential iterator/generator is a list and has length) that needs to be done out in this phantom land. As I mentioned above, I really believe that Viewlets and Viewlet Managers will help with these big complex templates which provide the look and feel of the front page or the basic template. But I know that sometimes, when putting those pages together from a designers input on a tight deadline with multiple browsers to test, the quick math and other small expressions we can squeeze into those spots have been a life-saver, even in recent weeks. On 12/28/05, Rocky Burt [EMAIL PROTECTED] wrote: Hi all, Please don't mistake this as a proposal or anything of the sort but I was just curious what the rest of the zope3 community thought on this particular topic. (Please forgive me if this topic has been exhaused to death already) Its my personal opinion that anytime a page template requires logic complicated enough to warrant using a 'python:' expression, that logic should be re-thought and placed into a view class. I know that some python: expressions are fairly simple, but for an HTML designer, *any* python: portions are dangerous to touch (and shouldn't be touched by the HTML designer). What do you all think? Regards, Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] URGENT RFC: Is anyone using response.write in Zope 3?
I was using it in some custom views for HurryFile based images. I've removed it since I started testing our code against Zope 3.2. Right now I just return the hurryfile binary data with a return statement (one big chunk), but am looking forward to knowing how to return long output. On 12/19/05, Jim Fulton [EMAIL PROTECTED] wrote: When we refactored the Zope 3 pubisher to work more closely with WSGI, we decided to remove the response.write method. We should have written a proposal for this, but we failed to do so. Over the last few weeks there has been much discussion of this in which I asserted many times that I didn't think any applications outside of Zope 3 itself used this method. No one has disagreed with me. I want to double check this. Does anyone have any Zope 3 applications that are using response.write? Assuming that the answer is no (or that no one answers today), I'm going to more clearly document how to return long output and I'm going to add a method that generates a hopefully helpful error. Note that we may add this method (or something like it) back in the future to support chunked streaming output, Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] URGENT RFC: Is anyone using response.write in Zope 3?
Yes, it's hurry.file. What's Tramline? We're using hurry.file for small images, generally, and it's been working fine. We've recently written a cache manager that writes the images out to the file system where Apache can serve them. So when that's in place (and working), efficient image serving from Zope is not that big of a concern to us... But back to the issue at hand - knowing how to better serve those out to the response would be a big help. On 12/19/05, Martijn Faassen [EMAIL PROTECTED] wrote: Jeff Shell wrote: I was using it in some custom views for HurryFile based images. I've removed it since I started testing our code against Zope 3.2. Right now I just return the hurryfile binary data with a return statement (one big chunk), but am looking forward to knowing how to return long output. Is HurryFile the same as hurry.file? You know of course hurry.file is pretty inefficient if you don't use tramline (which still needs integration into hurry, patches welcome :). Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: View lookup changes in Zope 3.2?
Is it related to this? Bug in Multi Adapter Lookup?
http://www.zope.org/Collectors/Zope3-dev/396
('fixed' in Zope 3.2b1)
That's my suspicion. This is a major blocking / freaking out kind of
issue. I'm trying to figure out now how to crawl through the debugger
and test the 'getMultiAdapter' lookup for this skin + object to
compare the results and hopefully.. I don't know. I have a pretty
complex view declaration that's meant to replace 'contents.html' for a
lot of our containers, and I'm hoping that I don't have to re-declare
the view for each container type. I guess I should also learn more
about how everything collaborates to establish an objects interfaces
and in what order so I can ensure that the base Zope interfaces are
lower on the providedBy list?
On 12/12/05, Jeff Shell [EMAIL PROTECTED] wrote:
Today I finally got around to installing Zope 3.2b1 and started
testing one of our sites against it. I'm running into a few problems,
some of which are my fault, some that I don't quite understand, and
one that is really bad.
We have been basically rolling a custom CMS in Zope 3, and the content
management skin that we made has been working wonderfully in Zope 3.1.
One of the key parts of our CMS's user interface is a custom contents
view that uses MochiKit for javascript/DOM based table sorting (easy
sorting on item name, title, and size), and uses MochiKit's AJAX
support for inline renaming/retitling of items in the container.
That's registered as 'contents.html' for our own base contentcontainer
interface. We've also made a custom metadata view that allows editing
of keywords (subjects).
In Zope 3.1.0 both of those worked fine.
In Zope 3.2b1, I'm getting the Rotterdam or default contents view,
wrapped up in our template. The same goes for the custom '@@+' view
I've made for the same objects, which is used to filter certain Zope
entries out of the add menu. For our container objects, I'm also
getting the Zope meta-data view, but on some of our custom content
objects I get our replacement view.
I use our own menu, 'cms_views', for tabs, and have contents and
EditMetaData registered as actions.
If I rename my 'contents.html' view to 'contentsplus.html', I can see it fine.
Here's my skin setup:
from zope.publisher.interfaces.browser import IBrowserRequest
from zope.publisher.interfaces.browser import IDefaultBrowserLayer
from zope.app.rotterdam import rotterdam
class CMS(IBrowserRequest):
The `cms` layer.
class ContentManagement(CMS, rotterdam, IDefaultBrowserLayer):
The Skin
configure:
layer name=example.cms
interface=example.cms.skin.CMS/
skin name=example.cms.ContentManagement
interface=example.cms.skin.ContentManagement/
and the contents.html view starts with:
view name=contents.html for=example.cms.interfaces.IContentContainer
permission=example.cms.ManageContent
layer=example.cms.skin.CMS
I'm referring to the layer with its interface path in ZCML, always.
If I moved 'rotterdam' out of the base interfaces for the
ContentManagement skin and set it as the base for the CMS layer
object, the same behavior still shows up.
This setup works as I expected it to in Zope 3.1, but breaks in Zope 3.2.
FWIW, I opened up a debugzope session in both Zope 3.1 and 3.2 in this
same configuration just to check the list of providedBy(obj) for the
same folder in each site, to see if the interface resolution order
might have changed, but the lists appear to be identical.
Bug? Or did I do something wrong in my Zope 3.1 implementation that
Zope 3.2b1 has fixed?
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: View lookup changes in Zope 3.2?
On 12/13/05, Jim Fulton [EMAIL PROTECTED] wrote:
Jeff Shell wrote:
Is it related to this? Bug in Multi Adapter Lookup?
http://www.zope.org/Collectors/Zope3-dev/396
('fixed' in Zope 3.2b1)
That's my suspicion.
That would be my suspicion too. It should be easy to test.
Just get a check out and merge out that change:
svn merge -r40385:40384 svn+ssh://svn.zope.org/repos/main/Zope3/trunk
and see if you still have the problem. If you don't, then you still have some
digging to do. If you do, then well, lets get into that if you
verify that that is the problem.
This was an honest-to-gosh bug. It is also the case that there were
registrations in Zope that depended on this bug and had to be changed.
Going through a lot of debugging, it looks as through it has to do
with how things are ranked in
zope.interface.adapter.AdapterLookup.lookup() for multi-adapters. I
haven't stepped through it in the debugger in Zope 3.1 yet, but I just
got finished doing it in Zope 3.2 and these are my results:
from zope.app.component.hooks import setSite
from zope.publisher.browser import TestRequest
from zope.app import zapi
from zope.publisher.interfaces.browser import ISkin, IDefaultSkin
conman = zapi.getUtility(ISkin, name='br.cms.skin.ContentManagement')
customer = debugger.root()['customer']
setSite(customer)
winter = customer['winter']
contents = zapi.queryMultiAdapter((winter,
TestRequest(skin=conman)), name='contents.html')
contents.__class__.__bases__
(class 'zope.app.container.browser.contents.Contents', class
'zope.app.publisher.browser.viewmeta.simple')
So then I do a pdb.run(zapi.queryMultiAdapter((winter,
TestRequest(skin=conman)), name='contents.html')) and it's inside
AdapterLookup that I get the following. When all of the adapters for
this container and the request with the name 'contents.html' are
looked up:
(Pdb) pp byname.get(name)
[((InterfaceClass zope.app.folder.interfaces.IFolder,
InterfaceClass zope.publisher.interfaces.browser.IDefaultBrowserLayer),
class 'zope.app.publisher.browser.viewmeta.Contents'),
((InterfaceClass br.cms.interfaces.IContentContainer,
InterfaceClass br.cms.skin.CMS),
class 'zope.app.publisher.browser.viewmeta.contents.html'),
((InterfaceClass br.cms.interfaces.IContentFolder,
InterfaceClass zope.publisher.interfaces.browser.IDefaultBrowserLayer),
class 'zope.app.publisher.browser.viewmeta.Contents')]
The one the I want is the second set in this list, 'br.cms.skin.CMS'.
Unfortunately, that's the one that loses out in the ranking algorithm
that ranks based on interface's ranking in the spec resolution order.
(NOTE: The IContentContainer there is different than the Zope
IContentContainer! This has cause some confusion in house)
The first one (IFolder, IDefaultBrowserLayer) produces the rank: (4, 4)
The second one, which I want, (IContentContainer, CMS) produces the rank (12, 2)
The third one, which I'm suspecting is generated from a zcml
containerViews directive, wins with the rank (3, 4).
It wins because the 'best' tuple is kept around. A rank wins 'best' by
being less than the current 'best', and (3, 4) is less than all of
them.
I understand why this is happening, but it's (obviously) not what I
want to have happen. I want MY skin layer's declaration of
'contents.html' to win out. It actually works for all container types,
so maybe I need to declare it for a root Zope container interface for
my layer?
I've been living under the impression that the layer a view was
assigned to had higher precedence than may have been intended, and
maybe this is part of the discussion going on in the
'SimplifySkinning' proposal/thread which I should take a closer look
at.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Interface implementation declaration weight (was Re: View lookup changes in Zope 3.2?)
On 12/13/05, Jim Fulton [EMAIL PROTECTED] wrote: Jeff Shell wrote: ... Going through a lot of debugging, it looks as through it has to do with how things are ranked in zope.interface.adapter.AdapterLookup.lookup() for multi-adapters. Yup. I don't know enough about the relationshipd between your content interfaces, to comment directly, but I will note that the intent was that content interface would have precedence over skin. This was not the case before due to a bug in multi-adapter lookup. I'm sure that's the issue here. The software worked fine in 3.1, or basically worked in a way that I assumed was fine. The situations where this is affecting us is in some of our oldest major Zope 3 code, and it's code we've had issues with before. Those issues, and this one, are likely due to it being early code and us (namely me) still learning a lot of core concepts and maybe not applying them so well. So I have a new question: with the different ways that 'implements' and 'provides' may be applied to an object, is there a document that details how those affect the interface/spec resolution order? I'm thinking of things like interface inheritance, class inheritance, ZCML's 'implements' directive, 'zope.interface.implements(IFoo)' in a Python class statement, and any interfaces said to be provided by a particular instance - how much weight does each method provide? A concrete example being: my content management system wants to provide a new 'contents.html' view for the content management skin for all of my different container types, most of which subclass core Zope objects somewhere along the way. I thought that having a root 'IContentContainer' interface was the best way to go - but as subobjects embrace and extend other container types, the 'IContentContainer' interface seems to be getting buried in the resolution order - for the object that I debugged, it ranked 12, while Zope's IFolder ranked 4th and a more specialized CMS content folder interface ranked 3rd. But I want the specialized contents view, which has a lot of sub-pages, so its not something I'd want to have to duplicate in ZCML for every interface, to work for all of them. How can I ensure that IContentContainer (or IManagedContent, or any of my other core-core-core interfaces) DO take precedence over core Zope interfaces for situations where I subclass core Zope objects? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] View lookup changes in Zope 3.2?
Today I finally got around to installing Zope 3.2b1 and started testing one of our sites against it. I'm running into a few problems, some of which are my fault, some that I don't quite understand, and one that is really bad. We have been basically rolling a custom CMS in Zope 3, and the content management skin that we made has been working wonderfully in Zope 3.1. One of the key parts of our CMS's user interface is a custom contents view that uses MochiKit for javascript/DOM based table sorting (easy sorting on item name, title, and size), and uses MochiKit's AJAX support for inline renaming/retitling of items in the container. That's registered as 'contents.html' for our own base contentcontainer interface. We've also made a custom metadata view that allows editing of keywords (subjects). In Zope 3.1.0 both of those worked fine. In Zope 3.2b1, I'm getting the Rotterdam or default contents view, wrapped up in our template. The same goes for the custom '@@+' view I've made for the same objects, which is used to filter certain Zope entries out of the add menu. For our container objects, I'm also getting the Zope meta-data view, but on some of our custom content objects I get our replacement view. I use our own menu, 'cms_views', for tabs, and have contents and EditMetaData registered as actions. If I rename my 'contents.html' view to 'contentsplus.html', I can see it fine. Here's my skin setup: from zope.publisher.interfaces.browser import IBrowserRequest from zope.publisher.interfaces.browser import IDefaultBrowserLayer from zope.app.rotterdam import rotterdam class CMS(IBrowserRequest): The `cms` layer. class ContentManagement(CMS, rotterdam, IDefaultBrowserLayer): The Skin configure: layer name=example.cms interface=example.cms.skin.CMS/ skin name=example.cms.ContentManagement interface=example.cms.skin.ContentManagement/ and the contents.html view starts with: view name=contents.html for=example.cms.interfaces.IContentContainer permission=example.cms.ManageContent layer=example.cms.skin.CMS I'm referring to the layer with its interface path in ZCML, always. If I moved 'rotterdam' out of the base interfaces for the ContentManagement skin and set it as the base for the CMS layer object, the same behavior still shows up. This setup works as I expected it to in Zope 3.1, but breaks in Zope 3.2. FWIW, I opened up a debugzope session in both Zope 3.1 and 3.2 in this same configuration just to check the list of providedBy(obj) for the same folder in each site, to see if the interface resolution order might have changed, but the lists appear to be identical. Bug? Or did I do something wrong in my Zope 3.1 implementation that Zope 3.2b1 has fixed? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Ajax in Zope 3
Bottlerocket has also chosen MochiKit. It's not full of flashy effects, but its Ajax support is nice, it's well tested, and it brings a lot of Python style functionality to JavaScript which makes JavaScript suck a whole lot less (for real - the DOM and Iterator libraries are absolutely great). In the Bottlerocket CMS, Mochikit has been used to give us sortable tables (used in contents view - click a column header to sort by name, order, title, and so on), Ajax based inline renaming and title editing in the contents view, a 'dynamic table' widget which allows adding and removing rows from tabular data for web pages, and more. I generally loathe JavaScript, but working with MochiKit has actually made it a lot of fun. FWIW, as far as Ajax libraries, ZC has chosen mochikit so far. It has a lot going for it. Gary___ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Generations - a missed use case? (Evolving an application for the first time)
I have an application where I'm trying to use 'zope.app.generations'
for the first time. And after much pulling of hair and looking at the
core code, I found what may be a missed scenario.
Basically, we deployed this application for a customer and now they
want some changes. It changes the schema of one item to store values
in tuples instead of strings. I wrote an evolve module, 'evolve1.py'
in myapp.generations, made the schema manager, registered it as a
utility, bla bla bla. But my code seemed like it would never run.
I'd run the debuzope script and look at the database
root['zope.app.generations'], and there was 'myapp' with the value of
1. I'd keep deleting that key and committing the transaction, but my
code would still never run. I tried running it manually using
pdb.run() to step through it and make sure that it was finding the
right objects and doing its job. My code was fine. So I looked at the
code in zope.app.generations.generations and found this interesting
tidbit:
for key, manager in findManagers():
generation = generations.get(key)
if generation == manager.generation:
continue
if generation is None:
# This is a new database, so no old data
if IInstallableSchemaManager.providedBy(manager):
try:
manager.install(context)
except:
transaction.abort()
logging.getLogger('zope.app.generations').exception(
Failed to install %s,
key)
raise
generations[key] = manager.generation
transaction.commit()
continue
(the code continues from there
There's one problem here - in my situation, it's NOT A NEW DATABASE.
There is old data that needs to be evolved, but there's no record of a
generation for this application because there was no need for a schema
manager until now.
I really like the concept and general implementation of the schema
manager, but this scenario is driving me crazy. I could write an
'install' script, but that doesn't really cover this situation. After
install is run, the database marks the application generation. This
makes sense for new applications installing themselves - there's no
old data to update, so if the application is at generation 5, for
example, it doesn't need to be evolved to '5' if all of the data
that's installed or used is already in generation 5 form. (ie - if I
were deploying my application fresh today, my fields would already be
tuples instead of strings).
But my situation, where I already have a deployed application, is not
covered by this. I *could* write an 'install' script for the schema
manager that did this first evolution that I need to do. But then that
installer would have to be updated with all of the future evolutions
as well - since in theory, I could update an application from before
the schema manager and need to bring it up to generation 5 or 8 from
essentially 0.
It seems like the Schema Manager needs an 'evolve from 0' option, with
'0' being set by the evolution script of no previous evolution was
found but (somehow) existing data could be detected. The other
solutions seem to be:
* Write an install script that then manually calls all of the evolvers
to bring things up to the current generation.
* Always put a schema manager in your application, with the starting
generation of 0, so that you can upgrade in the future.
Neither option seems quite tenable - like a bad hack that goes against
the Zope 3 concepts. You shouldn't need a schema manager utility until
you need it, and having a script that manually does
'evolve1.evolve(context); evolve2.evolve(context)'... seems like it
goes against the sort of problem that the generations system is trying
to solve.
Is there something about the schema manager/generations system that I missed?
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] hurry.query in Zope 3.2?
I love hurry.query. Whether it's in the core or not doesn't phase me, but it is really really helpful. We got bit by not realizing that FieldIndex queries passed directly to the catalog/index had a low and high range. It was a small bite. But it took us a while to figure out why searching for 'summer' pages included 'winter' ones, but searching for 'winter' pages only returned winter. So we put in hurry.query. And were able to do it without depending on zc.catalog. It made the catalog experience a lot nicer. I'd put my vote behind inclusion. While the catalog is certainly cleaner and easier to understand than the Zope 2 catalog, querying it is still kindof a pain, which is mentioned in zope.index.interfaces.IIndexSearch TODO This is somewhat problemetic. It means that application code that calls apply has to be aware of the expected query type. This isn't too much of a problem now, as we have no more general query language nor do we have any sort of automatic query-form generation. It would be nice to have a system later for having query-form generation or, perhaps, sme sort of query language. At that point, we'll need some sort of way to determine query types, presumably through introspection of the index objects. hurry.query seems to fill in this hole. On 10/24/05, Martijn Faassen [EMAIL PROTECTED] wrote: Hi there, Would there be any interest in merging hurry.query into Zope 3.2? What it does: hurry.query - higher level query system built on top of the Zope 3 catalog. Some inspiration came from Dieter Maurer's AdvancedQuery. See src/hurry/query/query.txt for documentation. Here's the code: http://codespeak.net/svn/z3/hurry/trunk/src/hurry/query/ And here's a doctest: http://codespeak.net/svn/z3/hurry/trunk/src/hurry/query/query.txt Of course, it probably needs a review and adaptations before it's accepted, and time until the feature freeze in november is short. It would be a very useful addition to Zope 3's featureset, however. It exposes features of various indexes that the normal catalog API does not expose, or if so, only very obscurely. :) Now that I think of it, exposing the ZCTextIndex properly with the various features involved may need the most work. If there's interest, I'd really appreciate volunteers for putting up a proposal on the wiki and integrating it into the codebase. This way it'd get a review by that person. If it'd be up to myself I likely won't have time... By the way, is zc.catalog up for merging with Zope 3.2, or won't this happen yet? hurry.query has a dependency on zc.catalog, though I believe I succeeded in keeping this optional. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope3 website report?
Why is WYSIWYG so important? Who's going to be editing all of that? I don't want another zopewiki.org. I think that zopewiki.org is a good site and that there should be an area of the site that's like that which may be open to the world - but I'd like serious / fun / USABLE documentation to be separate from that. You all know my feelings about Wikis. I walk away from so many technical wikis frustrated. I finally find a page I'm looking for, and it's contents are either: --- MultiAdapter A multi adapter adapts multiple objects --- Or --- HowToMakeAPie I found this link to a tip on this other site and it seems cool. http://www.example.com/how/to/make/a/pie --- As an outsider trying to get started, it doesn't take long for me to get frustrated and walk away. When I may be more settled in and curious about more, full community recipe sites or wikis may be a trove of terrific information. But don't waste my time making me click on page after page. Look at how accessible the quick start, the about, the docs, and more are accessible on TurboGears: http://turbogears.org/ Ruby On Rails has a wiki, but it's a few steps back from the front page, which again makes information well available: http://www.rubyonrails.com/ Django's got an informative web site: http://www.djangoproject.com/ Most of the information one would want on these sites are available within a few clicks, without their front pages feeling cramped and overloaded. Tutorials, quick starts, downloading, getting involved - all close. There are two nice quick start documents written in ReST already. Why don't we make it easy for those authors to put those in a common place first instead of debating over WYSIWYG editing? Let the smart people put the first content together. Make it easy for new people to find information over making it easy for new people to add noise. Are you trying to attract outsiders so that they'll get excited and grow the platform's base, or are you trying to keep Zope 3 within this small community and make it easy for those within this small community to tell each other what most of us already know? It sounds like the priority has been on the latter - make it a site to drive development of the Zope 3 platform itself. I think development is going fine with the tools already in place. Lets drive adoption by making our message heard! And again - that's not to say that the development wiki or a community wiki is excluded from that. But as I showed with the comments of just one smart outsider - getting information about Zope 3 is a frustrating process. On 10/12/05, Martijn Faassen [EMAIL PROTECTED] wrote: Stephan Richter wrote: On Tuesday 11 October 2005 12:41, Philipp von Weitershausen wrote: If anyone here really needs WYSIWYG, please make a point, but I doubt that there will be one... It's a top priority for Jim. Uwe and I agreed we would prefer ReST. I got the impression from Jim that this was just an idea that he wanted to try out. Ideas you're eager to try are different than top priorities, right? Unfortunately having a wiki page in HTML and in ReST is rather incompatible; while you can translate ReST to HTML, HTML to ReST would at best be unreliable and confusing. This means HTML pages can only be edited as HTML ever. Then again, I'm interested in seeing how the idea would work. Whether that should be driving a Zope 3 site as a whole is another question. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Why I posted about Zope3.org (the outsider's thoughts that got me thinking)
stream, but more dedicated so it's known that relevant information shows up). I think that Zope 3 has its own momentum away from Zope 2. Five is what is going to be appealing to Zope 2 developers learning about Zope 3. There should be something that appeals to the general Python crowd that I still believe to be the main target for Zope 3 as it stands right now - a shorter path between your Python objects and publishing them on the web. Or a shorter path between writing some plain old Python code and seeing a result. I need to read more of the other thread about this. I just know that there's some debate of whether Zope 3 should be a part of the Zope.org site. I'm for having it be separate. There are a lot of Python developers out there who have bad memories of Zope 2 but just may be the kind of developers who'd like or love Zope 3 if they could really see and understand what makes Zope 3 so great. -- Jeff Shell http://griddlenoise.blogspot.com/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Why I posted about Zope3.org (the outsider's thoughts that got me thinking)
On 10/11/05, Stephan Richter [EMAIL PROTECTED] wrote: On Tuesday 11 October 2005 13:24, Jeff Shell wrote: I'd really like to give Zope 3 a try, and I keep trying to. The docs are just nauseating. They might look good or fine to someone who's used Zope for years, but to someone new they're horrid. As I mentioned, the site is laid out horribly for someone who wants to learn Zope 3. Why is the left bar saturated with links when I just want Zope 3? It's incredibly frustrating and disappointing to hear about all the cool stuff you can do in Zope 3, and not see anywhere that shows it actually being done with descriptions on how it works, etc. Where are the examples? Where are the recipies to do cool thing X? The developers I see talk about Zope are all in companies that use it, that have teams that use it, that have tons of actual knowledge that doesn't exist on the website. I really really want to give Zope 3 a spin, I have a few fairly complex projects I'd like to try out with it. How do I get started? I would say, buy the books. It is too hard to keep documentation up to date, if you do not get paid. The alternative are doctests of course, which we have available as mentioned in my previous mail. Again, I think it is a lack of manpower, my own included. I would love to update the Web site to the version of my book that has actually been printed, but I just do not have time. All it needs is someone to merge the stupid DOC files to the TeX master documents and it would be online. Note that I already put them in a zope.org-based repo, so anyone can work on that task. That was my response to him. But for people evaluating Zope 3, or just starting out and not knowing whether it's a worthwhile technology to continue with, buying a book is probably a non-starter. Some good quick starts and recipes would help there. I don't think that the type of documentation that is in a book should be on the web site and maintained constantly. It's too big and too hard, a fact I'm sure you're aware of. The API Doc tool, the books, are all useful things to have once you've really committed to a project. But getting people that far is where zope3.org or maybe zope3rocks.com or something - anything! - would be useful. Instead of trying to update reams of documentation with new features in Zope 3.2, one could post a document like Zope 3.2 - Introducing zope.formlib or Zope 3.2 - deprecated functions Because, for example, I see the warning about using 'getView - use getMultiAdapter instead', but there's no explanation of how a getView(...) call should be translated into a getMultiAdapter call.. One can figure it out, but it's a couple of lines that could be in a document that many of us here can write.. I just don't want it lost in the desert sands of the wiki. I can find proposals about simplifying the component architecture, but there's no final document about what that simplification really produced and how it affects me. The deprecation machinery is great at telling me about these things (again - I think it's a great feature), but oh man - I think any major architecture like Zope 3 that gets *simpler* in a new version is something to sing about. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Why I posted about Zope3.org (the outsider's thoughts that got me thinking)
On 10/11/05, Stephan Richter [EMAIL PROTECTED] wrote: On Tuesday 11 October 2005 13:24, Jeff Shell wrote: Personally, I really like the Z3ECM project site - z3lab.org. It has a combination of blogs, papers, demos (animations) and documentation. That's still a project in its infancy, but it's a good looking site with a variety of sources feeding into it. If there were to be a model for a Zope 3 web site, that would be it. I have followed the mailing list the last months and the site a little bit, and I still do not know what the project is really working on at the moment. I know that Roger helped developing a high-level workflow engine atop WfMC and Jean-MARC works on CPS skins (why CPS skins, if there is no CPS for Zope 3), but that's pretty much it. Specifics about the Z3ECM project aside, it's just a nice site in my opinion. The front page layout - 'Latest News' and 'Spotlight Information' on top, the list of documentation updates, blog posts, documents and white papers on the side, the explanatory text further down - it's great. It's not super flashy, but it gets information across and has the feel of freshest information on top and avoids the feel of lots and lots of new and old information all over the place that Zope.org has (which stems from Zope.org's noble efforts as a community site which has built up a lot of data over the years, which is why I think a good Zope 3 marketing / information site should be more 'invite-only' in regards to publishing information, at least initially). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] fssync and export/import for Zope 3
YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES OH GOD YES! I mean. Yes! Backup/restore, and deploy. We're deploying a customers site in chunks - one section, then another, then a third. It's content that's being migrated off of Zope 2. The other developer here was complaining about having to do the third chunk on the live server. All of these chunks are well sectioned off, and import/export would be wonderful. fssync isn't in the release (we try to only use release code around here - easier to manage), and we didn't know what it meant that the code looks like it hasn't been touched in over a year - is it simple and stable enough to work with production Zope 3.1, or has it fallen behind? We didn't know this, but were thinking that now that things have settled down (somewhat), it might be nice to investigate. So - yes! This exactly mirrors a conversation we had just a couple of minutes ago. On 10/7/05, Garrett Smith [EMAIL PROTECTED] wrote: Is anyone interested in using export/import capabilities in Zope 3? As we get more Zope 3 deployments, I think this will become an important topic. It looks like the fssync code has become only slightly stale. With a little use, this could be break-out feature for Zope 3 developers. As Jim just pointed out, there are a couple a 'visions' associated with fssync: - The export/import functionality people are used to with Zope 2 - A checkin/checkout functionality that would let someone make long-running changes to a part of a site, with the option of commiting or aborting those changes I suspect the export/import feature alone will be attractive to anyone with production servers, as it enables object-specific backup and restore. If anyone is interested in using this, let me know. I'll be looking into adding a simple command-line tool for object-specific backup/restore (i.e. export/import) and it would be helpful to have some other users, if not contributors. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] KeywordIndex
I'm working on a simple application which is the first time I get to use the catalog in Zope 3. I'm writing against Zope 3.1b1. I was dismayed not to see KeywordIndex in the main catalog set, but then I found it in zope.index.keyword. But it seems to be a bit behind. I have it somewhat working through subclassing, etc, but it's been purely guess work on my part to get things this far. In my product package, I have the following: -- from zope.app.catalog.interfaces import IAttributeIndex, ICatalogIndex from zope.app.catalog.attribute import AttributeIndex from zope.app.container.contained import Contained from zope.index.keyword.index import KeywordIndex as KeywordIndexBase from zope.proxy import removeAllProxies from BTrees.IFBTree import IFTreeSet, IFSet, multiunion class IKeywordIndex(IAttributeIndex, ICatalogIndex): Interface-based catalog keyword index. class KeywordIndex(AttributeIndex, KeywordIndexBase, Contained): implements(IKeywordIndex) def index_doc(self, docid, value): # All security proxies need to be removed from the value. value = removeAllProxies(value) return super(KeywordIndex, self).index_doc(docid, value) def apply(self, query): # Keyword index doesn't implement apply(query) either. return self.search(removeAllProxies(query)) def _insert_forward(self, docid, words): insert a sequence of words into the forward index # Replaces parent _insert_forward because apply() claims to want IFSets idx = self._fwd_index has_key = idx.has_key for word in words: if not has_key(word): idx[word] = IFSet() idx[word].insert(docid) -- I first overrode index_doc because the base KeywordIndex does an isinstance(value, (ListType, TupleType)), which failed on a security proxy guarded value. Then I added 'apply()' when I noticed that the base KeywordIndex didn't implement apply. Looking at the other supported indexes and at the index interfaces in zope.index, I noticed that IFSets were what was desired as the output of apply(), and that's when I replaced _insert_forward with a near identical copy that uses IFSet. This works... so long as I only search for one keyword. If I search for more than one through the catalog interface (and I imagine I would get the same result manually), I get the following traceback: -- File /Users/jshell/Documents/Programming/kbase/lib/python/br/kbase/browser/search.py, line 22, in search results = catalog.searchResults(tags=query) File /Library/ZopeX3/3.1/lib/python/zope/app/catalog/catalog.py, line 105, in searchResults results = self.apply(searchterms) File /Library/ZopeX3/3.1/lib/python/zope/app/catalog/catalog.py, line 84, in apply r = index.apply(index_query) File /Users/jshell/Documents/Programming/kbase/lib/python/br/kbase/catalog.py, line 36, in apply return self.search(removeAllProxies(query)) File /Library/ZopeX3/3.1/lib/python/zope/index/keyword/index.py, line 139, in search rs = f(rs, docids) TypeError: invalid argument -- 'f' is IISet.intersection() The implementation of search() in the base KeywordIndex uses IISets for default values. I don't know if this is conflicting with the IFSets I set up in my subclass. I tried quickly editing zope.index.keyword.index to use IFSets instead, but I got the same traceback and then quickly reverted back to leaving the code untouched. It's been *years* since I've even touched simple indexing code, so I don't really know what's going on here or what's required. I would really like to have Keyword Index. In fact, such an index is the core of my application. I can throw together my own, I'm sure, that's a bit more brute force for my own purposes if necessary. I don't claim to have a solid understanding of how indexes and the catalog work (although it's been much easier to figure out in Zope 3, thanks!) Is there any reason why KeywordIndex seems half-abandoned? I guess it's not exposed to zope.app because of this. What would it take to make it catch up to FieldIndex? Thanks -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] KeywordIndex
Hi Gary! I'd be very interested in this. It's not critical for me right now, so there's no need to rush making something available. I have an inefficient but fun solution for my system that can be replaced when this comes along. I primarily wanted to know the state of the indexes. Is what's there right now going to be what ships with Zope 3.1 final? On 7/18/05, Gary Poster [EMAIL PROTECTED] wrote: On Jul 18, 2005, at 11:14 AM, Jeff Shell wrote: I'm working on a simple application which is the first time I get to use the catalog in Zope 3. I'm writing against Zope 3.1b1. I was dismayed not to see KeywordIndex in the main catalog set, but then I found it in zope.index.keyword. But it seems to be a bit behind. Hi. Yes, we needed it too. Here's another thing we want to open source. Look at the attached .txt file; if you want it then tell me and I'll make it available in a sandbox. We'll move it over into the Zope repo (probably with a new name, or rearranged on the appropriate locations (zope.index and zope.app.catalog, etc.) RSN. Downsides: - Note that some functionality requires that you use an extent catalog, another goodie in the package. - We have some refactoring of this that we want to do. We'll have legacy issues ourselves, then. Additional upside: - This package also includes a replacement for the field index (called a value index) and customizations of the value and set indexes specific to timezone-aware datetimes, as well as a few other things. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
