Re: [Zope3-Users] Eclipse + PyDev + deferred imports

[Martin Aspeli]

andrew wrote:
> Thanks for that, Dan, and also to Sailesh for the suggested workaround.
> I'll look into upgrading the relevant zope packages as the best answer.

That's not a good idea. If you upgrade packages willy-nilly, you'll get 
version conflicts. Stick to the tested known-good sets unless you really 
know what you're doing (or you're trying to help us test + develop new 
known-good sets).

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] Eclipse + PyDev + deferred imports

[Martin Aspeli]

Shailesh Kumar wrote:
> I generally make it /from zope.component._api import getUtility/ to make 
> PyDev happy. It doesn't hurt the code and I don't have to see the 
> 'unresolved import message'.

You shouldn't do this. You shouldn't import from a module starting with 
an underscore. It's the developers' way of telling you to treat it as 
internal. 'from zope.component import getUtility' is almost certain to 
work "forever". The _api module could disappear in a refactoring tomorrow.

The only way to fix this is to make PyDev aware of zope.deferredimport. 
You could ask. :)

Martin


-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] z3c.form: LookupErrors

[Martin Aspeli]

Stephan Richter wrote:
> On Wednesday 08 April 2009, Martin Aspeli wrote:
>> What I'd like to see:
>>
>>   1) z3c.form catches the LookupError and treats it as a valdiation
>> error (even on first render of the form), not a fatal error
>>
>>   2) z3c.form defaults to missing_value if there is a LookupError
>> against what the data manager returns. The value is indeed "missing in
>> action"
>>
>>   3) If possible, we output the offending value in the error message
>>
>>   4) In use cases where it makes sense, people can use a field property
>> implementation that checks the source and returns the default (or
>> something else) if the value can't be found. That's not for z3c.form
>> to decide or depend on though.
> 
> Sounds good.

Would you mind making a 1.9 maintenance branch and, if we fix a few 
bugs, could you release 1.9.1 soonishly.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] z3c.form: LookupErrors

[Martin Aspeli]

Hi Roger,

 > I agree that this should not end in an error blocking the UI.

Good. :)

 > Let's say you have a Choice with possible values defined in
 > a source, vocabulary or a simple list like:
 >
 > ['please select', 'Max', 'Peter', 'Fred', 'Admin']
 >
 > And we have a field which looks like:
 >
 > ownership = zope.schem.Choice)
 >title=u'Ownership',
 >values=['please select', 'Max', 'Peter', 'Fred', 'Admin'],
 >missing_value='please select',
 >required=True,
 >default='Admin')
 >
 > Now an object get added and the ownership value
 > get set to 'Peter'.
 >
 > After that 'Peter' get removed from the system.
 > Now it's a question how the system is built.
 > In some case an event get fired (user removed)
 > and you can deny removing the user because
 > one or more objects still need the user.

In a relational database, this is a lot easier. I think for most
content scenarios using the ZODB, it'll be tricky to maintain these
links except on a case-by-case basis. In that case, of course, this is
all a non-issue.

 > I agree that this is not allways usefull because
 > of performance reason. If so we have to live with
 > legacy data.
 >
 > - What does this mean to the form or the widget?
 >
 > - What should the widget show for the above use case?

On a display form/view it should probably show the stored value, maybe
with a warning.

On an edit form, it should show the field with a validation error
message and the missing_value selected. If the field is required, the
user will be forced to choose a new value. If not, at least they
will've been warned.

 > - What does the object return till someone will
 > adjust the ownership (widget) value.

By default, the old value. That's what's stored. You can't always
check against the source unless you use field properties and are
willing to take that hit.

It's also probably going to be useful to know what the erring value
was, so it needs to retain that for the validation error.

 > - And much more important, depending on the form,
 > does the user know that he has to adjust the
 > ownership value or does the widget, based on the
 > legacy value handling, show something that the
 > user think it is ok and he doesn't adjust the
 > ownership value at all?
 >
 > I think this use case can only get fixed if the
 > underlaying field, e.g. FieldProperty which manages
 > the ownership value will be consistent within the
 > widget.
 >
 > Which means the FieldProperty should only use
 > and return known values defined in the field.

Maybe. I'm not sure that's going to fit all use cases.

For example, let's say you're asked to pick a person as the "original
creator" of a document. To make it easy, we may use a form with an
auto-complete widget against a user source. If that source no longer
has the value, the historical information about which user was chosen
is still important.

Archetypess has the notion of en enforceVocabulary property that can
be set to False to allow values outside the vocabualry. This becomes a
schema decision, effectively.

 > In the usecase above, the field should only return
 > 'Admin' or 'please select' but not 'Peter' which got removed.
 > Hm, I'm not even sure if missing_value or the default value
 > should get used.

Probably missing_value if you want the user to re-select.

 > Since the missing_value is only a indicator that no value
 > is given, this means if a field defines required=True, then
 > the object isn't valid if you whould validate within the
 > object schema.

Yep, you'd effectively force the user to re-select.

 > Probably the 'default' value is the right value to use
 > for removed values in some use case, in other usecase
 > probably not. (not sure about that)

Yeah, it's tricky.

This is also why z3c.form (and other libraries) need to have some
leniency built in for cases where data integrity isn't 100%. Warnings
are good. Errors are bad.

 > Probably this is just to much and we should just adjust
 > the widget and use other field/widgets implementations
 > which handle this use cases in different ways.

Probably. You can then make a policy decision when you define the schema.

 > My recomendation for solve this problem:
 > A Choice field should never return something else then
 > defined in it's source.
 >
 > Any reason why this whould be a bad idea?

Yes - see above for the case of historical data, for example.

What I'd like to see:

  1) z3c.form catches the LookupError and treats it as a valdiation
error (even on first render of the form), not a fatal error

  2) z3c.form defaults to missing_value if there is a LookupError
against what the data manager returns. The value is indeed "missing in
action"

  3) If possible, we output the offending value in the error message

  4) In use cases where it makes sense, people can use a field property
implementation that checks the source and returns the default (or
something else) if the value can't be found. That's not for z3c.form
to decide or depend on though.

Re: [Zope3-Users] z3c.form: LookupErrors

[Martin Aspeli]

Hi Roger,

>> What if your list of choices depends on constantly changing 
>> data? For example, a widget allows you to select a user from 
>> a userfolder. Later the user gets deleted. 
> 
> pang, legacy data created

In the real world, this type of of thing happens all the time. It's 
incredibly unhelpful to say that this results in a user-alienating 
traceback and no means of fixing the data through the web.

Are you proposing that every time a user is deleted, we run a script 
over all content in the site that needs to know all the objects that may 
use a user source for a choice field, and modifies it? That's not just 
prohibitively expensive, it's open to an incredible number of 
permutations of things that may or may not need to be migrated in an 
open-ended system such as Plone.

>> I totally agree with Martin that we should use missing_value 
>> in those cases.
> 
> Defently not. Such forms will show you a default value and you
> think this is Ok. But the object devliers still the old
> stored value. Pang, pang and you will be surprised till you 
> will start debugging and see the real value decorated within the
> missing_value. That's a horrible scenario!

It'd be nice to show what's happened, e.g. with a validation error on 
the form. A traceback is definitely not the right thing.

>> I think this could actually be considered a fairly serious bug.
> 
> No, defently not, the Choice field defines what are valid values
> and the widget only handels that. There is no reason why a widget
> should do more then that.
> 
> If you remove valid values for a field, you also have to make
> sure that the system doesn't use them. Doesn't matter if a 
> system can work with different/legacy data or not.
> 
> I think you are right that a valid missing_value should get
> used, but that must be implemented at the field level. The 
> field has to return that missing_value. This will make sure
> that objects value returns the same as the widget does.
> 
> But that's a kind of auto-mirgation for legacy data.
> And I'm not sure if this is a good idea.

Let me put it this way: If we are to use z3c.form in Plone, the current 
behaviour or any solution that depends on site-wide migration of data in 
this kind of scenario is a showstopper. We'd need to customise pretty 
deep parts of z3c.form in the best case or ditch it in the worst case.

But it sounds like Stephan agrees. :)

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] z3c.form: LookupErrors

[Martin Aspeli]

Hi,

In z3c.form (at least with 1.9.0), if you have a Choice field and the 
vocabulary changes so that an existing value (or the default value on an 
add form) is no longer valid, you get a LookupError:

   Module z3c.form.form, line 126, in updateWidgets
   Module z3c.form.field, line 259, in update
   Module z3c.form.browser.select, line 51, in update
   Module z3c.form.browser.widget, line 61, in update
   Module z3c.form.widget, line 182, in update
   Module z3c.form.widget, line 120, in update
   Module z3c.form.converter, line 258, in toWidgetValue
   Module z3c.form.term, line 31, in getTerm
   Module zope.schema.vocabulary, line 124, in getTerm

It'd be nicer if z3c.form would catch the error and return 
field.missing_value or something like that. As it stands, if this 
happens with a content object, it's impossible to reach the edit form 
and fix the value!

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] Unknown directive: class !!!

[Martin Aspeli]

Andreas Jung wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Never heard or seen a zcml 'class' tag. Do you mean 'content'?

AFAIK,  is deprecated in favour of . We use it in 
Plone for example (from plone.app.contentrules):

  
 
 

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Sources, vocabularies, context source binders and vocabulary factories

[Martin Aspeli]

Hi,

In zope.schema, IBaseVocabulary extends ISource, so a vocabulary is a 
specialisation of a source. However, we have both an 
IContextSourceBinder and an IVocabularyFactory, both of which have a 
single method __call__(context) to return a source or vocabulary 
respectively. However, IVocabularyFactory does not extend 
IContextSourceBinder.

Is there some logic to this? Are they meant to be separate? I've seen 
naemd vocabularies registered with IVocabularyFactory. Is there some 
reason why you couldn't have named vocabulary factories creating simple 
sources instead of vocabularies?

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] z3c.form image upload widget

[Martin Aspeli]

Roger Ineichen wrote:

> I think everything should be there for a simple file upload.
> The z3c.form doesn't have enhanced upload features.
> 
> One way to implement an object replacement whould be to
> ad an addditional field (bool) in the object schema
> and depneding on that input replace the file in the
> EditForm.applyChanges method.
> 
> If this replace-me field is a part of the archetype file,
> then a new widget whould be the right thing.
> 
> btw, the default z3c.form widget returns the bytes data
> as widget value in applyChanges based on the converters
> convertion. Probably an archtype file widget should return
> an archetype? But this depends on the type of schema field
> which is used.

I'm not actually using Archetypes, I just want something with equivalent 
functionality.

At the end of the day, I want to store a blob and be able to download it 
again.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] z3c.form image upload widget

[Martin Aspeli]

Hi,

I'm in need of a z3c.form form that supports image uploads. Ideally, it 
should support optional and mandatory fields, and in 'edit' mode it 
should allow the user to either keep the current image or replace it 
with a new one (Plone/Archetypes has a radio button + a file upload 
widget to achieve this). It'd be nice to also show an icon of filetype 
or small thumbnail of the image next to the widget. Finally, it needs to 
retain the filename that is sent in the request and store this somewhere.

Does anything like this exist? We have collective.namedfile for Zope 2 
and formlib, and we could probably borrow some things from that, but 
it'd be nice if there was something already. Note that for z3c.form on 
Zope 2, with the plone.z3cform library, you get a "wrapper" around the 
form that makes it behave very much like it does in Zope 3. We may need 
a custom data manager for the image, and maybe a custom image IField 
type, but it should be easy enough to re-use most of the stuff across 
Zope 2 and Zope 3.

Cheers,
Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] __safe_for_unpickling__

[Martin Aspeli]

Hi,

What does __safe_for_unpickling__ do? I can't seem to find any 
conclusive documentation, though I see it in various parts of the Zope 
sources (e.g. the LocationProxy).

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] [RFC] Merging zope3-users list with zope-cwuwpebw...@public.gmane.org list

[Martin Aspeli]

Andreas Jung wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hereby I propose to abandon the zope3-user list  and merge it with the
> z...@zope.org mailing list.
> 
> Why?
> 
>  - getting rid of the artificial distinction between Zope 2 and Zope 3
> 
>  - phasing out the term "zope 3" in order avoid confusion
> 
>  - keeping user questions on one list since there is often an overlap
>between Zope 2 and the Zope component library (aka Z3)
> 
>  - one "user" list is enough (as we already have merged the
>zope3-dev list into the zope-dev list)
> 
> Thoughts?

+1

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Letting a custom factory instance act like a class with implements()

[Martin Aspeli]

Hi,

I have the following three classes. DelegatingIndexer is a kind of 
generic implementation of the IIndexer interface (not shown, it 
basically just has a __call__ method) that delegates to a given callable 
after doing some prep work. DelegatingIndexerFactory is an adapter 
factory for the delegating indexer. indexer is a decorator that uses 
these two to allow you to do the following:

  >>> @indexer(IMyType)
  ... def foo(object, **kw):
  ... return "some value"

class DelegatingIndexer(object):
 implements(IIndexer)

 def __init__(self, context, callable):
 self.context = context
 self.callable = callable

 def __call__(self, portal, **kwargs):
 kwargs = kwargs.copy()
 kwargs.setdefault('portal', portal)
 return self.callable(self.context, **kwargs)

class DelegatingIndexerFactory(object):

 def __init__(self, callable):
 self.callable = callable
 self.__implemented__ = Implements(IIndexer)

 def __call__(self, object):
 return DelegatingIndexer(object, self.callable)

class indexer(zope.component.adapter):

 def __init__(self, *interfaces):
 adapter.__init__(self, *interfaces)

 def __call__(self, callable):
 factory =  DelegatingIndexerFactory(callable)
 return adapter.__call__(self, factory)

This works, but I don't understand why I need to set 
self.__implemented__ explicitly as an instance variable on the 
DelegatingIndexerFactory. Without this, I can't just do 
provideAdapter(foo), because it says that the factory (an instance of 
type DelegatingIndexerFactory) doesn't implement a single interface (in 
fact, implementedBy() returns an empty generator).

I've tried various directives in zope.interface, but I can't find a 
nicer way than just setting __implemented__ as above. Am I missing 
something?

Cheers,
Martin


-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] thoughts about z3c.form-package

[Martin Aspeli]

garz wrote:
> hey,
> 
> while using z3c.form-package i reach its limits here and there. thats why i
> started to think about how a more general implemention should look like. 

A *more* general z3c.form sounds like a frightening prospect. :-)

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] formlib to z3c.form widget adapter/bridge

[Martin Aspeli]

Stephan Richter wrote:
> On Thursday 28 August 2008, Martin Aspeli wrote:
>> Has anyone written or thought about an adapter/bridge between formlib
>> and z3c.form widgets?
> 
> Not that I know of. But I think it might be hard to do due to the different 
> definitions of what a widget and a field is. On the other hand, I might be 
> wrong. If someone develops such a bridge, I would add it to z3c.form as an 
> optional feature.

I've only briefly looked at it, but I think it may be possible. Can you 
be a more specific about how you think their definitions matter?

My idea was to write a widget factory that attempts to adapt a 
zope.app.form widget to a z3c.form.interfaces.IWidget or one of its 
specialisations. If the widget had enough information to render itself, 
then so long as it got the right request through, I would hope that it'd 
return a value.

We may not get all the bells and whistles here - things like value 
adapters and custom data converters may be out. For most widgets, that 
may not be necessary, though.

> BTW, it would be a bridge from zope.app.form widgets to z3c.form ones. 
> zope.formlib does not define its own widgets.

Right, sorry.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] formlib to z3c.form widget adapter/bridge

[Martin Aspeli]

Hi,

Has anyone written or thought about an adapter/bridge between formlib 
and z3c.form widgets?

We have a few widgets that have no z3c.form equivalent, e.g. the formlib 
captcha widget. Whilst porting a widget isn't terribly hard, it would be 
really useful to have some kind of generic bridge that made it possible 
to use formlib widgets in z3c.form forms.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Searchable sources and z3c.form

[Martin Aspeli]

Hi,

What is the canonical way to do search-based sources/vocabularies? In 
particular, I want to use them with z3c.form.

In zope.schema, I see mention of an ISourceQueriables. I also see these 
in zope.app.form, but not in z3c.form. I'm also not quite sure I 
understand how these work.

In z3c.formwidget.query, we've got a specialisation of 
IVocabularyTokenized that adds a search() method. This is certainly 
useful, if a bit non-standard. :-/

Furthermore, from what I can tell from the interfaces in zope.schema, 
it's not possible to have a source that can be tokenised, but cannot be 
iterated over. I may've misunderstood tokens, but my understanding was 
that in order to safely pass strings back and forth to the browser 
whilst still supporting values of arbitrary types, we need tokens. A 
search-based source will almost certainly not be iterable, though.

Cheers,
Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] Dynamically generate interfaces, content object and z3c.forms?

[Martin Aspeli]

Hi Harald,

> I need some advise how to use dynamically generated interfaces, content 
> and forms:

I'm working on a package called Dexterity for CMF/Plone that can work 
with content types created through-the-web (among other things). For TTW 
content to have a unique interface, you need a dynamic one.

See http://martinaspeli.net/articles/dexterity for some more 
information. This is slightly out of date, but not too much.

If you just want an interface at runtime, with no persistence to the 
ZODB, then it's pretty easy. You can generate an interface (it helped me 
a lot to understand that an interface, whilst defined with the 'class' 
keyword, is really just an object of type InterfaceClass) and use it 
however you want. It gets a bit more tricky if you want to have content 
objects that are both persistent to the ZODB and provide the interface 
you generate forevermore. However, it's not too difficult.

> 1. step:
> generate interfaces from xsd
> I've used zope.interface.interface.InterfaceClass to achieve this

You may be interested to look at 
http://svn.plone.org/svn/plone/plone.supermodel which does the same 
thing from an XML representation of zope.schema fields.

plone.supermodel will work in "plone Zope 3", so you should be able to 
re-use it. I'd be really interested to see your XSD parsing code, by the 
way! We thought about using XSD for Dexterity, although I find XSD 
syntax a bit verbose.

Is it feasible to actually write the interface in Python?

plone.supermodel has a grokker (you don't need all of Grok, just the 
re-usable grok.component) that lets you write something like this:

 >>> class IMyType(plone.supermodel.Schema):
... plone.supermodel.model('mytype.xml')

plone.supermodel.Schema is just a marker interface.

At ZCML processing time, this will read 'mytype.xml' and scribble 
zope.schema type fields onto IMyType. This interface is then every bit 
as real as any other interface you have, and is quite easy to work with. 
For inspiration:

http://dev.plone.org/collective/browser/example.dexterity/trunk/example/dexterity/page.py
 


If it's not feasible to write a per-file schema interface like this, 
then you need to generate it all on the fly. That's easy too - you just 
construct an InterfaceClass object at runtime and return it 
(plone.supermodel has methods that do this, for example). The challenge, 
as you've seen, is what you do with that once you have it ...

> 2. step:
> generate content object implementing the generated interface from step 1
> zope.interface.directlyProvides or classImplements?
> FieldProperty?

If you really want to make sure that 
ISomeGeneratedSchema.providedBy(some_content) is True, then here's how 
Dexterity does it:

http://dev.plone.org/plone/browser/plone.dexterity/trunk/plone/dexterity/factory.py

This is a custom IFactory utility (we register local utilities for each 
TTW-defined content type). Your code doesn't need to be in such a 
utility, of course. The relevant bits are:

  1. Find a class to use. We store this in a string property that's TTW 
editable and resolve it.
  2. Create an instance of the class.
  3. Look up the (dynamic) schema marker interface.
  4. Check if the instance already provides the interface.
  5. If not, do an alsoProvide() to mark the instance.

At this point, if you have a generic class, you've probably just told a 
lie. Your generic class won't have the fields that the interface 
promises. You can either go through and set properties on the instance, 
or use a __getattr__() that can return field defaults. We opted for the 
latter, since it makes it easier to deal with interfaces that change 
over time. This is done here:

http://dev.plone.org/plone/browser/plone.dexterity/trunk/plone/dexterity/content.py

Here, we look up the type's schema again. Note that we need some kind of 
registry to know which schema the instance is supposed to have. 
Dexterity has all that in a utility, but you could just as easily have 
done something like queryType(self).

We *did* look at other ways, such as generating a class for each 
interface, or doing a dynamic __provides__ property. However, that got 
very complicated, or slow, or both. The pattern above is pretty 
straightforward.

However... :)

I assume you want to persist things in the ZODB as well? That gets a 
little tricky, because if you use alsoProvides() to set it on an 
instance, you need to ensure the interface has a real, stable module 
path so that the ZODB can load it again.

The way we've solved it in Dexterity is this:

  - We use a small package called plone.alterego 
(http://svn.plone.org/svn/plone/plone.alterego/trunk/) that has some 
hooks to let you create a dynamic module. You can re-use this in plain 
Zope 3.

  - The dynamic module has a __getattr__ hook which delegates to a 
utility that you write. Your utility creates and returns the module's 
object for that name.

  - You need to be careful that your utility always returns the exact 
same object, with

[Zope3-Users] Checking for existence of an adapter

[Martin Aspeli]

Hi,

Is there some way to check whether an adapter exists without having 
something to adapt?


Specifically, I want to know if a particular view is registered for a 
particular type of context and request/layer, with a particular name. 
However, I don't have an instance of the object of that type, nor the 
request, at the time when I need to do the check.


I tried this, but it doesn't seem to work, at least not for globally 
registered views:


site_manager = getSiteManager(site)
addview_factory = site_manager.adapters.lookup((Implements(IAdding), 
Implements(IBrowserRequest)), IBrowserView, name=fti.factory)


Cheers,
Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] z3c.form - content add and edit forms

[Martin Aspeli]

Hi,

It's very common to have a content type that has both an add- and an
edit form. If you have custom widget setup code and other logic, you
often have to replicate this across both forms to make them consistent.

Is there a standard/recommended z3c.form pattern to reduce duplication
in this case?

Martin


--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: A slew of z3c.form questions

[Martin Aspeli]

Stephan Richter wrote:

On Sunday 06 July 2008, Martin Aspeli wrote:

I'm guessing z3c.form groups do that, of course, but it's not clear to
me whether it's appropriate to use them for this kind of thing,
especially since the logical groupings and field ordering will only be
calculable at runtime.


Groups were written to support your use case specifically. I think they even 
put fieldset tags around each group, but I would have to check the template.


Heh, indeed. Though now that I see it, I notice that it's using the 
non-existent  tag, rather than . I realise it's 
mostly used in the test, but you may want to fix that. :-)


One other question: I want the Group's to be instantiated and populated 
at run time. That is, I don't want a class for each one, but rather I 
want to be able to distribute fields across groups via various adapters 
looked up by the form.


Is this sensible? Should I instantiate Group objects directly and set 
their fields etc? Or should I do something else?


Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] z3c.form version of a 'lines' widget

[Martin Aspeli]

Hi,

Is there a z3c.form input widget that can work on zope.schema.Set with a 
value_type of zope.schema.TextLine. That is, a widget that lets the user 
build a list of values (e.g. one per line)?


I see the selection widget, but that assumes that there's a vocabulary.

Cheers,
Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: A slew of z3c.form questions

[Martin Aspeli]

Hi Paul,

Thanks a lot for this!


You can override the updateActions method and modify the css after the
buttons are created.  As you may have read, buttons are like schema
fields, and actions are like the widgets for a schema field.  So to
modify the appearance of a button, you have to actually modify the
action:

@button.buttonAndHander("My Button", name="myButton")
def handleMyButton(self, action):
print "handling my button"

def updateActions(self):
super(MyForm, self).updateActions()
self.actions["myButton"].addClass("my-custom-css-class")


Nice one! That works.


 - Some fields on the form are provided by the content item. Others can come
from other schemata. There will be adapters from the context to these
interfaces. How do it up so that z3c.form uses the appropriate adapter to
read and write values, including in the add form?


In the add form, it is up to you to handle the data input, by
implementing the create and add methods.


Ah right. I guess I should be able to do that. I had guessed that 
form.applyChanges() could do something implicit, but I guess that's a 
bit too much to ask.



As for the edit forms, I'm
not entirely sure about this but I believe the form framework will
just do the right thing.  i.e. you might say:

fields = field.Fields(IMyInterface)
fields += field.Fields(IMyOtherInterface)


Okay, I'll try that. I actually don't know which interfaces will be used 
until runtime (i.e. the form looks those up dynamically), but I'm 
guessing I can build that dynamically anyway.



And it will automatically try to adapt the context to the interface
from which the field was defined.  An alternative way which will
definitely work (even if you don't have adapters) is to use groups:

class MyOtherInterfaceGroup(group.Group):
fields = field.Fields(IMyOtherInterface)
def getContent(self):
# do whatever you have to do to get something implementing
IMyOtherInterface, adaptation or otherwise
return myInterfaceToOtherInterfaceAdapter(self.context) #even
a direct call to a specific adapter

class MyForm(group.GroupForm):
fields = field.Fields(IMyOtherInterface)
groups = (MyOtherInterfaceGroup,)

This is essentially the poor man's version of having a subform.  It's
also a great way to fake "object widgets" when one of the fields of
IMyInterface is of type zope.schema.Object.


Interesting... can you elaborate on that (I may need it for something else)?


 - I'd like to group widgets together into fieldsets. A fieldset may contain
widgets from multiple interfaces. All fieldsets will be on the same form, in
different  tags. Should I look to use groups for this? Subforms?
Or something else?


I'd recommend just writing your own template.  I've found that the
templates in z3c.formui can only take you so far, and are best used as
prototyping tools and reference documents.  Of course, you can always
reuse many of the macros, especially when it comes to displaying
widget error messages.


Yeah, I'm happy enough to do that. Right now, I'm using a Ploneish 
template from plone.z3cform, and I may yet try to generalise this and 
extend that instead of my own code, but I'd expected to hack some TAL.


However, I'd like to know if z3c.form has some support for grouping 
fields from across multiple adapters/schemata interfaces and marking 
them up so that I could render the fields in the right order, in the 
right logical groupings.


I'm guessing z3c.form groups do that, of course, but it's not clear to 
me whether it's appropriate to use them for this kind of thing, 
especially since the logical groupings and field ordering will only be 
calculable at runtime.


Cheers,
Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] A slew of z3c.form questions

[Martin Aspeli]

Hi,

I'm using z3c.form in Plone via plone.z3cform. The z3c.form 
documentation is very good and very detailed, but I must admit to 
getting a bit lost in all of it. :)


To that end, I have a few questions. I'm creating a pair of add- and 
edit forms for a content item:


 - I've created a few buttons with @button.buttonAndHandler(). However, 
I need to set a different CSS class for each button. What's the easiest 
way to do that?


 - Some fields on the form are provided by the content item. Others can 
come from other schemata. There will be adapters from the context to 
these interfaces. How do it up so that z3c.form uses the appropriate 
adapter to read and write values, including in the add form?


 - I'd like to group widgets together into fieldsets. A fieldset may 
contain widgets from multiple interfaces. All fieldsets will be on the 
same form, in different  tags. Should I look to use groups 
for this? Subforms? Or something else?


That's it for now.

Cheers,
Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: XML schema definitions,zope.schema and z3c.form

[Martin Aspeli]

Christian Klinger wrote:

Hi Nylan,

we are working during the grokkerdam sprint on the same topic.


Interesting! Can you give us some more information?

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: [Zope-dev] Zope 3.4.0 candidate 1 Released

[Martin Aspeli]

Hermann Himmelbauer wrote:

Am Donnerstag, 27. März 2008 18:26 schrieb Kurt Zitze:

if you want to raise the userbase of zope, the first and most obvious thing
to do is, get a forum running! mailing lists are bu*** and completly
out of date. it is max cumbersome to login into your email account to do a
post and so on, i think i dont need to enumerate all the disadvantages of a
mailing list compared to a forum. i am even not aware of how to replay to a


Well, all I can say to this is: Please do not split up the userbase by opening 
some extra web forum. I personally dislike forums, they are often cumbersome 
to use, therefore I prefer mailing lists a lot.


I think the chances of this happening are virtually zero. :)

Although I don't like forums that much, it is true that newbies and specific 
users tend to use them. To satisfy both sides, I can think of a forum that 
has a gateway to this mailing list. If I remember it right, Plone has such a 
thing (perhaps it could be used somehow?). This forum would then also serve 
as a pretty looking archive, which is also a good thing.


So does Zope. See nabble.com and news.gmane.org.


and if you finaly have one, put it on the start site, not like this mailing
list that is so to say hidden!


It's true, that Zope3 and Zope3 support ist somehow hidden in the Zope 
website. But AFAIK a new Zope website is currently under development, which 
will probably solve all these issues.


Indeed. We should see some movement on this over the weekend.


everything in zope is not obvious, at least not to me. everything has to be
found out in hours of studying the sources! reading the books, using google
to find sources that arent linked nowhere. i stumbled over nabble, i
stumbled over nearly everythink i essentialy have to know!


Well, the learning curve is really steep, that's true. I personally also did 
have to study the sources quite often. Phillips book did help, but often only 
after a personal advice from himself or after studying the sources.


The real problem for me was that Zope 3 is all about a new software 
development concept, namely, the component design with interfaces / 
adapters / utilities etc. This is something that the Joe Average programmer 
is not used to, so he does not really know how to map his ideas to a 
componentized architecture. I don't know how to deal with this problem, 
perhaps a theoretical book about componentized software design could help; On 
the other hand newbies like to start right away and don't want to study a 
complicated design book beforehand.


I think this is the problem that Grok attempts to address.

Another issue is the ZMI. Most people, who begin Zope3, start out with 
Phillips book or similar documentation which uses and adapts the ZMI. 
However, many people sooner or later come to the conclusion that the ZMI can 
not be configured to their needs, things get very complicated and people are 
frustrated. Many people, such like me, then have a look at a ZMI-less design 
(e.g. z3.pagelet, z3c.form etc.), which works better for many projects.


Anyway, after approx. 1 year of Zope 3 development, I can say that going 
through these hassles and problems was definitely worth it. Moreover, I 
think, Zope 3 is very much "work in progress" and I'm expecting many things 
to come that will solve the issues above and make the entry step easier.


Zope 3 is also one of the most advanced and powerful development 
frameworks in existence - in any language. I miss the Component 
Architecture so much when I do Java. ;)


Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: [Zope-dev] Zope 3.4.0 candidate 1 Released

[Martin Aspeli]

Chris Shenton wrote:

"Martijn Faassen" <[EMAIL PROTECTED]> writes:


On the rest of your rant, I agree that the beginner experience for
Zope 3 is suboptimal. Work is slowly progressing towards a new website
for Zope. As an alternative you might like to look at Grok
(grok.zope.org), which is based on Zope 3 as well but may be somewhat
easier to get started with. That said, our documentation is far from
complete yet, and we don't have a forum either. :)


I've been poking around the edges of Plone for a while and Plone3 makes
the learning wall even steeper than Plone 2.  So last weekend I got
Grok, followed the tutorial, and had an application up in a day that
took me a week in Plone3.  Grok seems a great way for me to get into
Zope without worrying about all the details yet. 


Kudos to the Grok team for such a pleasant product, and for some REALLY
good tutorials.  Thanks!


Grok and Plone are not exactly competitors. You're not comparing apples 
and apples at all. :)


I think Plone can learn a lot from Grok's philosophy and that the two 
projects can share a lot more infrastructure, though.


Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: [Zope-dev] Zope 3.4.0 candidate 1 Released

[Martin Aspeli]

Kurt Zitze wrote:

if you want to raise the userbase of zope, the first and most obvious
thing to do is, get a forum running! mailing lists are bu*** and
completly out of date. it is max cumbersome to login into your email
account to do a post and so on, i think i dont need to enumerate all
the disadvantages of a mailing list compared to a forum. i am even
not aware of how to replay to a certain message with this mailing
list. why make it difficult if it could be easy? just get a forum and
you have done 50% of the things you could do to improve the
development experience with zope.


http://news.gmane.org/search.php?match=zope
http://www.nabble.com/Zope-f6706.html

... and when you start participating actively in a project or two, 
you'll realise why a web based (only) forum is far, far sub-optimal to a 
properly archived mailing list with an NNTP and web gateway.


If you're having trouble replying to emails ... mmm

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Dynamic __providedBy__

[Martin Aspeli]

Hi!

I may have a use case where I need an instance to provide marker
interfaces dynamically. That is, under certain conditions I want the
type to say it provides a particular marker interface, and otherwise it
doesn't. It still needs to support the usual by-class and
directly-provided idioms for providing interfaces, including
directlyProvides()/alsoProvides().

Is such a thing possible? Perhaps one could make __providedBy__ a
dynamic property or something? Or is this a very bad idea?  :)

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: z3ext

[Martin Aspeli]

Nikolay Kim wrote:

Martin,


This looks very complete and powerful, from a super quick glance.


I can give you manager role on z3ext.net so you can look closely on
management interface.


Cool! I signed up already.

I have a dream that the various Zope 2 + Zope 3 CMS efforts will get 
better at sharing components. Did you use/look at any of the plone.* 
components from Plone 3 (that work on Zope 3 also)? 

no. as i understand plone.* is UI related code for plone? i use
completely different patterns for UI building.


Not really. plone.app.* is the namespace we use for things that are 
Plone "application"/UI specific. Things that could be reusable outside 
Plone (either on plain Zope 3, plain Zope 2 or CMF) should live in 
plone.*. plone.locking, for example, depends only on the WebDAV 
implementation (not sure if that's Zope 2 specific, though); 
plone.portlets and plone.contentrules should work in plain Zope 3 (the 
former has been used in Grok). I'm sure there are others too.


Do you think any 
parts of z3ext are useful in other systems?

yes, why not. for example z3ext.controlpanel powerful and easy to use 
configuration system
same for almost all other packages.


Cool!


z3ext.net is built with z3ext, you only need checkout z3ext.homesite package
  svn co https://z3ext.svn.sourceforge.net/svnroot/z3ext/z3ext.homesite/trunk 
z3ext
I'm not entirely sure it's in everyone's interest to have something that 
looks so very much like Plone's out of the box look and feel that is not 
based on Plone at all (as I understand it) - least of all z3ext's, since 
it may get confused with Plone.

there was one reason, i'm not designer and plone looks very polished :)
but in general i agree without about confusion. maybe somebody will help
to make default skin not so plonish.


After my five-minute look at this system, I thought of this as "Plone 
clone". If that's not how you want the system to be perceived, then 
changing the skin would be a good start. The basic UI metaphors are 
virtually all the same too.


The Plone Foundation *may* have a problem with something that's not 
Plone looking and feeling so close to Plone, because of brand and 
trademark protection. I would at least have a word with the PF board 
before promotion this using Plone's look and feel to avoid any confusion 
or confrontation later.


Is this just a theme for this one site, or is it the way that z3ext 
looks without customisation?

z3ext.net is default skin without customization

recently i made http://www.alteringthefuture.com/ for my firend,
actually he did this. this site created only with TTW customization.


Cool.

I'm actually quite interested in what techniques you are using for TTW 
customisation. Can you explain the model here in more detail?


Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: z3ext

[Martin Aspeli]

Hi Nikolay,

This looks very complete and powerful, from a super quick glance.

I have a dream that the various Zope 2 + Zope 3 CMS efforts will get 
better at sharing components. Did you use/look at any of the plone.* 
components from Plone 3 (that work on Zope 3 also)? Do you think any 
parts of z3ext are useful in other systems?



z3ext.net is built with z3ext, you only need checkout z3ext.homesite package
  svn co https://z3ext.svn.sourceforge.net/svnroot/z3ext/z3ext.homesite/trunk 
z3ext


I'm not entirely sure it's in everyone's interest to have something that 
looks so very much like Plone's out of the box look and feel that is not 
based on Plone at all (as I understand it) - least of all z3ext's, since 
it may get confused with Plone.


Is this just a theme for this one site, or is it the way that z3ext 
looks without customisation?


Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: [Zope-dev] Zope 3.4.0 candidate 1 Released

[Martin Aspeli]

Stephan Richter wrote:

On Friday 01 February 2008, Martijn Faassen wrote:

http://www.openplans.org/projects/zorg-redux


This project does not seem to be public.


Right - thanks Martijn for spilling the beans prematurely. ;-)

We haven't wanted to make too much of a splash about this until we have 
something tangle and working that we can actually present. Suffice it to 
say that we have Zope Foundation support and the right people involved. 
Once those people have produced a site, with a theme and some initial 
content that shows the direction we're proposing, we want to open it up 
for further suggestions and new content from a wider audience. Until we 
have that, though, we risk either getting lost in the noise of general 
development or disagreements (both of which have killed previous 
zope.org efforts), or setting expections that we can't meet.


So - please bear with us. I hope we'll have something in the next few 
weeks, but of course it's hard to predict when everyone is working on 
"best endeavours".


Cheers,
Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Buildout and defining build order

[Martin Aspeli]

Darryl Cousins wrote:

Hi Jim,

Thank you for the reply.

On Thu, 2007-12-20 at 18:23 -0500, Jim Fulton wrote:

On Dec 20, 2007, at 6:07 PM, Darryl Cousins wrote:


Hi,

Is it possible to define in which order the parts are built.

Yes, they are built in the order listed.


You must mean the order the sections are listed and not the order listed
in parts. I've tried playing with both orderings but when I start the
buildout it first runs through the develop eggs then starts on with ZODB
- and the custom python is not built.


I'm pretty sure it runs in the order in the 'parts' variable inside the 
main [buildout] section - at least all my testing has indicated this is 
the case.


Can you create a minimal test buildout that demonstrates different 
behaviour?


Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: buildout and egg depedencies

[Martin Aspeli]

Hi Jeff,


In general, once you understand that recipes are just eggs, loaded with
an entry point, and that options are passed around in dicts-of-dicts, I
find buildout pretty easy to get to grips with.


I understand that they're eggs with entry points. But that doesn't
help me figure out all of the options available. It's hard to get a
simple straightforward list of a Recipe's configuration options, how
to format them (since the ConfigParser format is so godawful), etc.


Well, of course there's no substitute for decent documentation! :-)

Buildout itself is pretty well documented, IMHO - I use 
http://pypi.python.org/pypi/zc.buildout/1.0.0b31 and ./bin/buildout 
--help as references.


The plone.recipe.* recipes also attempt to document their options 
clearly, for example 
http://pypi.python.org/pypi/plone.recipe.zope2instance/1.0


and then we have high level documentation in places like 
http://plone.org/documentation/tutorial/buildout.


Of course, some of that's Zope 2 and Plone specific, but at least it's 
not an intractable problem. :)



I've looked at zopeproject. The biggest problem is that we have large,
existing applications that don't fit those molds. Starting up a
totally fresh project? Relatively easy.


Yes, of course - legacy's always hard. :)


But just today, I was trying to get a running buildout instance thingy
going for a customer who has a very small site which we haven't yet
deployed. Now I'm just running into problems with finding out which
things are configured (in ZCML) by default and which aren't. And the
last stumbling block I hit before I gave up for the day involved
`zope.filerepresentation` installing as a zipped egg, which then gets
in the way of ZCML being able to load its configure.zcml file. I tried
to find out if there was an 'always_unzip' option for Buildout, but it
seems to only be a part of buildout's easy_install API.


Unfortunately, that's a setuptools problem. Maybe zc.buildout could have 
that option - it'd be nice. Zipped eggs are a PITA when it comes to 
ZCML. :-(


Btw, this means that no-one's ever used zope.filerepresentation except 
in develop mode, which is pretty crap. :)


Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: buildout and egg depedencies

[Martin Aspeli]

Hi Jeff,


How did it come to be that the Python tools are so bad at this?


To be fair, it's a hard problem. In Java land, you have similar problems 
with JARs in that they frequently have the same filename but different 
versions and there's no nice way that I know of to manage conflicts. 
Most Java projects I've worked on have had handful of ghost JARs - 
no-one knows where they come from, but they break something when removed 
and sometimes you get obscure errors like NoMethodDefFound when versions 
get out of sync...



Setuptools is horrible when it comes to doing local
(instance-home-ish) installations, requiring virtualenv or whatever.
And I've had little success getting those to work. Maybe they just
break my way of thinking about how Python does and should work.


virtualenv is reasonably easy in my experience (make sure you have the 
latest version), and reasonably natural (just use the binary in the env, 
not the global python binary).



Whatever. Buildout looks like it tries to address many of those
issues, but again I find myself fighting against my natural instincts.


I've been happy with buildout when I've used it in anger.

Where's some end user documentation? 


The cheeseshop page for buildout is pretty decent, and I wrote 
http://plone.org/documentation/tutorial/buildout.



The doc-test is difficult to read
and speaks in generics, not about day-to-day problems. The Recipes are
even worse, leaving one to clamor through the web to get back to the
cheeseshop page and then face the same difficult to read doc-test kind
of 'help'. Which I wouldn't mind reading, if I could easily read that
help locally, like a man page or using Python's 'help()' system.
``buildout help zc.recipe.egg``, ``buildout help zc.recipe.cmmi``,
whatever.


+1

In general, once you understand that recipes are just eggs, loaded with 
an entry point, and that options are passed around in dicts-of-dicts, I 
find buildout pretty easy to get to grips with.



That I'm still frustrated by these tools all this time later is
disappointing. And yes, it's easier to write your own. That's the
Python way. Don't understand [zope, pylons, cherrypy, quixote,
skunkweb]? Write your own web framework! Python does make it easy to
do that because it's such a fantastic language. But I think that
attitude, in turn, gives us worse tools, because everyone scratches
their own itch and moves on, leaving everything incomplete. It seems
almost like it's easier to write your own tool than to read whatever
cryptic documentation exists for another.


Completely.


I've gotten Buildout to work on some small components. It's great -
check out the source, run buildout, wait, wait, wait, and then have a
nice little self contained testing and development environment. But
I've never been able to get a full Zope 3 "Application" up and running
in that environment.


Have you looked at zopeproject (uses buildout) grokproject (uses 
buildout) or Repoze (uses virtualenv)?



There's just no time and the tools are just too hard to learn under
the circumstances my little company is operating in right now.
Buildout *seems* like it could fix some big problems that have been
hitting us hard in recent weeks. But I still can't wrap my head around
how.


Maybe you should start a new thread and tell of your use cases and ask 
for examples of how to solve them?


Martin


--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Eggs and classic instance homes, again... (was Re: Eggs, workingenv.py, and 'classic' instance homes)

[Martin Aspeli]

Hermann Himmelbauer wrote:

Am Freitag, 9. November 2007 01:31 schrieb Jeff Shell:

Oops. Forgot to send this to the list as well as Stephan. Goddamn Gmail.

On Nov 8, 2007 8:28 AM, Stephan Richter <[EMAIL PROTECTED]> 

wrote:

Hi Jeff,


- zope.component 3.4.0  (or anything built into the zope 3.4 tarball)
- sqlalchemy 0.4.0
- simplejson


Btw., how do you integrate Zope3 with SQLAlchemy 0.4? As far as I 
know "zalchemy" is not SQLAlchemy-0.4 ready yet?


I believe collective.lead (in cheese shop) works with 0.4 (there's also 
a branch in the Plone Collective SVN for slightly better integration). 
Although I haven't tested it on straight Zope 3, it's really just using 
ZODB features so it ought to work.


Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Getting current user and current user's group in a buildout script

[Martin Aspeli]

Derek Richardson wrote:
So, is there an easy way to do it? I know I can write a recipe, but a 
recipe seems heavyweight for this. It seems to me that access to these 
two values should be built into buildout as implicit variables. Is this 
contrary to the lightweight, pluggable design philosophy?


What's the use case here? I can't think of many good uses for something 
that's going to vary depending on who's running the buildout.


Secondly, buildout and at least the recipes we like to promote are 
cross-platform. This may not be as easy to achieve on Windows.


Thirdly, users can be in multiple groups, so at least you'd need a list, 
which may not lend itself so well to the standard way of using variables 
in buildout.


Martin

--
Acquisition is a jealous mistress

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Kupu and Zope3

[Martin Aspeli]

Jeff Shell wrote:
On Aug 20, 2007, at 3:45 AM, "Jeremy Cook" <[EMAIL PROTECTED]>  
wrote:



Is anyone using Kupu (or any other visual editor) with zope3? I saw
hints that it might be ported to zope3 or conversely that "kupu must
die". When I tried installing it under zope3 I didn't get awfully far.


I tried and tried to use Kupu, and it was damn near impossible. I  
wouldn't recommend it to anybody. Which is too bad - the editor itself  
is great. But integrating it into custom environments was way too  
difficult.


Note that the Plone community has an interest in getting a kupu Zope 3 
widget. We haven't had much time since it wasn't in scope for 3.0, but I 
know of several people who need/want it.


And yeah... it's not the easiest thing in the world, unfortunately. :-/

Martin

--
Acquisition is a jealous mistress

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: ObjectModifiedEvent but not ContainerModifiedEvent

[Martin Aspeli]

Chris Withers wrote:

Hey All,

How do I subscribe a susbcriber to ObjectModifiedEvent but not 
ContainerModifiedEvent?


I have a subscriber that is currently subscribed to 
IObjectModifiedEvent, but as a result it's getting called when objects 
are added and removed whereas I only want it when the container is 
actually getting modified.


def handler(event):
if IContainerModifiedEvent.providedBy(event):
return

Martin

--
Acquisition is a jealous mistress

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] RE: Blog naming proposal

[Martin Aspeli]

Mark, Jonathan (Integic) wrote:
> 
> A better name is Noiszzz 
> 
> Noize starts with a capital N, then a vowel, then a "Z" then another
> vowel. It is too close to the word "Nazi" for some English speakers. 
> 
> I am not saying that people who like the name Noize also like Nazis. I
> am just saying that the association will be there. Noiszzz is better
> because the triple zzz is itself a noise.
> 

That's an even worse name ;-)

Noize sounds nothing like Nazi. I don't think the world is so sensitive that
we need to ban the letters N and z from the same word forever.

Martin
-- 
View this message in context: 
http://www.nabble.com/RE%3A-Blog-naming-proposal-tf3865792.html#a10952236
Sent from the Zope3 - users mailing list archive at Nabble.com.

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Blog naming proposals

[Martin Aspeli]

Florian Lindner wrote:

Thanks for all suggestions and ideas. I have not decided yet but at the moment 
I tend to name it "Noize".
Most blogs are producing more smoke than heat thus more noize than signal. And 
a "Z" is also in it.


FWIW, I think it'd sound a lot less like a tool for l33t teenagers if it 
didn't have the Z in it, but otherwise a good choice of name. :)


Martin

--
Acquisition is a jealous mistress

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Blog naming proposals

[Martin Aspeli]

Florian Lindner wrote:

Hello,
some people might have noticed I am developing a Blog package for Zope3.
Since it slowly becomes functional (an older version is working at 
http://xgm.de) I want to release it (under an free and open source licence).


One thing still missing is a good name. A name that quickly comes to my mind 
is zBlog but which is not very fancy.


What ideas have you for Zope3 blog package, what would you choose?


"Blue Blog"

if it's not already taken.

--
Acquisition is a jealous mistress

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Blog naming proposals

[Martin Aspeli]

Benji York wrote:

Florian Lindner wrote:

What ideas have you for Zope3 blog package, what would you choose?


I would choose anything as long as it doesn't have a Z in it.  But 
that's just me.


+1 - using a "z" for an "s" is excessively lame, imho. :)

Martin


--
Acquisition is a jealous mistress

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Still stuck without views.

[Martin Aspeli]

Robert Norman wrote:

Hi again,
I'm trying to learn Zope through the Web Component Development book and 
find myself stuck implementing simple views. This was posted earlier but 
and I've worked on it since but feel totally unable to proceed.


I'm working on WinXP.  I can manipulate simple persistant objects using 
debugzope. The objects are listed in the ZMI. However I can't do 
anything with the views supplied as part of the example code.  For 
example, under debugzope , following the instructions in the text, if I 
try to examine the supplied view with:


view = getMultiAdapter((lasagne, request), name=u'index.html')

I get a lookup error.  Both lasagne, and request are valid objects.  
Also, from my browser even though the ZMI shows my objects,  any attempt 
to view them fails. Apparently my view is not being registered. A line 
does exists in the configuration file that points to the folder 
containing the view...




This is all code supplied by the book pasted in from the web site -- I 
don't have the depth of knowledge of Zope yet to figure this out. 


I suspect the configure.zcml itself isn't being parsed. An easy, crude 
way of figuring this out is to introduce a syntax error. Change that 
line to read:




I'm not sure which part of the book you're in, but you may want to try 
to put a file in etc/package-includes called e.g. test-configure.zcml, 
and have it include:


 

where my.package is the name of the package you're currently in.

Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Field validation errors in formlib action handlers

[Martin Aspeli]

Hi,

I still find the formlib validation machinery a bit confusing, I'm afraid...

I have a form which saves values in a relational database. Because of 
concurrent requests, it's possible that a key constraint in the database 
may be violated on save. I can't know this until the actual action 
handler, though.


The error would relate to a particular field (basically, the field is an 
integer whose value can't be above a number N, where N is dependent on 
the current state of the database, think something like a booking 
database where you request tickets, but others may have snatched the 
last remaining tickets before you hit Save).


I'd like to be able to catch a database-layer exception in the form 
action handler method and then have the form return with a status 
indicating an error on a particular field, with the form values filled in.


I've done interface constraints before and raised ValidationErrors. 
However, in this case that won't work because the error can only occur 
during the action handler (and without access to the request, which 
carries a particular foreign key, I can't look in the database to 
predict whether it would fail).


Is there some way of doing this?

Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Utility Local to an Annotation?

[Martin Aspeli]

Hi Derek,

b - In the Atom syndication format, UUIDs are necessary for two things. 
One, the overall feed has a UUID. This is easy - I'm storing them in a 
site-local named utility, indexed by the feed annotation object.

What do yuo mean "indexed by"?


Hand the utility a feed annotation, get back a uuid for the feed.


Also, is this UUID not just another aspect of feed "metadata" and thus a
candidate for the container annotation?


This was the original plan, but I was convinced to go with the more
generalized solution of a uuid utility. I guess I can cache it in the
container annotation, but that's an optimization and tangential to this
discussion.


I don't think it's tangental. When we discussed this before, I was under 
the impression you wanted to have automatically assigned UUIDs to 
content objects. That sounded like something which should (a) be 
external to that object and (b) be centralised, with a key-reference 
type functionality in the same way as zope.app.intid, to allow semantics 
like "I have a UUID, now where is the object that it belongs to".


I still thing this sounds like useful, general behaviour.

However, now we are also talking about UUIDs of "feeds", which are 
implemented as views. I'm assuming the same feed gets the same UUID each 
time (if it does not, then you just generate it in the view, 
dynamically, which is simple).


If the feed needs metadata, and this metadata is context-specific, then 
storing that metadata in an annotation on the feed source (the 
container) seems sensible. However, the feed UUID is then just another 
part of that metadata.


The advantage of the utility approach is that it can generalised a lot. 
You can index based on generic container events, for example. If the 
feed/annotation is being managed explicitly, then why bother trying to 
fire "contentish" events and dealing with things like key-references for 
something which is in an annotation of an object?


The only reason I'd see for a central utility keeping track of UUIDs and 
feeds would be if you needed some kind of global UUID-to-feed lookup 
service.


If you do choose to just treat the feed UUID as metadata, there is of 
course no reason why you can't share the UUID-generating code between 
the feed annotation and the more general global UUID registry/id utility.


 Two, 
each entry in a feed has a UUID. A content item that is an entry (a 
file, in the current case) can, however, be in multiple feeds and needs 
a different UUID in each. Thus, I need to be able to look up UUIDs by 
the content object that will be rendered as a feed entry and look them 
up relative to the feed, rather than globally.



That sounds to me like you want a composite UUID - a UUID utility gives each
content item a UUID (which is not feed-specific, and stays in line with the
general concept of a content object UUID). The one you put in the feed is
the feed's UUID and the object's UUID are combined. You could possibly use
some kind of hash if you needed to.


I considered this. I have a certain understanding of what I'm doing that
precludes the combinatorial UUID approach, but no one I talk to seems to
grasp it, so I think I will air it here so we can discuss it.

I am using RFC 4122 type 1 UUIDs. These are (practically) guaranteed
universally unique, as they are based on spatial (MAC address) and
temporal (CPU clock time) location. They have safeguards built in for
things like multiple CPUs and resetting the CPU clock.

However, they are only (practically) guaranteed universally unique if
*everyone* follows the same algorithm. If you use a different algorithm
for computing your UUIDs, then they may collide with my RFC 4122 ones,
since your algorithm doesn't compute them the same way and thus may use
different, supposedly unique information included in a different way
that results in the same UUID that I generate. Highly unlikely, but
vastly more likely than if we all follow the RFC. Thus, to me, part of
being a good citizen of the UUID world is to follow the exact RFC 4122
algorithm, so we can all get along without collisions.

There is no provision in RFC 4122 for combining two UUIDs to generate a
third, still unique, UUID. So, in my mind, combining two UUIDs, by
whatever method, results in a relative UID, not a UUID.

Granted, I live in a fantasy world where everyone plays by the same RFC
4122 rules. Still, it's a nice world and I want to do what I can to
encourage others to join me in it. So, I want to generate
strictly-compliant RFC 4122 UUIDs for use in my product (and my utility
makes it easy for others to use them elsewhere in Zope).

Thus I take the hard road, here. Is there a flaw in my reasoning?


I understand this problem, and it makes sense. I think it's a good line 
to take. However, does the spec say the UUID *has* to be RFC 4122 type 
1? If not, then a plain concatenation (no hash) of a UUID, with some 
separator that's not going to be output by the UUID seems valid enough 
to me. If you have tw

Re: [Zope3-Users] Utility Local to an Annotation?

[Martin Aspeli]

Derek Richardson-2 wrote:
> 
> Yes, it does feel like I'm going about this the wrong way.
> 
> a - The "feed" is actually just configuration metadata - whether the 
> feed is enabled, whether it is recursive, what its display name is, etc. 
> The actual feed document is not stored - it is simply rendered 
> dynamically when requested, based on the metadata and the existent 
> content items. The "feed" is an annotation on a container; at the 
> current time, only folders are feeds and only contained files are feed 
> items.
> 

Okay, so the feed is really a view, which consults some annotations on a
container and then recursively looks for objects in that container and
constructs XML?



> b - In the Atom syndication format, UUIDs are necessary for two things. 
> One, the overall feed has a UUID. This is easy - I'm storing them in a 
> site-local named utility, indexed by the feed annotation object.
> 

What do yuo mean "indexed by"?

Also, is this UUID not just another aspect of feed "metadata" and thus a
candidate for the container annotation?


 Two, 
> each entry in a feed has a UUID. A content item that is an entry (a 
> file, in the current case) can, however, be in multiple feeds and needs 
> a different UUID in each. Thus, I need to be able to look up UUIDs by 
> the content object that will be rendered as a feed entry and look them 
> up relative to the feed, rather than globally.
> 

That sounds to me like you want a composite UUID - a UUID utility gives each
content item a UUID (which is not feed-specific, and stays in line with the
general concept of a content object UUID). The one you put in the feed is
the feed's UUID and the object's UUID are combined. You could possibly use
some kind of hash if you needed to.



> c - I use the UUIDs only when rendering the feed, looking them up by 
> object and sending them to the client embedded in the feed document. 
> They are used for no other purpose.
> 

Still, the concept of a UUID of a content object ought to be separate from
and more general than your particular need for a feed item UUID.



> So, my situation is that I've written my nifty uuid utility based on 
> intid and I want to reuse it for feed entry UUID lookup. I can't use 
> unnamed utilities because I may be accessing different uuid utilities 
> for entries from the same place in the tree. It occurs to me that I 
> could make them named utilities local to the object underlying the entry 
> and look them up by the feed UUID they correspond to, but, in my 
> understanding, that would require littering sites all over the place, 
> which seems like bad citizenship. 
> 

It does. I would not do this at all.

I think the cleanest design would be:

 - You have a generic object UUID facility
 - You make a UUID for a feed when you create it, and store it in the feed
annotation
 - You generate feed item UUIDs on the fly from a hash/concatenation of the
feed UUID and the generic object UUID

Martin

-- 
View this message in context: 
http://www.nabble.com/Utility-Local-to-an-Annotation--tf3646832.html#a10221944
Sent from the Zope3 - users mailing list archive at Nabble.com.

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] Utility Local to an Annotation?

[Martin Aspeli]

Derek Richardson-2 wrote:
> 
> Benji York wrote:
>> Derek Richardson wrote:
>>> The specific case is uuids for atom feed entries. We have annotations 
>>> representing feeds and I would like my uuid utility to be local to the 
>>> feed annotation, thus recording and making available uuids only for 
>>> entries in that feed.
>> 
>> How about a multi-adapter from content and feed to UUID?
> 
> Hmmm, to do that I have to be able to annotate an annotation, right? As 
> the feed is an annotation and that is where I want to store the UUIDs. I 
> tried this tonight and was unable to make it work - I got the following:
> 

There's no reason why you can't mark an object that you fish out of an
annotation with IAttributeAnnotatable and then annotate that. However, this
feels suspiciously like you're asking the wrong kind question. :)

Can you explain (a) what you are trying to store (what is a "feed" in this
case? is it just feed-specific metadata? or an actual list of items rendered
to RDF?) and (b) what you need UUIDs for and (c) when you need to use the
UUIDS?

Martin
-- 
View this message in context: 
http://www.nabble.com/Utility-Local-to-an-Annotation--tf3646832.html#a10217406
Sent from the Zope3 - users mailing list archive at Nabble.com.

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: zope.intid and UUIDs

[Martin Aspeli]

Derek Richardson wrote:

Philipp von Weitershausen wrote:
Martin and Gary pointed out other good reasons why not to go with 
subclassing: the standard intid utility doesn't work in all 
environments. Apparently in Zope 2 you'll need a slightly differnet 
implementation. If you just defer to it via utility lookup, your UUID 
utility might actually work on both platforms, as long as there's an 
intid utility. It makes things more flexible.


Hmmm. I've looked in Zope 2.10.3 final (the earliest release I may 
target) and zope.app.intid is the same between Zope 2.10.3 and Zope 
3.3.1, except for the presence in 2.10.3 of 
zope.app.intid-configure.zcml, which is just a slug. Am I looking in the 
wrong place?


Yes, it's there, but that doesn't mean it *works* in Zope 2. You should 
look at five.intid, which is an attempt to make it work in Zope 2.


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Zope 3.4.0a1 released

[Martin Aspeli]

Robert Hicks wrote:

Is this series targeting Python 2.5?


No.

Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] zope.intid and UUIDs

[Martin Aspeli]

Derek Richardson-2 wrote:
> 
> We've talked a lot about the composition alternative to my idea, but we 
> haven't talked about my idea much. What is suboptimal with the way I'm 
> proposing, other than that it requires changing zope core? Or is that a 
> good enough reason to not do it?
> 

Where does the BaseId base class live? If it lives in zope.app.intid you
still have a hard dependency on that, and composition may make more sense,
because it allows you to benefit from an override of the intid
implementation, for example.

It doesn't seem important enough to me to justify a brand new package for
bundling with Zope just to avoid such a dependency.

Plus, using composition means you don't need to sync your  own releases code
Zope releases.

Martin

-- 
View this message in context: 
http://www.nabble.com/zope.intid-and-UUIDs-tf3597738.html#a10082722
Sent from the Zope3 - users mailing list archive at Nabble.com.

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] Interfaces in Schemas

[Martin Aspeli]

Hermann Himmelbauer wrote:
> 
> Hi,
> I wonder if it's possible to define attributes in a schema that reference 
> other interfaces. For instance, I have a schema for a car and another one
> for 
> a wheel and what I want to do is something like that:
> 
> class IWheel(Interface):
>type = TextLine()
> 
> class ICar(Interface):
> 
>model = TextLine()
> 
>wheel = ??? of type IWheel ???
> 

wheel = schema.Object(schema=IWheel)



> or even better:
>wheel = List(min_length=4, max_length=4, 
> value_type = ??? of type IWheel???)
> 

value_type=schema.Object(schema=IWheel)



> What would be really great now is if formlib could handle this and would 
> automatically set up the needed widgets.
> 

Not sure what it does; I think you'd need to write some custom reference
widget type thing; you can't "fill in a wheel", really. :) Where would the
Wheel objects come from?

Martin
-- 
View this message in context: 
http://www.nabble.com/Interfaces-in-Schemas-tf3601683.html#a10061121
Sent from the Zope3 - users mailing list archive at Nabble.com.

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: RFC 4122 UUIDs

[Martin Aspeli]

Fred Drake wrote:

On 4/6/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:

How is there a ZCML pain? Simply register the adapter for all
IAnnotatable objects. Typically your content objects are annotatable
anyway because you want DublinCore stuff etc.


This sounds like this will result in huge numbers of UUIDs being
generated for objects that aren't "syndicatable content" in this
application.  The subscriber should probably be registered for objects
that can be syndicated, not everything, to avoid useless CPU load and
database bloat.

Of course, as the OP suggested there's already an annotation for
syndication-related information, I'd just add it to that, and not use
a separate annotation.


Another common pattern is to invent a new marker interface, e.g. 
IUUIDAware, which perhaps inherits from IAnnotatable so that it's clear 
there are annotations involved. Then you register adapters from that, 
and use a generic ZCML statement to give various objects this marker. In 
a CMF world, for example, we may do:






Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: RFC 4122 UUIDs

[Martin Aspeli]

Stephan Richter wrote:

On Wednesday 04 April 2007 14:34, Derek Richardson wrote:

I believe that that will not guarantee a *universally* unique id, but
only an id unique within that ZODB. Am I wrong?


Well, intid guarantees to be unique for this Zope instance, even accross 
multiple databases conencted to this Zope instance. All you have to do is to 
id the Zope instance, for example, ip+port should suffice.


One problem we see in Plone (which has similar types of extrinsic ids) 
is that if you export/import into a new site, ids are not stable (unless 
you exported the entire site, including the id). When used for e.g. 
references between objects, these break.


If UUIDs were essentially hashes that'd make this problem managable. I'm 
not sure if this particular approach solves that though.


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] RFC 4122 UUIDs

[Martin Aspeli]

Derek Richardson-2 wrote:
> 
> Martin Aspeli wrote:
>> 
>> 
>> Stephan Richter-2 wrote:
>>> On Wednesday 04 April 2007 13:06, Derek Richardson wrote:
>>>> I am hoping that Zope 3 assigns an RFC 4122 UUID to each content item.
>>>> If not, I am hoping there is a third-party product to do this.
>>> No there is neither. We have an intid utility that guarantees
>>> System-wide 
>>> unique ids. This utility is used at several places most notably the
>>> catalog.
>>>
>>>> I would like RFC 4122 UUIDs to provide standard Atom feeds of Zope
>>>> content [1].
>>>>
>>>> It will be better if Zope itself assigns UUIDs, so that there is a
>>>> single source and not a possibility of multiple packages assigning
>>>> different UUIDs to the same content item.
>>> You have to write your own utility to generate the UUID. I checked the
>>> RFC 
>>> quickly and our IntIds are certainly not of the format requested by RFC
>>> 4122.
>>>
>> 
>> Presumably, the intid implementation would be a useful reference for such
>> a
>> utility, and this would a good canidate for a general, re-usable package.
>> 
>> Martin
> 
> Good. I would like to write it as a general, re-usable package.
> 
> Generating RFC 4122 UUIDs is easy - there's a routine for it in the 
> python 2.5 standard libraries and a python 2.3+ version here:
> 
> http://zesty.ca/python/uuid.html
> 
> What seems more difficult is how to plug the routine in so that all 
> content items receive one and only one UUID upon creation. Maybe listen 
> for IObjectCreatedEvent and annotate then? Or is there a potential race 
> condition that means events are not the way to go?
> 
> (Unsure of the depths of Zope 3's architecture)
> 

Look at zope.intid; it should be IObjectCreatedEvent or IObjectAddedEvent.

Martin

-- 
View this message in context: 
http://www.nabble.com/RFC-4122-UUIDs-tf3527097.html#a9842467
Sent from the Zope3 - users mailing list archive at Nabble.com.

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] RFC 4122 UUIDs

[Martin Aspeli]

Stephan Richter-2 wrote:
> 
> On Wednesday 04 April 2007 13:06, Derek Richardson wrote:
>> I am hoping that Zope 3 assigns an RFC 4122 UUID to each content item.
>> If not, I am hoping there is a third-party product to do this.
> 
> No there is neither. We have an intid utility that guarantees System-wide 
> unique ids. This utility is used at several places most notably the
> catalog.
> 
>> I would like RFC 4122 UUIDs to provide standard Atom feeds of Zope
>> content [1].
>>
>> It will be better if Zope itself assigns UUIDs, so that there is a
>> single source and not a possibility of multiple packages assigning
>> different UUIDs to the same content item.
> 
> You have to write your own utility to generate the UUID. I checked the RFC 
> quickly and our IntIds are certainly not of the format requested by RFC
> 4122.
> 

Presumably, the intid implementation would be a useful reference for such a
utility, and this would a good canidate for a general, re-usable package.

Martin
-- 
View this message in context: 
http://www.nabble.com/RFC-4122-UUIDs-tf3527097.html#a9841735
Sent from the Zope3 - users mailing list archive at Nabble.com.

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Port Zope3 product to Zope2/Plone

[Martin Aspeli]

Hermann Himmelbauer wrote:

Hi,
I'd like to develop a little Zope3 package which I also want to use with a 
recent Zope2/Plone release. 


Is this possible? If yes, what do I have to do to be compatible?


It depends on what the package does. Something that we do from time to 
time in Plone is to devel a plone.something package that is generic and 
depends only on Zope 3, and a plone.app.something package that provides 
some Plone specific integration, UI and/or some Zope 2 overrides for 
various components (e.g. to mix in acquisition).


See for example plone.portlets and plone.app.portlets, both in 
http://svn.plone.org/svn/plone.


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: general zope question

[Martin Aspeli]

tyson wrote:
I would like to build an application with Zope3 that does not use the 
ZODB at all.  I want to pull my data from my own database, display it to 
the user and allow them to change and edit the values with forms.  Is 
Zope the right solution for this situation?  I know everyone says the 
ZODB is very powerful and I know forms are very easy to generate through 
widgets and formlibs, but I don't want to store my information via 
Zope.   Sqlos is another solution I have heard of  but I dont' want to 
use that either.  Is it conceivable to build an application in Zope3 
with an outside database and not use the ZM?


You can use formlib and views and all that without storing the data in 
persistent objects in the ZODB. It just happens that storing things in 
the ZODB is really easy too.


You may be interested to look at http://plone.org/products/alchemist 
which uses some of these tools against relational data sources. It uses 
SQLAlchemy, which I recently learned and which seems really lovely to 
work with.


It's not a pure zope 3 solution, but I'm told the zope 2 dependencies 
are fairly minimal and it probably could be refactored to not depend on it.


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] Zope3 with RDBMS (avoiding ZODB)?

[Martin Aspeli]

I am not an expert and I've never developed a big "pure Zope 3" application,
but I have consumed a lot of Zope 3 ilbraries and concepts, from Plone on
Zope 2, and mostly that's been a pleasant experience. Zope 3 is incredibly
advanced and powerful. The concepts take some time to get used to if you are
new to it all, but as far as I'm concerned, it's miles ahead of most of the
competition in terms of architecture and specifically code re-use. 

Of course, you may find that the learning curve outweighs the benefits,
though if you've got Philipp's book, and it makes sense, that's probably a
good gauge.



Stefan Krumbiegel (Galileo Press) wrote:
> 
> 3. Our main problem is: in our Zope2-application we stored our content in
> a
> RDBMS, we avoided ZODB for that stuff. We are definitely going to use an 
> RDBMS
> (PostgreSQL/MySQL) for the new (Zope3 or Django)-project and still want 
> to avoid
> ZODB where possible. This architectural decision is carved out of stone.
> 

I'm curious as to why this is set in stone?

I'd argue that the ZODB is very good if you're trying to store *content*
that may be hierarchical in nature and is not strongly structured.
Certainly, if the alternative is store HTML and Images (gulp) in BLOBs in an
RDBMS, I know which way I'd go. Metadata is more borderline, and could be
easier in an RDBMS, but the catalog provides a good solution for most use
cases if you go with the ZODB.



> Now, where should we start with it in Zope3 to connect it to an RDBMS?
> 

SQLAlchemy seems to be a very popular RDBMS framework for Python. There is
at least one integration package in svn.zope.org. You may also be interested
in the Relational Alchemist product from Kapil; it's for Plone/Zope2 but I
believe there are no strong Zope2 dependencies. Its main premise is to turn
RDBMS table definitions in SQLAlchemy into Zope 3 interface, which can then
be fed to formlib forms and you get generalised forms support. I've not used
it seriously, though. There is a video about it among the Seattle 2006
conference videos at http://plone.org. 



> 5. The ZMI: In Zope2 we never used it.
> Do we need the ZMI in Zope 3 just if we will not use the ZODB for 
> storing our
> content objects but an RDBMS instead. According to 'Web Component 
> Development
> with Zope 3' by Philipp von Weiterhausen the ZMI is used to manage 
> content objects
> stored in the ZODB, so our assumption is, if we do not store them in the 
> ZODB,
> we do not need the ZMI. Is that right or do we need the ZMI for anything 
> else?
> Do we need ZMI in Zope3 for administration or can we do that with 
> scripts etc.?
> 

I'd assume you wouldn't need it. You'd probably need to write a custom
publication object that could map URLs to things in your database. I think
you'll probably be closer to the bleeding edge here than you would be in a
Django/TG world, though, because most people that use Zope also seem to use
the ZODB... normally for good reasons. But I see no reason a-priori why, if
you like Zope 3's programming concepts and libraries, you couldn't use it
with an RDBMS.

Another opion may be to use a hybrid, e.g. with users and/or static pages
and/or some configuration in the ZODB, but with views or objects to act as
proxies to the RDBMS.

Martin
-- 
View this message in context: 
http://www.nabble.com/Zope3-with-RDBMS-%28avoiding-ZODB%29--tf3308983.html#a9204651
Sent from the Zope3 - users mailing list archive at Nabble.com.

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] Question about IOrderedContainer interface

[Martin Aspeli]

Thierry FLORAC wrote:
> 
> 
>   Hi,
> 
> I have a little question about the "IOrderedContainer" interface.
> 
> Actually, this interface is derived from "IContainer", and only contains
> a single method, "updateOrder()" which is an updating method.
> 

That's pretty silly, it should probably be IWriteContainer :-(

Note that if anyone's fixing OrderedContainer, the default implementation
isn't terribly optimal as well - it uses PersistentMappings and not BTrees.
I've got impementations where I wanted to reuse it but use a BTree, and I've
done things like this:
http://svn.plone.org/svn/plone/plone.portlets/trunk/plone/portlets/storage.py

Martin
-- 
View this message in context: 
http://www.nabble.com/Question-about-IOrderedContainer-interface-tf3293814.html#a9162073
Sent from the Zope3 - users mailing list archive at Nabble.com.

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Newbie Question

[Martin Aspeli]

Edward Muller wrote:

I've done Zope2 stuff in the past, including writing Zope2 Products.

We are working on new hosting software and have decided to use Zope 3.

So we're defining our interfaces and have started to define classes  
based on those interfaces and I have a question...


The simple todo app (http://worldcookery.com/files/jeffshell-todo/ 
step1.html) shows the Todo class having three attributes  
(description, details, done). These are all defined in the interface  
using various zope.schema definitions.


But ...

The Boring product (http://products.nidelven-it.no/zope3_boring/)  
does the same thing in the interface with a title attribute. But when  
it gets to the class definition it uses:


def __init__(self, title='Default boring title'):
   self.title = title

The later is more familiar to me coming from Zope 2. Which is right?  
If they are both right, which is *more* right wrt Zope 3 ... and why?


They are both right, and it doesn't matter.

The interface says "when you have an instance of this object, you can 
expect there to be a 'title' attribute". How it got there is not that 
important.


By the way, if you're starting with Zope 3, get Philipp von 
Weitershausen's book Web Component Development with Zope 3 
(www.worldcookery.com). It'll make a lot of this stuff much more clear.


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: formlib vs. cancel button

[Martin Aspeli]

Maciej Wisniowski wrote:

@form.action("Cancel", validator=None)

-1 from me

Currently above code is same as:

@form.action("Cancel")


So I think this is a very common pattern that means:
do standard validation, do not use additional action validator.


Yes. I think you misunderstand my suggestion.

Currently,

@form.action("Cancel")

is the same as

@form.action("Cancel", validator=None)

I think it's fairly unlikely that someone *wanted* the default 
validation and *explicitly* used the second syntax. To say 
validator=None and get a default validator is fairly un-intuitive.


I'm proposing that if you *explicitly* pass validator=None, you get no 
validator. The way the code works currently from what I can tell, the 
easiest way of achieving that would be if the default for which the 
fallback is invoked is not "None" but is some "_marker". This is a 
fairly common pattern.


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: formlib vs. cancel button

[Martin Aspeli]

Marius Gedminas wrote:


I'd be happy to implement and commit something


Yay!


but I'd be happier if
someone else designed the API.  When I try to design APIs myself, I tend
to change my mind too often.  Now I want

@form.action("Cancel", validator=None)

to mean "do no validation".  But perhaps that's not backwards-compatible
enough?


+1 This sounds sensible and intuitive and non-invasive. It was the first 
thing I tried. :)


From my original debugging, I think the problem is that when 
validator=None in formlib, it falls back on some default validator. I 
suggest that the "default" validator is some _marker, e.g.


_marker = object

def action(name, ..., validator=_marker):
   ...

...

   if validator is _marker:
   validator = default_validator

Or some such. The only thing that'd break, probably, would be people who 
*explicitly* set validator=None and expected the default validator, 
which sounds like a pretty marginal case to me.


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: formlib vs. cancel button

[Martin Aspeli]

Philipp von Weitershausen wrote:

Martin Aspeli wrote:

Marius Gedminas wrote:

On Thu, Feb 15, 2007 at 09:55:19AM +, Martin Aspeli wrote:

Dennis Schulz wrote:

I dont know if it is the "proper" way,
but when I return an empty string there is no validation error.

This was also one of the strangest things I found out with formlib.

I found that returning {} also works.

The validator is supposed to return a list of errors.  Neither '' nor {}
are lists.  () is a list.  I use

@form.action("Cancel", validator=lambda *a: ())
def cancel(self, action, data):
...

But this is clearly a design weakness if there is no other way of 
doing it. Something like validator=NULL_VALIDATOR would be fine, or 
some kind of decorator.

+1 for allowing

@form.action("Cancel", validator=form.no_validation)
I added something similar to plone.app.form, but there really, really 
should be support for this use case in formlib in a non-hacky way.


We happily accept patches through collector entries. Actually, aren't 
you a committer? :)


No, not yet, paperwork scares me. And I'm looking into it. I'm just not 
quite sure I (want to) understand the full validation mechanism in 
formlib. We could obviously have such a null-validator in formlib itself 
for import. However, I wonder if it shouldn't be something a bit less 
hacky, e.g. a different type of decorator or some different option 
passwed to the @form.action decorator.


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: formlib vs. cancel button

[Martin Aspeli]

Marius Gedminas wrote:

On Thu, Feb 15, 2007 at 09:55:19AM +, Martin Aspeli wrote:

Dennis Schulz wrote:

I dont know if it is the "proper" way,
but when I return an empty string there is no validation error.

This was also one of the strangest things I found out with formlib.

I found that returning {} also works.


The validator is supposed to return a list of errors.  Neither '' nor {}
are lists.  () is a list.  I use

@form.action("Cancel", validator=lambda *a: ())
def cancel(self, action, data):
...

But this is clearly a design 
weakness if there is no other way of doing it. Something like 
validator=NULL_VALIDATOR would be fine, or some kind of decorator.


+1 for allowing

@form.action("Cancel", validator=form.no_validation)


I added something similar to plone.app.form, but there really, really 
should be support for this use case in formlib in a non-hacky way.


Thanks!
Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: formlib vs. cancel button

[Martin Aspeli]

Dennis Schulz wrote:

I dont know if it is the "proper" way,
but when I return an empty string there is no validation error.

This was also one of the strangest things I found out with formlib.


I found that returning {} also works. But this is clearly a design 
weakness if there is no other way of doing it. Something like 
validator=NULL_VALIDATOR would be fine, or some kind of decorator.


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] formlib vs. cancel button

[Martin Aspeli]

Hi,

I really thought I knew how to do this, but now I can't get it to work 
and I'm really confused.


I have a formlib EditForm, with an action like this:

@form.action("Cancel", validator=lambda *args, **kwargs: True)
def handle_cancel_action(self, action, data):
nextURL = self.nextURL()
if nextURL:
self.request.response.redirect(self.nextURL())
return ''

However, I still get validation errors when I click Cancel. I also tried 
a validator to return None, and no validator at all, and 
"validator=None", they all have the same effect.


Is there a proper/easy way of doing this?

Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] zope.app.cache

[Martin Aspeli]

Hi guys,

I'm trying to determine if zope.app.cache is potentially useable in a
Five/Zope 2.10 environment, and if so how it actually works and what I need
to do to use it.

Unfortunately, there are no doctests or other documentation in this package
that I can see. The interfaces and code give some hints, but given that I'm
not very familiar with things like RAMCache on Zope 2 anyway, I feel like
I'm missing something.

Any pointers?

Martin
-- 
View this message in context: 
http://www.nabble.com/zope.app.cache-tf3154169.html#a8746306
Sent from the Zope3 - users mailing list archive at Nabble.com.

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Simple buildout tutorial

[Martin Aspeli]

Alec Munro wrote:

Hi list,

I haven't really been keeping up with eggs or buildout, and I find
myself needing to install an egg in my Zope instance. Does buildout
facilitate this? If so, can someone point me at a tutorial/howto?


I think a more in-depth tutorial is still missing (I may write one, 
philipp said he may as well), but there's the pypi page 
(http://cheeseshop.python.org/pypi/zc.buildout) and internal documentation.


I found it quite useful to observe an existing buildout. For the 
Zope2/Plone buildout we have been working on, I wrote a README that may 
be instructive, see http://svn.plone.org/svn/plone/ploneout/trunk.


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] zc.buildout and unreleased eggs in svn

[Martin Aspeli]

Philipp von Weitershausen wrote:
> 
>> Does this example actually work?
> 
> No, it doesn't. The format is #egg=-. We use it currently 
> on the CheeseShop page for grok and grokproject. You can easy_install 
> these two even though there's no release. Setuptools will simply get 
> them from SVN from the URLs that have the "#egg=..." thing.
> 
> http://cheeseshop.python.org/pypi/grok
> http://cheeseshop.python.org/pypi/grokproject
> 

Sio are you doing this in grok's buildout? What does the syntax actually
look like?

Martin
-- 
View this message in context: 
http://www.nabble.com/zc.buildout-and-unreleased-eggs-in-svn-tf3130333.html#a8688282
Sent from the Zope3 - users mailing list archive at Nabble.com.

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: zc.buildout and unreleased eggs in svn

[Martin Aspeli]

Jim Fulton wrote:


Where is it under documented? :)


http://thread.gmane.org/gmane.comp.python.distutils.devel/4076 has some 
pointers. We could move this discussion to that list (didn't realise it 
had anything to do with zc.buildout, but then saw the thread where you 
asked if it was the place to discuss it...)



 > It *does* work

though (try it if you'd like).


I will when I make some time.


Well, it's not that exciting. It just checks it out into /tmp and builds 
it and install is.



I don't think that in this case it's actually getting it directly
from svn.  But I'm not sure.  If we were having this discussion
on the distutils-sig mailing this, Phillip Eby would have started
explaining it by now. :)


Okay, let me reply to the other thread there.

Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: zc.buildout and unreleased eggs in svn

[Martin Aspeli]

Jim Fulton wrote:

Martin Aspeli wrote:

Hi,


I'd rather discuss questions like this on the distutils-sig list.


Okay? Is that a Zope list or a python one? In Gmane?


easy_install lets me specify an egg from svn, e.g.:

 $ easy_install 
http://svn.plone.org/svn/collective/ZopeSkel/trunk#egg=ZopeSkel-dev


Hm, interesting.  I thought I had seen something like that, but I've
never been able to find documentation for it.  Do you know where this
is documented?  Does this example actually work?


Hanno did some digging and found it was under-documented. It *does* work 
though (try it if you'd like).


I have a zc.buildout recipie that specifies a number of eggs that should 
always be fetched from svn.


I wonder what that should mean.


Basically, that I want the eggs in my buildout to track svn. The way we 
do that now is that we use svn:externals to get them into src/ and then 
use them as 'develop' eggs. However, if I have a different project that 
wants to track Plone svn, I'd rather not have to check out the source 
code like that.



I agree that something like this would be useful.  I would like to
see the semantics spelled out.  For example, I agree that this should
lead to a develop egg.  What version should it have? Should that
be determined by the remote setup.py file?  Is the project you point
to required to have a setup.py file?  If so, then why specify a
project name after the #.


I don't know why the # is needed, this is just the way I've seen it 
spelled before.


I think the default semantic would be that the version would be ==dev 
i.e. current svn. I don't fully understand how this works though - I 
know I can do "easy_install PasteScript==dev" to get the current 
development version of PasteScript, but I don't know how easy_install 
actually finds that (I presume the cheeseshop tells it about 
PasteScript's svn location?)


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] zc.buildout and unreleased eggs in svn

[Martin Aspeli]

Hi,

easy_install lets me specify an egg from svn, e.g.:

 $ easy_install 
http://svn.plone.org/svn/collective/ZopeSkel/trunk#egg=ZopeSkel-dev


I have a zc.buildout recipie that specifies a number of eggs that should 
always be fetched from svn. These are not (yet) in the cheeseshop.


Is there some way of specifying such eggs, e.g.

[buildout]
parts = ...

eggs =
  http://svn.plone.org/svn/collective/ZopeSkel/trunk#egg=ZopeSkel-dev

Of course, that doesn't work :)

I suppose this is somewhat similar to develop-eggs, but (as far as I 
know) these have to be in the src/ directory, and can't be fetched from 
svn and kept up to date automatically. We currently do this with svn 
externals to fetch them into src/ but I'd like to be able to distribute 
a standalone buildout.cfg that could get these eggs.


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: interview for my diploma thesis about Zope 3 in education

[Martin Aspeli]

Benji York wrote:

David Johnson wrote:

Zope  was developed (as I understand and may be incorrect) by a
professor in Computer Science in order to explain web development and
instruction on application development.


You are indeed incorrect.  Correction left as an exercise for the reader. :)


It could be the reader of Philipp von Weitershausen's excellent book - 
see http://worldcookery.com. It contains a very nice and concise history 
of Zope, and will teach you Zope 3 too :)


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Checkout

[Martin Aspeli]

Philipp von Weitershausen wrote:

You don't need to create objects just for the sake of displaying a form. 


Ah, the beautiful world of Zope 3 (the CMF and Archetypes people are 
sorry for poisoning your minds)


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Empty ZCML file

[Martin Aspeli]

Michael Bernstein wrote:

As I experiment with Zope3 skins, I frequently have various
*-overrides.zcml files I am using to switch the default skin. I tried
today to comment out the only directive I had in one file (ie. like so:
 ), and this caused
an error.

So, it looks like Zope does not like content-free ZCML files. Bug or
Feature?

Having to move the file isn't a problem, exactly, but it is annoying.


You should always have the  ..  directive; you 
can comment out what's in-between.


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] Blog for Zope3

[Martin Aspeli]

Florian Lindner wrote:
> 
> Hello,
> is there a blog package for Zope3? It doesn't need to mature just usable
> would 
> be ok...
> 

grokblog is a demo app for grok, shipping with grok's buildout. I'm sure
it's not that mature yet, but it may be a great way to get into grok :)

Martin

-- 
View this message in context: 
http://www.nabble.com/Blog-for-Zope3-tf3010389.html#a8370456
Sent from the Zope3 - users mailing list archive at Nabble.com.

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: prettier edit widgets..

[Martin Aspeli]

Roy Mathew wrote:

Hi Folks,

I need prettier edit widgets than the stock Rotterdam/Basic skin
versions. Is there a collection of such widgets that maybe use
dojo/mochikit/scriptaculous. Or is it reasonable to simple re-style
(w/css) the stock widgets, or programmatically (in editform)
manipulate parameters, to get reasonable edit widgets.


Don't know if you consider Plone's standard widgets pretty, but the 
plone.app.form package[1] makes formlib widgets fit into Plone's 
standard layout, which may be similar to what you want.


That's not using JS libraries though; in general, it's a bad idea to 
*depend* on such JS libraries; rather they should be additional benefits 
for those with browsers that support it.


Incidentally, if you're feeling adventurous, you may want to check out 
KSS, which is the JS meta-framework Plone 3 will use (meta, because it 
can use prototype or mochikit or whatever; it's just a way of binding JS 
behaviour to the page using a CSS-like syntax, and writing server side 
logic in python). KSS has a plain-JS bit (called kukit) which does the 
binding and command handling and a plain-Zope 3 bit (for server side 
actions and resource management). Plone has its own bindings and 
Plone-specific actions of course, but there's nothing Plone- or 
Zope2-specific about the framework or common actions.


Cheers,
Martin

[1] http://svn.plone.org/svn/plone/plone.app.form/trunk/plone/app/form/

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] zc.buildout with Zope 2

[Martin Aspeli]

Jim Fulton wrote:
> 
>> This may not be the right place for this question, but I'm wondering if 
>> anyone has experience or examples using zc.buildout with Zope 2.
> 
> I don't.  I'm using the immediate predecessor of zc.buildout
> for zope Zope 2 projects though.
> 

Is this internal only?



> 
>> It seems a useful solution and one that will increase in importance, 
>> though so far I've not yet fully grasped what it does or how I use it in 
>> my brief encounters with it.
> 
> buildouts are about automating application assembly and installation.
> They are somewhat like make in that regard, although they tend to work
> at a higher level.  (In fact, our earlier buildouts were built using
> make.)
> 
> A secondary benefit of zc.buildout is that it provides tools for
> leveraging eggs in a much more controlled way that is allowed
> by easy_install.  This will be helpful to Zope 2 in the future
> especially as Zope 3 is split into eggs.
> 

Would it be helpful at the moment as well? Or are there too many rough edges
in terms of lacking egg-ification $SOFTWARE_HOMEs and $INSTANCE_HOMEs that
make it non-trivial to use this in Zope 2 projects?



> BTW, if you want to learn more about zc.buildout, then a good way would
> be to attend the minitutorial I'll be giving at PyCon nect month:
> 
>http://us.pycon.org/TX2007/TutorialsAM#AM7
> 

Bit far for me to travel, but good luck :)

Martin

-- 
View this message in context: 
http://www.nabble.com/zc.buildout-with-Zope-2-tf2962956.html#a8297926
Sent from the Zope3 - users mailing list archive at Nabble.com.

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] zc.buildout with Zope 2

[Martin Aspeli]

Hi guys,

This may not be the right place for this question, but I'm wondering if 
anyone has experience or examples using zc.buildout with Zope 2.


It seems a useful solution and one that will increase in importance, 
though so far I've not yet fully grasped what it does or how I use it in 
my brief encounters with it.


I'm wondering whether it is something I should pursue further in the 
context of Plone development (targeting primarily Zope 2.10 for now), 
but I don't know if it's even relevant to that platform or if this is 
unchartered territory.


Suggestions?

Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: 2nd edition of Zope 3 book available!

[Martin Aspeli]

Philipp von Weitershausen wrote:


- better.

  With the second edition, the book has been completely revamped. My
  excellent reviewers from the Zope and Plone community have done a
  tremendous good job at improving the book's language and technical
  details. I also improved the didactics in various places.


Having been given the honour of helping to review the book (and as an 
owner of the first edition), I can safely say Philipp is right - this 
book is a great improvement on the first book, which apart from some 
language snafus was also a great example of technical writing.


I'd highly recommend it, also to the Zope2/Five/Plone crowd that want to 
get a solid understanding of Zope 3 concepts.


Cheers,
Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: "So you've just downloaded Zope 3.3...."

[Martin Aspeli]

Philipp von Weitershausen wrote:


What happened to Tools? `zope.app.component.browser.tools`? I'm not
even sure what tools were,


We weren't either ;) so we got rid of them.


From the PSU Time Machine Black Box:

Philipp - Hey guys, what's this browser tool stuff?

Martijn - I don't know, isn't that something Tres invented?

Philipp - No, dude, this is in Zope 3

Martijn - Aha.

Philipp - Let's ask Jim. Jim?

Jim - Yeah?

Philipp - What is this browser.tool stuff?

Jim - We can probably get rid of that

Philipp - Okay, I'll refactor it out of zope.app, deprecate the ZML, 
simplify it using a base class, have some sushi, bike across China and 
write about it in my new book. It'll be great! :)


With apologies to Martijn and PSU.

Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Writing tests for views

[Martin Aspeli]

Philipp von Weitershausen wrote:


Consider buying my book: http://worldcookery.com


t'is great and will be greater still ;-)

Also consider reading the docs that are there. Zope 3 has lots of docs 
(see http://localhost:8080/++apidoc++ after enabling devmode). There are 
also a couple of tutorials available at http://worldcookery.com/Appetizers.


Definitely.

But also, well done George on taking this stuff seriously and being 
willing to learn. I think you can be forgiven asking questions when the 
body of documentation isn't quite as big as it probably should be, and 
when people moving from Z2 to Z3 development inevitably face a bit of 
new-concept-overload at first. Also, you're writing a test for a view. 
That kind of stuff should be commended ;-)


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Multiple actions per button in formlib forms?

[Martin Aspeli]

Stefan Fink wrote:


Error object: 'Action' object is not callable


I wonder if this has to do with the @form.action... decorator on 
handle_edit_acion? Try to take it off and/or replicate the code of the 
edit action itself.


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] Functional Tests

[Martin Aspeli]

Fabio Rizzo wrote:
> 
> Does anybody knows where i find any "tutorial" for zope.testbrowsers?
> 

See the last two pages of http://plone.org/documentation/tutorial/testing.
This is somewhat Plone/Five/Zope2 specific, but almost all of it should be
relevant to pure Zope 3 as well.

Martin

-- 
View this message in context: 
http://www.nabble.com/Functional-Tests-tf2186132.html#a6245831
Sent from the Zope3 - users forum at Nabble.com.

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Using ZCML for defining global constants ?

[Martin Aspeli]

Andrew Groom wrote:

Hi there,

I've got a few global constants that I'd like to be available to my 
application and a .zcml file seems to be a sensible place. I'm thinking 
of something like a .zcml file with, e.g.:





...


This would then be available in a component as a dictionary. Is anythign 
like this already available ?


You could just use , and thereby group your constants into 
logical chunks.


interfaces.py:

class IDatabaseLoginOptions(Interface):
username = Attribute()
password = Attribute()

config.py:

class DatabaseLoginOptions(object):
implements(IDatabaseLoginOptions)
username = 'foo'
password = 'bar'

configure.zcml:



used:

opts = getUtility(IDatabaseLoginOptions)

Obviously, this is a bit more work than just declaring some constants in 
ZCML, but global constants suffer the same problems whether they're 
defined in Python or XML. Parts of your application are making 
assumptions that they are there, with very specific names, which are not 
type checked.


With the solution outlined above, you can logically separate different 
types of options into different utilities, that may be provided in 
different ways. For example, your tests can just plug in a different 
utility using provideUtility(), no config file swapping to deal with. If 
you need some parts of your application to use different settings, you 
can provide a local utility, for example, and if you need to make this 
configurable by the user in the future, then a site-local (persistent) 
utility is the natural place to store it - it'll override the global 
registration.


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: nextUrl(), passing state in formlib

[Martin Aspeli]

Jürgen Kartnaller wrote:


I did it this way :

The Edit Form implementation :

class AddClub(zope.formlib.form.AddForm):

base_template =zope.formlib.form.AddForm.template
template = ViewPageTemplateFile('club_add.pt')

...


def referer(self):
returnself.request.form.get('referer')\
   or self.request.getHeader('HTTP_REFERER')

def nextURL(self):
return self.request.form.get('referer','..')


The template ('club_add.pt') :


  
   

  




Ah, excellent - thank you!

Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] nextUrl(), passing state in formlib

[Martin Aspeli]

Hi,

I have an add form (and later, an edit form) that may be invoked from a 
particular view among a few choices. That is, the user can be at @@foo 
or @@bar, click "add X" or "edit Y".


When the form is successfully submitted (i.e. validated) I want to send 
the user back to @@foo or @@bar depending on where they originally came 
from.


Add forms (and my custom edit handler for the edit form) have a 
nextUrl() method to work out what the next URL should be. However, I 
need to pass the state of which page I came from along the requests. 
Using HTTP_REFERER doesn't work, because when it comes to the save 
button handler, the referer is the add form I was just on.


One way would be to put a hidden field in the form that looked at the 
referer the first time it was rendered and then passed that state along 
subsequent requests. However, I really need a generalisable solution 
(there will be many of these add and edit forms for different objects). 
Having a custom pageform template for all of them (I can make them all 
use a custom base class) would be one option, but I'd rather avoid it if 
I could, since this'd need to repeat all the other code in the pageform 
that I'd rather not have to keep manually in sync when the original 
version changes or bugs are fixed.


Is there some other way of passing this kind of "where did I originally 
come from" information along?


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] How to make a new namespace for pagetemplates?

[Martin Aspeli]

FB-5 wrote:
> 
>> >my employer want to have all external links marked with a small icon
>> telling
>> >anonymous users from the internet that everything behind given links is
>> >beyond our responsibility.
>> 
>> Why not use a piece of javascript to do this? See the linkpopper
>> product on plone.org for a way to process all links in a page and
>> process them. That product makes external links open in a new window,
>> but the code should be easy to alter.
> 
> Thank you for the hint.
> 
> But there are several reasons for not using JS:
>* One of the constraints of that site is javascript being optional.
>  Problem ist: marked links are mandatory - they have to be marked
>  even with javascript turned off.
>* I'd like to have a tag-postprocessing namespace for some other
>  reasons, too - e.g. for a printing-view that automatically creates
>  a list of links at the end of the page.
>* I'd like to know, how to make a new pagetemplate namespace :-).
> 

It's fairly annoying to have to change every view that may or may not parse
links, though. Think also about the case when links are coming from HTML
(possibly transformed from some other format?) inside some content object
rendered via a view.

Look at zope.contentprovider, though. It sets up the provider: namespace.
It's fairly simple.

Martin
-- 
View this message in context: 
http://www.nabble.com/How-to-make-a-new-namespace-for-pagetemplates--tf2238315.html#a6207359
Sent from the Zope3 - users forum at Nabble.com.

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: crud/read example?

[Martin Aspeli]

Robert Hicks wrote:

I was just wondering...


... how to phrase your question and you couldn't decide?

Try to be a bit more specific, you'll get more answers that way.

Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Why Zope3

[Martin Aspeli]

Philipp von Weitershausen wrote:

Behrang Dadsetan wrote:

Hi Philipp,
 
Your reply made me discover the fact that http://svn.zope.org contains

so many third-party packages.
 
Is there any page that gives a minimal description to each of these

packages? Like an overview maybe even in the same format
than http://svn.zope.org  but instead of the last
comment checked-in, a two-liner describing the package?


Unfortunately not, but there are plans to build such a site. For now,
perhaps [1] can give you more pointers.


Zope 3 has a really good culture of low-level documentation, too. Each 
of these packages has a README.txt or similar .txt file that is a 
working (hopefully) DocTest and background documentation on how it is to 
be used.


To see the "big picture" of Zope 3, though, look at Philipp's website 
http://worldcookery.com, which has a few "Appetizers" to get you going. 
I can highly recommend his book as well.


Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: state of pure Zope 3 CMSs?

[Martin Aspeli]

Hi,


I wonder what is that state of pure Zope 3 CMSs? - Cubic and z3ecm
come to mind, see below.


Me too! :)


I am aware that sytems like *Plone* offer everything you can imagine
for serious CMS development. But being based on Zope 2 (and just
slowly moving towards Zope 3 by means of Five) they also carry a lot
of baggage with them:

* Say you want to develop a Plone product based on Zope 3 (Five): 
  You effectively have to master Zope 2, Plone and Zope 3.


To a certain extend that is true. It depends on what you're trying to 
do. Sometimes you can do things almost entirely in a Zope 3 style (at 
least going forward, we are doing this as much as we can for Plone 3 and 
later), other times Zope 3 doesn't make much sense, and other times 
again you have to straddle both platforms.


Better documentation on the patterns is forthcoming, as we figure out 
the details for ourselves.



* On my debian system (after installation of plone-site)
  du -h /var/lib/zope2.8/instance/plone-site/Products/
  gives me: 19M - that's a lot.


Yeah, there are a lot of files in there. Note that a bunch of them are 
from CMF, which offers functionality in some cases at the same 
conceptual level as what Zope 3 offers, and also a lot of that is 
images. It's fairly impossible to compare, though.



Many portals start out as some small projects and might not need all
the fancy stuff. Being small in code and therefore easily manageble
might be more important.


The main reason I develop on top of Plone is that it's already proven to 
support a whole bunch of use cases in the real world that I'd rather not 
have to implement myself. It's often easier to take bits away from Plone 
than to put bits on top of a lower level framework. Often it seems easy 
in the beginning, but the devils are in the details. That is why I'd 
love to see what's been going on with the pure Zope 3 CMS' that solve 
real-world use cases for real users. I'm sure we'd have a lot to learn 
from them as well.



Besides: if they where solely based on Zope
3, adding more stuff to them should be easier anyway (by means of
adapters e. g.).


Definitely.


Cubic and z3ecm come to my mind - are there more?


Tiks?

Martin

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Re: Checking if an interface is provided by an object or could be adapted to

[Martin Aspeli]

On Mon, 01 May 2006 00:55:46 +0100, Stephan Richter  
<[EMAIL PROTECTED]> wrote:



On Sunday 30 April 2006 19:34, Bernd Dorn wrote:

component.queryMultiAdapter((bar,baz), IFoo) is not None or False


Why not just:

component.queryMultiAdapter((bar,baz), IFoo, default=False)


Well, it seems that if I have:


class Foo(object):

.implements(IFoo)


context = Foo()
component.queryAdapter(foo, IFoo, default=None)

None

I assume it's the same with single adapters? As I said, I may well be  
doing something wrong, but that's what was happening to me (using Five,  
Zope 2.9.2). If it makes any difference, the interface in question (IFoo)  
was applied to the class Foo using  in ZCML (legacy/backwards  
compatability issue).


Martin

--
"You can just adapt yourself out of it..." // Archipelago sprint 26/04/2006

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Checking if an interface is provided by an object or could be adapted to

[Martin Aspeli]

On Sun, 30 Apr 2006 23:31:37 +0100, Bernd Dorn  
<[EMAIL PROTECTED]> wrote:



i would use

return IFoo(context, False) is not False or False


Aha, didn't know you could do that. Thanks :)

How do I do that for multi-adapters, though?

Martin

--
"You can just adapt yourself out of it..." // Archipelago sprint 26/04/2006

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Checking if an interface is provided by an object or could be adapted to

[Martin Aspeli]

Hi,

I'm probably doing something very wrong, but ...

I have a general interface that can either by directly provided by an  
object or class (typically with implements() on the class), but could also  
be provided via an adapter. I have a few places where I just need to check  
for this (it's not really a marker interface, but I need to know whether  
other code later on would be able to use the interface or not).


In my tests, I tried to use queryAdapter(), but that didn't return  
anything when the interface was implemented directly by the class.  
Similarly, Interface.providedBy() returns (expectedly) False if the  
interface could only be obtained via an adapter. Currently I do:


  try:
adapted = IFoo(context)
return True
except (ComponentLookupError, TypeError):
return False

but that's just silly... Is there a pattern for this?

Martin

--
"You can just adapt yourself out of it..." // Archipelago sprint 26/04/2006

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Re: Blobs in Z3 anyone?

[Martin Aspeli]

On Thu, 20 Apr 2006 04:35:47 +0100, Chris McDonough  
<[EMAIL PROTECTED]> wrote:


The zodb code is on the blob-merge-branch of ZODB in Zope's subversion  
repository.  I'm not sure when it's going to land in an actual ZODB  
release.  I'm fighting a bunch  of fires at the moment and it's on the  
backburner as a result. :-(


Is there a roadmap, to-do list or similar? Do you have an estimation of  
how complete it is at this stage?


Storage of large files is something that Plone and the other CMSs solve  
(to various degrees of success) at the wrong layer of the stack (although  
Railroad/Tramline/Hurry are really interesting). Development at the ZODB  
level scares me, but I'm sure there are people in various communities  
interested in getting this solved once and for all.


Martin

--
(muted)

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Zope 3 menus for Plone - design choices

[Martin Aspeli]

Hi guys,

I'm writing this PLIP: http://plone.org/products/plone/roadmap/142.

For those of you familiar with Plone, it relates to the global contentmenu  
- the green bar you see when you can edit an object in Plone, under the  
content views tabs. This contains a number of drop-down menus, including  
'state' (the workflow state), 'actions' (cut/copy/paste/rename) and 'add  
item'. At the moment, this menu is a very large, complex, monolithic page  
template with a lot of logic.


What I want to do is to use a view to construct the menu. However, I also  
want to make it easier to register new top-level menus, and to override  
the existing menus. Say, for example, that I install a versioning tool and  
this wants to register a 'versions' menu, or a staging tool with a 'stage'  
menu. Say also that in a particular folder, I wanted to override the  
'actions' menu to provide some very different actions.


If possible, I'd like to re-use the IBrowserMenu machinery in  
zope.app.publisher.browser. However, there are a few concerns with how  
this may work. I'm hoping someone with a bit more experience can point me  
at a design that will work.


 1. It must be possible to add new top-level drop-downs (i.e. a menu next  
to 'state' drop-down called 'versions', which has its own items).


 2. It must be possible to specify how these are ordered ('versions'  
always comes after 'state', but 'stages' comes before 'add item', for  
example).


 3. It must be possible for the existing menus to be constructed as they  
are now: the 'add item' menu uses the addable types as dictated by  
portal_types, the 'actions' menu queries portal_actions for actions, etc.


 4. It must be possible to override existing menus (e.g. I want to replace  
the 'add item' menu with my own)


 5. It must be possible to provide a given menu only for a given context  
(e.g. only when the context is marked with a given interface), or for all  
objects. Ideally this would be configurable, so that I could store a list  
of types that get the 'versions' menu (the versionable types) and the menu  
would be hidden for those types that are not on this list.


 6. If a given product provides a menu or overrides a menu, that menu  
shouldn't come into effect until the product is installed in the site - it  
must be possible to for one Plone instance in the Zope instance to get the  
menu and another to avoid it.


I took a look at the menus in zope.app.publisher.browser.menu and  
menumeta, including the doctest. I'm still a bit unclear how it all works,  
so I'd appreciate some specifics on whether this is possible, and if so  
how to design it.


I'm guessing we could register a new IMenuType 'contentmenu', that was a  
top-level menu, and then have each of the drop-downs be sub-menu-item.  
Some of those would have to construct their children by looking up actions  
etc, others may allow a more traditional registration. However, I'm still  
unclear on issues such as ordering (I think we need to allow menus to  
specfy a relative ordering, e.g. to say "I don't care where I am so long  
as I'm before the 'state' menu") since they may come from different  
sources.


I think we may need to use adapters to achieve the lookup only in some  
contexts, but it's possible this could be a condition on the sub-menu  
itself.


We may have to use local adapters/utilities to solve the installed-only  
issue. In fact, this is a problem we're going to have a lot CMF/Plone  
going forward, so some general patterns here would be useful.


Most of all, I hope we can solve this without re-inventing infrastructure.  
:)


Thanks!

Martin

--
(muted)

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: A Few Questions re Namespaces

[Martin Aspeli]

2. I finally found the "+" view in container/browser, but all
uses of it are as "/@@+/newitem.html".  I could have sworn
I saw the "+" used w/o the "@@" prefix someplace but can't
find it again.  Did I indeed imagine ever seeing
"/+/newitem.html"?


No, I've seen this too. As far as I understand, the @@ is optional, but  
useful to disambiguate views from other things. If you had an object in /  
called '+', /+ would find that, not the add view.



3. What happens if you register a utility or adapter with
the -exact- same criteria including the same name?  Does
a queryAdapter() lookup return the oldest or newest?
Is that a legitimate way of overriding, other than
using an overrides.zcml?


Did you try it?

Martin

--
(muted)

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] Re: Use Case for a Tree of Adapter Registries?

[Martin Aspeli]

On Fri, 14 Apr 2006 11:07:42 +0100, Jeff Rush  
<[EMAIL PROTECTED]> wrote:


I've read the code for adapter registries, how there is a global one and  
any number of local ones, arranged in a tree and that each can be  
disabled.


But I can't figure out when you'd want to make use of such an  
arrangement. The docstrings and .txt files use abstract examples, for  
unit testing, and don't provide a motivation for this feature.


Related to that, the global registry is loaded at server startup time  
from the various .zcml directives, and I presume that the only way to  
loaded up a local registry is thru-the-web, right?  Which means all  
local registries are persistent in the ZODB, I think.


Can anyone nudge me onto the right path?


I'm most definitely not the right person to make an authoritative  
statement on this, but something that we're struggling with in Plone's  
adoption of Zope 3 technologies is that CMF/Plone works on the principle  
that things aren't active until you've installed something in the site.  
For example, I may have two Plone sites in the same Zope instance. If I  
want to install a product that uses an adapter registration to override  
something in one site, but not the other, global adapter registrations  
don't work.


I can imagine this going further, so that for a specific content type I  
need a more specific override for that adapter that can't be tied to an  
interface only (e.g. in MyCrazyFolder the adapter for IDocument is  
different than it is for IDocument everywhere else).


Martin

--
(muted)

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

[Zope3-Users] zope.viewlet and zope.contentprovider - options for Zope 2 and Plone 3

[Martin Aspeli]

Hi guys (sorry for the crosspost, this is rather a cross-area post),

I'm reading the docs for zope.contentprovider and zope.viewlet, and there  
are many reasons why we'd like to use this in Plone. The way the release  
cycles work, Plone 3.0 would be the natural place to put some of this.  
Now, I have a few questions:


 - In what version of Zope 3 did zope.contentprovider and zope.viewlet  
appear? They're not in my Zope 2.9 lib/python/zope.


 - Are they scheduled to be in Zope 2.10?

The main achilles heel as far as I can tell is the TALES 'provider:'  
expression. I'm guessing that without using the Zope 3 ZPT and TALES  
implementations, Zope 2 won't be able to use these.


 - Is it the intention to use the Zope 3 ZPT and TALES engines in Zope  
2.10? If not, are they scheduled for some other time? How much work is  
needed for this to be a reality?


Now, I have a feeling that this could be faked in Zope 2 with something  
like:




the object 'provider' would have to be defined globally (in  
global_defines.pt in Plone). Its implementation would basically be  
identical to the TALESProviderExpression in zope.contentprovider, with a  
__call__() method that called update() and render() on an IContentProvider  
looked up by the name it was passed.


The tricky part is the ITALNamespaceData update magic that needs to read  
the TAL context:


 - Is there some way a python object referred in an expression like the  
one above could be passed or acquire (literally or figuratively) TAL  
objects defined in the current context at that point?


 - If not, based on your practical experience, how much is this used -  
would zope.contentprovider and zope.viewlet be useless if Plone had to say  
"we only support a subset of the zope.contentprovider API" (note: we  
really don't want to do that, I'm just looking at options here)


The other problem with this implementation is that it would call  
viewlets/content providers sequentially, i.e. call update(), then render()  
for each object as it discovered them, not call all the update()'s and  
then all the render()'s. I note that the zope.contentprovider README.txt  
mentions that this is bad, but the TALESProviderExpression implementation  
seems to suffer from exactly the same problem.


 - Is this expected behaviour? Is it considered as "known issue"? Are  
there plans to improve on this?


Thanks a lot!

Martin



--
(muted)

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users