date:20050830



On Aug 30, 2005, at 9:13 PM, Stuart Bishop wrote:


Gary Poster wrote:



2 Clean up the exceptions widget framework.  The use of the widget
input error is quite messy: see collector issue 273.  The idea  
would  be

to make the use of the errors argument more consistent and more
restricted, and make the 'doc' implementation simpler.


I've just had to wade through this recently. In particular, I had  
to resort
to ZCML overrides to get around the HTML quoting embedded in the  
guts of the

form validation error rendering - we need XHTML markup in our error
messages. If this is worked on it would be nice if this use case was
remembered ;) I suspect we want to use views on the exceptions so  
we can

easily provide HTML snippets or plain text string renderings.


OK, good feedback.  Thanks.

3 Make the arbitrary constraints in the schema framework more   
powerful:

specifically, allow a field to accept more than one  constraint, and
have the constraints raise errors (with an i18n doc,  if desired)  
rather
than return an uninformative Boolean.  This can be  done in a  
backwards
(and deprecation) compatible way by keeping the  constraint  
argument and

adding a constraints argument wit the new  semantics; or with another
approach. *would need small proposal*  *code exists*


Constraints can already raise ValidationError whose doc() method  
returns the

error message. Although this seems to be undocumented and may only be
working for us by accident...


Interesting point.  The interface doesn't seem to support this  
approach...


def constraint(value):
u"""Check a customized constraint on the value.

You can implement this method with your Field to
require a certain constraint.  This relaxes the need
to inherit/subclass a Field you to add a simple constraint.
Returns true if the given value is within the Field's  
constraint.

"""

...but that doesn't mean we can't bless it retroactively. :-)  That's  
definitely worth evaluating, as that would mean fewer changes.  I  
think I'd be fine with just expanding the contract a bit...



8 Add suggestion and MRU (Most Recently Used) widgets.  These widgets
provide a drop down of suggested (specifically most recently used for
the MRU widget) values for a choice field.  They really make using
choice widgets much nicer in many cases.  *code exists* *proposal
needed for also adding another of our packages to the core, on which
this relies*


You mention code exists - is it available anywhere? We were looking  
into
similar things but I'm not sure what the status is (I think we have  
some

suitable client side javascript, but I havn't seen it running yet).


We have not yet released this--it is in a package that needs some  
TLC, as I said at the beginning of the original note, and it relies  
on another piece that we are in the process of proposing.  If there  
is some time pressure for this, let us know, and we'll see if we can  
accelerate some of this enough for you all to at least evaluate from  
the sandbox.


Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-30 Thread Stuart Bishop

Gary Poster wrote:

> 2 Clean up the exceptions widget framework.  The use of the widget 
> input error is quite messy: see collector issue 273.  The idea would  be
> to make the use of the errors argument more consistent and more 
> restricted, and make the 'doc' implementation simpler.

I've just had to wade through this recently. In particular, I had to resort
to ZCML overrides to get around the HTML quoting embedded in the guts of the
form validation error rendering - we need XHTML markup in our error
messages. If this is worked on it would be nice if this use case was
remembered ;) I suspect we want to use views on the exceptions so we can
easily provide HTML snippets or plain text string renderings.

> 3 Make the arbitrary constraints in the schema framework more  powerful:
> specifically, allow a field to accept more than one  constraint, and
> have the constraints raise errors (with an i18n doc,  if desired) rather
> than return an uninformative Boolean.  This can be  done in a backwards
> (and deprecation) compatible way by keeping the  constraint argument and
> adding a constraints argument wit the new  semantics; or with another
> approach. *would need small proposal*  *code exists*

Constraints can already raise ValidationError whose doc() method returns the
error message. Although this seems to be undocumented and may only be
working for us by accident...

> 8 Add suggestion and MRU (Most Recently Used) widgets.  These widgets 
> provide a drop down of suggested (specifically most recently used for 
> the MRU widget) values for a choice field.  They really make using 
> choice widgets much nicer in many cases.  *code exists* *proposal 
> needed for also adding another of our packages to the core, on which 
> this relies*

You mention code exists - is it available anywhere? We were looking into
similar things but I'm not sure what the status is (I think we have some
suitable client side javascript, but I havn't seen it running yet).

-- 
Stuart Bishop <[EMAIL PROTECTED]>
http://www.stuartbishop.net/

signature.asc
Description: OpenPGP digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: RDFLib and Zope 3

2005-08-30 Thread Daniel Krech



On Aug 29, 2005, at 11:24 PM, Gary Poster wrote:



On Aug 26, 2005, at 3:03 AM, Daniel Krech wrote:


On Aug 25, 2005, at 3:10 PM, Michel Pelletier wrote:


On Thu, 2005-08-25 at 14:32 -0400, Gary Poster wrote:

see what he thinks.  I wonder how "lite" the component kernel  
can go.




The only thing I have in mind is the interface package, which is  
what

Twisted uses.  That's all we would need.  zope.component needs
zope.interface, zope.testing, and zope.exceptions, according to its
DEPENDENCIES.cfg.



Right.  Well in this case we would provide just a very simple  
interface

facade that had no effect when run in an environment with no
zope.interface (ie, catch the ImportError, null-out the facade)  
or hook
into zope.interface if it is available.  This way rdflib can be  
still be

used with or without zope.interface.



Sounds good.



OK, cool.


We've started a branch where we'll be depending on zope.interface and  
in the end may just choose to grow a dependency on zope.interface or  
provide some kind of fallback if possible. We're just going to  
concentrate on getting going with zope.interface for now.





In the mean time the adapters can live inside Zemantic, which  
is an

rdflib to zope bridge anyway.  Let me know if you want to send
patches,
otherwise I'll probably get around to adding functionality like  
this

soon.



I'm actually interested in trying to hook this up, but have very
limited time.  I might play with it just within RDFLib alone during
some hobby time tonight, but otherwise may  need to toss this  
off to

you if you'll catch it.

I also kind of want to hear Dan's reaction before I spend too  
much time.




#redfoot on freenode is a good place to catch him, and me.



Yep, feel free to stop by anytime.



OK, cool, I plan to again. :-)


I thought I read that an RDF triad was itself something that  
could be
a node in another RDF triad, but I can't find that anywhere  
now.  Can

you confirm or deny? :-)



Yes, it's called reification, making a statement about a statement.

http://www.w3.org/TR/rdf-primer/#reification

http://en.wikipedia.org/wiki/ 
Resource_Description_Framework#Statement_reification_and_context


http://www.w3.org/TR/rdf-mt/#Reif



Reification is probably best avoided. I'd recommend seeing if you  
can make use of a context or quoted graph instead.




I have read that 'context' actually is still a word looking for a  
firm definition in RDF, but I like the interpretation that it is  
the source of the assertion.  That's not a general answer for the  
sorts of things that reification can provide, though.


Correct, 'context' was not a term defined in the set of RDF  
specifications, but all the RDF toolkits end up implementing them  
because pretty much all applications need them for something or  
another. RDFLib's support for contexts does not constrain the  
interpretation of what a context represents... it only provides a way  
to identify a set of triples. The identifier can be either a URIRef  
or BNode and can be used to make assertion such as the source of the  
triples, creation date, or whatever assertions your application wants  
to make about the context.


The quoted graph does seem interesting: I said before that it seems  
very similar to reification, and it does, but I guess it subsumes  
the data structure that reification can provide...I also said that  
I wonder about efficient indexing, and I still do.


On the plus side for context, you've implemented it. ;-)


I hope to be implementing support for quoting soon... not sure of an  
ETA yet.


I'm interested in contemplating RDF as a full catalog solution for  
Zope, at least as a thought experiment.  The SPARQL work seems  
interesting, in regards to some of the recent discussion on the  
Zope 3 list; and the ability to seamlessly and simultaneously query  
both relationship information between objects and more traditional  
catalog data seems compelling.


It seems to me that allowing a back end to index particular  
relationships--and joins, particularly through blank nodes--would  
be a big step in letting RDF actually be a front end to a full  
catalog.  Another step would be having a front end that honored  
rdfs range and domain constraints.


I plan to get on IRC and bother you all again as soon as I have  
time to do so. :-)


Hope to see you soon,


Gary



Daniel Krech, http://eikeon.com/



___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/ Massive style cleanup: Move to new raise exception style; for motivation, see:

2005-08-30 Thread Stephan Richter

On Tuesday 30 August 2005 18:10, Benji York wrote:
> >  class StateNamesVocabulary(SimpleVocabulary):
> >      """Vocabulary providing the names of states in a local process
> > definition. """
> > @@ -61,7 +65,7 @@
> >              for obj in zapi.getParents(context):
> >                  if IStatefulProcessDefinition.providedBy(obj):
> >                      return obj.getStateNames()
> > -        raise 'NoLocalProcessDefinition', 'No local process definition
> > found.' +        raise NoLocalProcessDefinition('No local process
> > definition found.') 
>
> I'm not sure it's worth worrying about (and I definitely prefer the new
> version better), but these type conversions are not backward compatible.
>     Of course it's only a problem if anyone is trying to catch the
> string version of the exception.

This code has never been released as part of Zope 3.0 (but separately) is not 
in 3.1 and does not even work in the latter.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/ Massive style cleanup: Move to new raise exception style; for motivation, see:

2005-08-30 Thread Benji York


Martijn Pieters wrote:

Benji York wrote:

I'm not sure it's worth worrying about (and I definitely prefer the 
new version better), but these type conversions are not backward 
compatible.Of course it's only a problem if anyone is trying to 
catch the string version of the exception.



There were no references to these string exceptions anywhere in the 
Zope3 codebase, nor was the exception described in any interface. So I 
felt confident that any breakage I caused was self-inflicted by whomever 
was using this undocumented feature. ;)


That's good enough for me!  :)
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/ Massive style cleanup: Move to new raise exception style; for motivation, see:

2005-08-30 Thread Martijn Pieters


Benji York wrote:
I'm not sure it's worth worrying about (and I definitely prefer the new 
version better), but these type conversions are not backward compatible. 
   Of course it's only a problem if anyone is trying to catch the string 
version of the exception.


There were no references to these string exceptions anywhere in the 
Zope3 codebase, nor was the exception described in any interface. So I 
felt confident that any breakage I caused was self-inflicted by whomever 
was using this undocumented feature. ;)


Martijn Pieters


signature.asc
Description: OpenPGP digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/ Massive style cleanup: Move to new raise exception style; for motivation, see:

2005-08-30 Thread Benji York


Martijn Pieters wrote:

Log message for revision 38178:
  Massive style cleanup: Move to new raise exception style; for motivation, see:



Modified: Zope3/trunk/src/zope/app/workflow/stateful/definition.py
===
--- Zope3/trunk/src/zope/app/workflow/stateful/definition.py2005-08-30 
21:36:02 UTC (rev 38177)
+++ Zope3/trunk/src/zope/app/workflow/stateful/definition.py2005-08-30 
21:50:19 UTC (rev 38178)
@@ -46,6 +46,10 @@
 implements(IStatefulStatesContainer)
 
 
+class NoLocalProcessDefinition(Exception):

+"""No local process definition found"""
+
+

 class StateNamesVocabulary(SimpleVocabulary):
 """Vocabulary providing the names of states in a local process definition.
 """
@@ -61,7 +65,7 @@
 for obj in zapi.getParents(context):
 if IStatefulProcessDefinition.providedBy(obj):
 return obj.getStateNames()
-raise 'NoLocalProcessDefinition', 'No local process definition found.'
+raise NoLocalProcessDefinition('No local process definition found.')
 


I'm not sure it's worth worrying about (and I definitely prefer the new 
version better), but these type conversions are not backward compatible. 
   Of course it's only a problem if anyone is trying to catch the 
string version of the exception.

--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] catalog 'all documents' abstraction


Gary Poster wrote:


On Aug 30, 2005, at 1:57 PM, Martijn Faassen wrote:



...

It should be pointed out initially that the son-of-queued-catalog  code 
doesn't have anything to do with extents.  I think Jim wants  that 
factored out when we have time so that can be a mix-and-match  
capability. 


Yup. That was a mistake (not a hack ;).  It should be done through
composition. Extents could be provided through composition too, I think.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] catalog 'all documents' abstraction


Jim Fulton wrote:

Martijn Faassen wrote:


...

It would be helpful if someone could explain the motivations behind 
the extent catalog, by the way -- this information seems to be missing 
in zc.catalog. Am I at all on the right track with my thinking on it?



What information?


Never mind. I missread what you said.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] catalog 'all documents' abstraction

Martijn Faassen wrote:

Jim Fulton wrote:

Martijn Faassen wrote:

...
In general, I'd like the catalog to remain fairly small and free of 
logic.

I wanted to say this in the other thread you started on cataloging, but
didn't get to it.  Ideally, a catalog wouldn't have any query logic
at all.  People should be able to invovate on query algorithms without
affecting catalogs.

This is already clear;

Cool. Just making sure. :)

> I've been trying to do so in the project I'm
working on, though I'm more focusing on a sensible query language (well, 
of Python objects) than performance algorithms.

Cool.  I really wish someone would pick up on Aaron Waters Gadfly 2 work.
I strongly suspect that there are some interesting bits to mine there.

At the same time I believe Zope 3 *does* need query systems built in 
eventually. While it's fine to allow people to design their own query 
languages and algorithms, not everybody is able to do this, and those 
who are able to don't always want to.

Agreed.

> Even if they did, I don't want us

to end up with 5 different query systems either.

Hm. I wouldn't mind a bit of they addressed different needs.

So, while I agree that a query language in the core should not exclude 
someone from building something better, I do believe a catalog query 
language package is needed in the core.

I agree that a good query mechanism should be in the core, but it should be
a separate component. It should not be in the catalog.

(To be absolutely clear: I also think the RDF avenues being explored are 
very interesting, and I don't want to imply that this is not an 
interesting direction, but I do think we need something for the plain 
catalog too)

Yup

Hm, perhaps this isn't ideal either, as this would get hairy in case 
of a query that spans multiple catalogs -- which catalog will be 
asked in that case for a list of all documents? 

I think in the particular case of "not", you have to have an implicit or
explicit set that you are subtracting something from.  The "right" set is
application specific.  In any case, I think the query logic should be
in separate query components.

I agree that the catalog should remain nice and simple.

That said, catalogs right now already have an implicit concept of 
'everything indexed', which for instance is already used for 
re-indexing, it's just not made available to someone who wants to build 
something on it.

Wel, it has a concept of of everything that could be indexed.
It generally won't index everything in the intids.

The extent catalog makes this more explicit by defining an extent, so 
perhaps this is the way to go.

I suspect so.

> The extent could be a query parameter to
help the query engine figure out what to do in case of 'not'. For simple 
use cases, the extent can be constructed from the intid utility, perhaps.

It would be helpful if someone could explain the motivations behind the 
extent catalog, by the way -- this information seems to be missing in 
zc.catalog. Am I at all on the right track with my thinking on it?

What information?

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: AttributeError: 'NoneType' object has no attribute '_implied'

2005-08-30 Thread Alec Munro

Ar!
Apparently, the problem was that the __getattr__ method in my adapter
didn't raise an AttributeError if it failed. I do know better, but I
really didn't expect it to manifest like this.

Thanks for reading, and perhaps I can save someone else the day of debugging.

Alec

On 8/30/05, Alec Munro <[EMAIL PROTECTED]> wrote:
> This seems to be a regression, as I believe this was working with the beta.
> I don't have it pinned down entirely, but it seems to be related to an
> Annotation adapter I am using. The error occurs in
> zope.interface.interface, at the following location:
> 
> 
> def providedBy(self, ob):
> 
> .
> 
> spec = providedBy(ob)
> return self in spec._implied
> 
> Printing spec gives:
>  from 
> /usr/local/Zope-3.1.0c2/lib/python/zope/app/exception/browser/systemerror.pt>
> 
> Also, dir(spec) includes '_implied', so I really don't know what's going on.
> 
> It isn't likely to be important, but I have commented out the import
> of the C optimized version of this method, so I could attempt to debug
> it. The error changed when I did this (it was AttributeError:
> 'NoneType' object has no attribute isOrExtends), but I assume that was
> simply because the C code was cloaking the error.
> 
> I've attempted to track this down myself, but I really had no luck. I
> think I'll do some trial and error editing of my Annotations adapter,
> and see if that effects it.
> 
> Thanks,
> 
> Alec Munro
>
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] AttributeError: 'NoneType' object has no attribute '_implied'

2005-08-30 Thread Alec Munro

This seems to be a regression, as I believe this was working with the beta.
I don't have it pinned down entirely, but it seems to be related to an
Annotation adapter I am using. The error occurs in
zope.interface.interface, at the following location:


def providedBy(self, ob):

.

spec = providedBy(ob)
return self in spec._implied

Printing spec gives:


Also, dir(spec) includes '_implied', so I really don't know what's going on.

It isn't likely to be important, but I have commented out the import
of the C optimized version of this method, so I could attempt to debug
it. The error changed when I did this (it was AttributeError:
'NoneType' object has no attribute isOrExtends), but I assume that was
simply because the C code was cloaking the error.

I've attempted to track this down myself, but I really had no luck. I
think I'll do some trial and error editing of my Annotations adapter,
and see if that effects it.

Thanks,

Alec Munro
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] catalog 'all documents' abstraction



On Aug 30, 2005, at 1:57 PM, Martijn Faassen wrote:


Jim Fulton wrote:


Martijn Faassen wrote:


[snip]



 > ). I also think however that it's the wrong

place the ask for this information, as this doesn't work with the  
extentcatalog.


 Well, it depends on what you meant by "indexed" above.  Different  
indexes
index different objects.  The extent catalog tried to define an  
extent for

which it makes sense to apply different (not) operations.



And is the idea that multiple extent catalogs can share an extent?


They could.  We haven't needed that yet.

(By the way you say 'the extent catalog tried', does this mean  
something else is being considered now?)


Not to my knowledge, and I just asked Jim, and he said there was no  
special significance to the past tense.  :-)


The catalog itself seems like the wrong place to ask as well  
however, as things would get hairy in the case of a query over  
multiple catalogs -- which catalog would be asked for all ids  
that are indexed?


In general, I'd like the catalog to remain fairly small and free  
of logic.
I wanted to say this in the other thread you started on  
cataloging, but

didn't get to it.  Ideally, a catalog wouldn't have any query logic
at all.  People should be able to invovate on query algorithms  
without

affecting catalogs.



This is already clear; I've been trying to do so in the project I'm  
working on, though I'm more focusing on a sensible query language  
(well, of Python objects) than performance algorithms.


At the same time I believe Zope 3 *does* need query systems built  
in eventually. While it's fine to allow people to design their own  
query languages and algorithms, not everybody is able to do this,  
and those who are able to don't always want to. Even if they did, I  
don't want us to end up with 5 different query systems either.


So, while I agree that a query language in the core should not  
exclude someone from building something better, I do believe a  
catalog query language package is needed in the core.


(To be absolutely clear: I also think the RDF avenues being  
explored are very interesting, and I don't want to imply that this  
is not an interesting direction, but I do think we need something  
for the plain catalog too)


This all makes sense to me, btw (as is probably clear by my RDF  
messages).  Query language arguments have been persuasive to me.   
That said, I still don't find the lack of a query language to be an  
impediment.  It's a nice-to-have for me and arguably an essential-to- 
have to support a larger audience.


Hm, perhaps this isn't ideal either, as this would get hairy in  
case of a query that spans multiple catalogs -- which catalog  
will be asked in that case for a list of all documents?


I think in the particular case of "not", you have to have an  
implicit or
explicit set that you are subtracting something from.  The "right"  
set is

application specific.  In any case, I think the query logic should be
in separate query components.


I agree that the catalog should remain nice and simple.

That said, catalogs right now already have an implicit concept of  
'everything indexed', which for instance is already used for re- 
indexing, it's just not made available to someone who wants to  
build something on it.


The extent catalog makes this more explicit by defining an extent,  
so perhaps this is the way to go. The extent could be a query  
parameter to help the query engine figure out what to do in case of  
'not'. For simple use cases, the extent can be constructed from the  
intid utility, perhaps.


It would be helpful if someone could explain the motivations behind  
the extent catalog, by the way -- this information seems to be  
missing in zc.catalog. Am I at all on the right track with my  
thinking on it?


It should be pointed out initially that the son-of-queued-catalog  
code doesn't have anything to do with extents.  I think Jim wants  
that factored out when we have time so that can be a mix-and-match  
capability.  I think you are asking about extents themselves, though.


We had three use cases that led us to extents.

First, we wanted several catalogs that only indexed certain different  
things.  This could have been done by subscribers, so this wasn't  
terribly compelling by itself.


Second, we wanted to transparently support queries that merged  
results across catalog-like data structures.  The catalog defined the  
items we wanted to search through, while some of the other data  
structures kept track of a larger set of objects (subsuming the set  
that the catalog cared about).  Sometimes, users could perform a  
query that didn't actually use any of the catalog's data structures,  
but that should be filtered by the set of the catalog's objects--its  
extent.


Third, we wanted to let our indexes data be usable for NOT queries.   
In order to do that, we needed an IFBTree structure that describes  
the complete set for a given catalog, so tha

Re: [Zope3-dev] catalog 'all documents' abstraction

2005-08-30 Thread Martijn Faassen


Jim Fulton wrote:

Martijn Faassen wrote:

[snip]


 > ). I also think however that it's the wrong

place the ask for this information, as this doesn't work with the 
extentcatalog.
 
Well, it depends on what you meant by "indexed" above.  Different indexes

index different objects.  The extent catalog tried to define an extent for
which it makes sense to apply different (not) operations.


And is the idea that multiple extent catalogs can share an extent?

(By the way you say 'the extent catalog tried', does this mean something 
else is being considered now?)


The catalog itself seems like the wrong place to ask as well however, 
as things would get hairy in the case of a query over multiple 
catalogs -- which catalog would be asked for all ids that are indexed?


In general, I'd like the catalog to remain fairly small and free of logic.
I wanted to say this in the other thread you started on cataloging, but
didn't get to it.  Ideally, a catalog wouldn't have any query logic
at all.  People should be able to invovate on query algorithms without
affecting catalogs.


This is already clear; I've been trying to do so in the project I'm 
working on, though I'm more focusing on a sensible query language (well, 
of Python objects) than performance algorithms.


At the same time I believe Zope 3 *does* need query systems built in 
eventually. While it's fine to allow people to design their own query 
languages and algorithms, not everybody is able to do this, and those 
who are able to don't always want to. Even if they did, I don't want us 
to end up with 5 different query systems either.


So, while I agree that a query language in the core should not exclude 
someone from building something better, I do believe a catalog query 
language package is needed in the core.


(To be absolutely clear: I also think the RDF avenues being explored are 
very interesting, and I don't want to imply that this is not an 
interesting direction, but I do think we need something for the plain 
catalog too)


Hm, perhaps this isn't ideal either, as this would get hairy in case 
of a query that spans multiple catalogs -- which catalog will be asked 
in that case for a list of all documents? 


I think in the particular case of "not", you have to have an implicit or
explicit set that you are subtracting something from.  The "right" set is
application specific.  In any case, I think the query logic should be
in separate query components.


I agree that the catalog should remain nice and simple.

That said, catalogs right now already have an implicit concept of 
'everything indexed', which for instance is already used for 
re-indexing, it's just not made available to someone who wants to build 
something on it.


The extent catalog makes this more explicit by defining an extent, so 
perhaps this is the way to go. The extent could be a query parameter to 
help the query engine figure out what to do in case of 'not'. For simple 
use cases, the extent can be constructed from the intid utility, perhaps.


It would be helpful if someone could explain the motivations behind the 
extent catalog, by the way -- this information seems to be missing in 
zc.catalog. Am I at all on the right track with my thinking on it?


Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives

Jim Fulton wrote:

> Jean-Marc Orliaguet wrote:
>
>> Jim Fulton wrote:
>>
>>
>> - this portlet uses this widget
>
>
> I'm confused. In the doctest you pointed out:
>
> https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt
>
>
> the portlet and widget are wired up by hand, not by lookup AFAICT.
>

sorry this is a doctest that does not take into account relations. It
only describes the way in which elements are rendered, i.e. moving from
content -> view, from data to HTML.

>> - this portlet uses this style
>>
>> not for a *class* of portlets, but for *instances* of classes. Adapters
>> connect interfaces, not instances.
>
>
> Then why not just store the style in the portlet?
>
Again you are making the assumption that a portlet *has* a style. If the
portlet is rendered in RSS it has no style ...

Also this is as bad as storing browser view related attributes in a
content class - otherwise we are back to the Zope2 old days, where every
possible attribute was stored on the objects themselves.

Then OK: if you store the style attribute on the portlet itself, I
suppose that this information will be indexed and cataloged. In what way
is it different from having a separate relation store that does not
duplicate information?

Honestly, Zope3 makes some sort of schizofrenic separation between
content and view, in a way that you sometimes cannot get access to the
request object because you haven't adapted (context, request).

the Zope3 philosophy has to be coherent: if you create a waterproof
separation between components, then having a waterproof separation
between content elements, i.e. portlets / widgets / styles / layout /
visibility options / caching parameters is just as important.

>
>> to sum up: for exactly the same reason as why Zope2 moved to a
>> component-based architecture, but for the content this time. I want to
>> be able to connect content objects (portlets, styles, widgets, layouts)
>> in a flexible way.
>>
>> and by the way it works, so why explain why you need something when it
>> works as expected?
>
>
> Because to decide if I want to use it, I need to evaluate the
> architecture:
>
> - I need to know if there are hidden costs that aren't apparent in
>   demos and small scale.
>
>   Your solution requires a potentially large centralized indexing
> structure.
>   I don't like large centralized indexing structures.  They are necessary
>   sometimes, but I don't want to use them if I can avoid it.
>
I don't know about yours, but I guess that you will store all the
information in the portal catalog? what is the difference?


> - Your system defines a framework that I'll need to understand if
>   we want to use it.  I need to understand if developers will find it
>   easy to use
>
the number one target audience is end-users, and application developers.
The Zope2 version is already appealing to both users and developers. At
the university we can't afford to create a product that only developers
understand. Content creators, graphic designers don't think as
developers, they see things differently and this is what I'm trying to
integrate into cpsskins, i.e. *their* knowledge.


>
 if other combinations of filters are used (a RSS filter for instance),
 the same data is displayed in RSS instead of HTML.
>>>
>>>
>>>
>>> Why would you want to generate RSS in a portlet?
>>
>>
>> the portlet data is used for syndication in RSS / ATOM too in a RSS
>> rendering engine (the [RSS] orange button).
>
>
> Is this a case where you are using a portlet as an application
> component outside the context of a page?
>

yes, of course, content is often syndicated. Creating a syndication
adapter that gathers data, extract data and renders it in RSS when you
only need to create a filter and add /++engine++rss/ in the url is worth
a lot.

>>>
>>> - We define layout types.  These extend something like ISubPage (as
>>> defined in
>>>  formlib).  Alternatively, we use named adapters.
>>>
>>
>> what is a layout type?
>
>
> The thing you specify with the widget keyword argument to the Widget
> contructor in the doctest you sent.
>
OK, this is not really important, this is only used by the vocabulary
items to not propose a "box layout" to a user when it makes no sense to
apply a "box layout" to an element. This is just a way of categorizing
widgets / layouts.

>>> - We adapt the applets with the request to the layout type:
>>>
>>> view = component.queryMultiAdapter((applet, request),
>>> IDropDownList)
>>>
>>>  or, with named adapters:
>>>
>>> view = component.queryMultiAdapter((applet, request), ISubPage,
>>> 'dropdown_list')
>>>
>>> Would something like this work for you?
>>>
>>> Jim
>>>
>>
>>
>> I don't think so, because the relation portlet <-> widget <-> layout
>> gets hardcoded in python.
>
>
> In the example you asked me to look at, the portlet<->widget relation
> seemed to be hardcoded in Python.
>
> In any case, adapter definitions are not hardcoded in Python.

Re: [Zope3-dev] catalog 'all documents' abstraction


Martijn Faassen wrote:

Hi there,

Now that there's a plain catalog and an extent catalog, and while I was 
implementing a 'not' operator for a query language, I ran into some 
missing abstraction that would be convienient; a way to get all the 
object ids that are indexed,


For some definition of indexed. :)

preferably in the form of a IFBTree so I 
can do fast intersections and the like (which are needed for "not", 
which is an intersection of all object ids with those object ids I don't 
want).


Right now this information is not really available in a standard or a 
very efficient manner. For the normal catalog you can ask the IIntId 
utility for all int ids, which is reasonable and should be fairly 
efficient, though it'd be nice to have something come out in IFBTree 
form (or perhaps the intid's IOBTree can be intersected with an IFBTree 
directly? that'd be nice..


Yup.  This is a wart in the current BTree implementation. You can't do
merging operations across BTree types. We've been able to get around
in the past, because we didn't support operations accross catalogs.
Now, however, this is getting to be more of a problem.

> ). I also think however that it's the wrong
place the ask for this information, as this doesn't work with the 
extentcatalog.


Well, it depends on what you meant by "indexed" above.  Different indexes
index different objects.  The extent catalog tried to define an extent for
which it makes sense to apply different (not) operations.

The catalog itself seems like the wrong place to ask as well however, as 
things would get hairy in the case of a query over multiple catalogs -- 
which catalog would be asked for all ids that are indexed?


In general, I'd like the catalog to remain fairly small and free of logic.
I wanted to say this in the other thread you started on cataloging, but
didn't get to it.  Ideally, a catalog wouldn't have any query logic
at all.  People should be able to invovate on query algorithms without
affecting catalogs.

Hm, perhaps this isn't ideal either, as this would get hairy in case of 
a query that spans multiple catalogs -- which catalog will be asked in 
that case for a list of all documents?


I think in the particular case of "not", you have to have an implicit or
explicit set that you are subtracting something from.  The "right" set is
application specific.  In any case, I think the query logic should be
in separate query components.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] "make check" errors on FreeBSD 5.4

2005-08-30 Thread Velko Ivanov


File "", line 1, in connect
error: (49, "Can't assign requested address")


Seeing this error in a connect() call is unusual. I'd check the security 
configuration of the box for the source of this - something is 
preventing the connecting side from getting an appropriate address to 
use to connect from, which in this case should be localhost:, 
where port is something >1000.

It could be a limit set to the user, or a MAC policy for example.
It is possible also that the server side is unable to bind to 
localhost: too - do you see any exceptions with the same error, 
but from a bind() call ? If that turns to be the case, then I'd ask - 
did you by any chance forgot to enable your lo0 interface in rc.conf ? 
It happened to me once.


> So, did anyone compiled zope3 successfully on subj?

Yes, I'm runing a test Zope3 server on my FreeBSD 5.4 workstation since 
the X3 release and I have installed all releases since then, and their 
tests are working for me each time.



Regards,
Velko Ivanov
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives

Jean-Marc Orliaguet wrote:

Jim Fulton wrote:

Jean-Marc Orliaguet wrote:

this is more a design feature than an implementation feature.

Could you explain *why* you need relations?

yes, because adapters provide flexible relations between *components*
(interfaces, classes), but not between *content* objects. I want to be
able to say (or the user)

- this portlet uses this widget

I'm confused. In the doctest you pointed out:

https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt

the portlet and widget are wired up by hand, not by lookup AFAICT.

- this portlet uses this style

not for a *class* of portlets, but for *instances* of classes. Adapters
connect interfaces, not instances.

Then why not just store the style in the portlet?

to sum up: for exactly the same reason as why Zope2 moved to a
component-based architecture, but for the content this time. I want to
be able to connect content objects (portlets, styles, widgets, layouts)
in a flexible way.

and by the way it works, so why explain why you need something when it
works as expected?

Because to decide if I want to use it, I need to evaluate the architecture:

- I need to know if there are hidden costs that aren't apparent in
demos and small scale.

Your solution requires a potentially large centralized indexing structure.
I don't like large centralized indexing structures. They are necessary
sometimes, but I don't want to use them if I can avoid it.

- Your system defines a framework that I'll need to understand if
we want to use it. I need to understand if developers will find it
easy to use

if other combinations of filters are used (a RSS filter for instance),
the same data is displayed in RSS instead of HTML.

Why would you want to generate RSS in a portlet?

the portlet data is used for syndication in RSS / ATOM too in a RSS
rendering engine (the [RSS] orange button).

Is this a case where you are using a portlet as an application
component outside the context of a page?

...

I guess the widget filter somehow decides how to generate HTML based
on the widget and data. Similarly, it somehow chooses a style.
It's unclear how this is working.

the widget knows nothing about the style that is going to be applied
afterwards. The portlet <-> style connection is a relation defined in
the relation store.

Can you say why you chose this division of labor?

it is one example of a chain of filters that covers most of the use
cases to create HTML pages.

Since the engine definition is defined in a zcml file it can be changed
easily. I could go into the details of the design, but since it works as
expected ...

I agree that, given a model where portlets only generate data, "pagelett"
is not a good name. Perhaps "applet" would be a better name.

IMO, the choice of the term "widget" is unfortunate, both because it
clashes
with the Zope 3 use of the term and because it clashes with common
usage in
GUIS, where widgets are responsible for UI generation, whereas here,
AFAICT,
widgets are responsible for UI specification in some fashion.

Here's an alternate suggestion that follows Zope 3 style a bit more:

- We have applets that provide application functionality. These are
like your portlets.

- We define layout types. These extend something like ISubPage (as
defined in
formlib). Alternatively, we use named adapters.

what is a layout type?

The thing you specify with the widget keyword argument to the Widget
contructor in the doctest you sent.

- We adapt the applets with the request to the layout type:

view = component.queryMultiAdapter((applet, request), IDropDownList)

or, with named adapters:

view = component.queryMultiAdapter((applet, request), ISubPage,
'dropdown_list')

Would something like this work for you?

Jim

I don't think so, because the relation portlet <-> widget <-> layout
gets hardcoded in python.

In the example you asked me to look at, the portlet<->widget relation
seemed to be hardcoded in Python.

In any case, adapter definitions are not hardcoded in Python.

> I would mean that I would have to rewrite the

AJAX theme editor.

the difference with the rendering architecture that I have implemented
is that new rendering engines can be created by reusing components.

I think that your approach is not generic enough, it is too much tied
with the webpage generation paradigm (it assumes that a portlet has a
layout, or a style...) which are web-related concepts.

I see your point about not wanting to store a web style with a portlet
instance. I need to think about this.

Jim

--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-

[Zope3-dev] catalog 'all documents' abstraction

2005-08-30 Thread Martijn Faassen


Hi there,

Now that there's a plain catalog and an extent catalog, and while I was 
implementing a 'not' operator for a query language, I ran into some 
missing abstraction that would be convienient; a way to get all the 
object ids that are indexed, preferably in the form of a IFBTree so I 
can do fast intersections and the like (which are needed for "not", 
which is an intersection of all object ids with those object ids I don't 
want).


Right now this information is not really available in a standard or a 
very efficient manner. For the normal catalog you can ask the IIntId 
utility for all int ids, which is reasonable and should be fairly 
efficient, though it'd be nice to have something come out in IFBTree 
form (or perhaps the intid's IOBTree can be intersected with an IFBTree 
directly? that'd be nice..). I also think however that it's the wrong 
place the ask for this information, as this doesn't work with the 
extentcatalog.


The catalog itself seems like the wrong place to ask as well however, as 
things would get hairy in the case of a query over multiple catalogs -- 
which catalog would be asked for all ids that are indexed?


Hm, perhaps this isn't ideal either, as this would get hairy in case of 
a query that spans multiple catalogs -- which catalog will be asked in 
that case for a list of all documents?


(note that 'not equals' on a FieldIndex can be implemented more 
efficiently as in this case the index itself can be used as the list of 
'all documents')


Does anybody have ideas on what the best way to go here would be?

Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] how-to fool XML-RPC publisher

2005-08-30 Thread Adam Groszer

Dear All,

Is there any way to fool the Z3 XML-RPC publisher to unmarshall
strings *always* as unicode? I think the problem is that xmlrpclib
tries to convert all strings to str, but in Z3, all strings should be
stored as unicode. Even better that zope.schema enforces unicode also.
So my exposed methods would start with converting all necessary
parameters to unicode.


-- 
Best regards,
 Adam  mailto:[EMAIL PROTECTED]
--
Quote of the day:
"Nothing is permanent except change."

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)



On Aug 30, 2005, at 11:31 AM, Jim Fulton wrote:


Gary Poster wrote:

On Aug 29, 2005, at 4:50 PM, Jim Fulton wrote:

Gary Poster wrote:
...
4 Recognize and document that the 'default' field argument is
actually 'initial value'.

...


I'm uncomfortable with this.

...
Initial value is a concept in XMLSchema (http://www.w3.org/TR/  
xmlschema-1/#key-iv).  The qoute is in W3C-speak, but I'm pretty  
sure  they are talking about what we are talking about.  I think  
it does  belong in a statement about a logical schema.


I can't figure what they are saying. I mean i really have no clue.
I asked my pointy-bracket consultant, but he couldn't make sense of
it either, although he didn't think it had anything to do with that
we were using the term for. :)


Heh, ok.


Here's what we say about default in the schema package's README.txt:

  "Default field values are assigned to objects when they are
   first created."

This is a statement either:

- about the past history of an object, or

- about some tool used to create an object.

I don't really see that this is of value in a schema.  A schema
constrains object values, bit default isn't about object values,
it's about something that happened in the past.  There's no way to
evaluate, for example, whether an object satisfies this aspect of
it's schema.

Furthermore, we rarely, if ever, use a default definition in a
schema to constrain how an object is created. For example, I doubt
this often effects how __init__ methods are defined. Rather, we use
it to initialize forms.  We then create the object with whatever data
we get from an add form.  IOW, we don't really use it is an initial
value to create the object.

I suggest that the default should become a field in a formlib form- 
field

definition, and should be deprecated from schema field.


Hm.  I'm not the one to quote computer science definitions, but I  
don't think the concept of schema is constrained to 'constraints'.  A  
schema is a data model.  The initial value of a given instance of the  
model, whether it be used for object creation or any other kind of  
model instantiation (e.g., collecting the data for a search form) is  
not unreasonably part of a data model.  I agree it is not a  
constraint, but I'm not sure that's pertinent.


That said, as we discussed verbally yesterday, a "purity" perspective  
suggests we are moving towards a more explicit three-layer cake for  
schema fields: interface, relationship, and form field.  If that  
perspective wins out, then yes, I agree that it fits better on the  
form field.


Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: RDFLib and Zope 3

2005-08-30 Thread Michel Pelletier

On Mon, 2005-08-29 at 23:24 -0400, Gary Poster wrote:

> >> Right.  Well in this case we would provide just a very simple  
> >> interface
> >> facade that had no effect when run in an environment with no
> >> zope.interface (ie, catch the ImportError, null-out the facade) or  
> >> hook
> >> into zope.interface if it is available.  This way rdflib can be  
> >> still be
> >> used with or without zope.interface.
> >
> > Sounds good.
> 
> OK, cool.

Stub interfaces (from Zemantic) are now checked into the rdflib trunk.
Dan and I also had a discussion on what changed to the lib would be made
if we actually depended on zope.interface.  Definately the plugin
framework would go, but there were some other unanswered questions we
had.

> > Yep, feel free to stop by anytime.
> 
> OK, cool, I plan to again. :-)

Please do, we need some help sketching out what kinds of changes would
be required moving over to a component model.

> I'm interested in contemplating RDF as a full catalog solution for  
> Zope, at least as a thought experiment.  The SPARQL work seems  
> interesting, in regards to some of the recent discussion on the Zope  
> 3 list; and the ability to seamlessly and simultaneously query both  
> relationship information between objects and more traditional catalog  
> data seems compelling.

And I think SPARQL is up to the task to query a catalog for the most
part, there might be some holes in the language that don't suite the
catalog exactly (text index querying, for example, is out of spec), but
for field and keyword indexes SPARQL would make a great query language,
one would just need to teach the catalog to assign well know predicates
to index names, possibly via adaptation.  For example, I think the
following queries and many like it are easily possible against a
catalog:

PREFIX  dc: 
SELECT  ?title
WHERE
{ ?book dc:title ?title }

Note that the use of bound variables also removes the need for brains.
Given that SPARQL also has CONSTRUCT (to build a graph of results) and
DESCRIBE (generate results describe one or more resources) clauses, I
think it makes a better object query language than OQL.

Note that the sparql support needs help!  We have query logic and half a
parser, the parser needs completion and to be glued to the logic.

> 
> It seems to me that allowing a back end to index particular  
> relationships--and joins, particularly through blank nodes--would be  
> a big step in letting RDF actually be a front end to a full catalog.   
> Another step would be having a front end that honored rdfs range and  
> domain constraints.
> 
> I plan to get on IRC and bother you all again as soon as I have time  
> to do so. :-)

Sure, there are some notes from me on the z3lab site that might be of
interest for thinking about zemantic and catalog integration.  THis may
be completely the wrong direction, bust most of my experiments so far
have been to keep a strong separation between how zemantic stores
searchable data (without interpretation) and how the catalog stores it
(with interpretation).  

For example, rdflib doesn't interpret a dc:modification_data value as a
date at all.  It's just one element in a graph that rdflib stores, not
interprets.  We (meaning Dan and I, as we've discussed this) want to
keep as strong barrier as possible between a Graph and its
interpretation, ie, we don't want to encapsulate or imply any
interpretation on any graphs, and if we do, we want to make sure that
interpretation is pluggable and that a graph can be transposed between
interpretations easily.  Interpreting dc:modification_date as a date
certainly does make sense, but its an assumption we can't make globally,
although I'm not against sensible defaults.

The catalog, on the other hand, makes these assumptions by design.  It
knows dc:modification_date is a date because the user instructs that
value to go into a date range searchable index.  This is not bad, it's
good, I think that rdflib and a catalog can leverage the distinction
between uninterpreted and interpreted data.

So far most of my thoughts have been that content (or whatever)
describes itself as RDF.  This is stored in a Graph with no
interpretation, the rdflib object only holds the "shape" of the graph.
Events get fired that make decisions on how that graph should be
interpreted, and the data is then cataloged.  I see a one to many
relationship possible, one interpreting catalog can derive its
interpretations on many graphs, and one graph can have many interpreting
catalogs, all queriable via SPARQL.

-Michel

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)


Gary Poster wrote:


On Aug 29, 2005, at 4:50 PM, Jim Fulton wrote:


Gary Poster wrote:
...

4 Recognize and document that the 'default' field argument is   
actually 'initial value'.  That is, if you set a field with a  
default  to the missing_value, the default does not become the  
field's value:  the 'default' value is only used if the value has  
never been set  (i.e., during creation or when there is no  previous 
state of the  value).  Possibly rename to  'initial_value' (with 
deprecation  support).  *would need proposal*
5 Allow fields to accept a default (or initial_value, as above)  
*or*  a default_getter (or initial_value_getter, as above).   
default_getter/ initial_value_getter would be a callable passed  the 
field's context.   It should return the desired initial  value.  Use 
cases include  initializing to now, today, the current  user, etc.  
*would need small  proposal* *code exists*




I'm uncomfortable with this. Right now, I think fields do too much.
They have too much application logic.  This would add more.  The whole
concept of "initial value" seems to be very application dependent.
Maybe it would be best to just drop the default field altogether
and introduce adapters for computing initial values in those special
cases when we need them.



Initial value is a concept in XMLSchema (http://www.w3.org/TR/ 
xmlschema-1/#key-iv).  The qoute is in W3C-speak, but I'm pretty sure  
they are talking about what we are talking about.  I think it does  
belong in a statement about a logical schema.


I can't figure what they are saying. I mean i really have no clue.
I asked my pointy-bracket consultant, but he couldn't make sense of
it either, although he didn't think it had anything to do with that
we were using the term for. :)

Here's what we say about default in the schema package's README.txt:

  "Default field values are assigned to objects when they are
   first created."

This is a statement either:

- about the past history of an object, or

- about some tool used to create an object.

I don't really see that this is of value in a schema.  A schema
constrains object values, bit default isn't about object values,
it's about something that happened in the past.  There's no way to
evaluate, for example, whether an object satisfies this aspect of
it's schema.

Furthermore, we rarely, if ever, use a default definition in a
schema to constrain how an object is created. For example, I doubt
this often effects how __init__ methods are defined. Rather, we use
it to initialize forms.  We then create the object with whatever data
we get from an add form.  IOW, we don't really use it is an initial
value to create the object.

I suggest that the default should become a field in a formlib form-field
definition, and should be deprecated from schema field.

Moreover, I regard any lookup code as an intellectual cost for  
developers: a cost both for making and for finding the associated  
configuration.  For schemas, being able to look in one place is very  
valuable, at least to me.  APIDoc can help, but is not a panacea.  I  
don't think this particular configuration division would be a win.


Agreed, but I think we are mixing concerns. Default is not a property
of the specification, but of a form definition.

I think dropping the functionality of default would be a loss for  
reasonable schema functionality.  I think renaming it to initial or  
initial_value would be a win for accurate names.  I'm willing to drop  
the getter: it is kind of ugly, I admit.


You ok with just changing the name?


I'd really prefer to move it to form field, and change the name.


...


7 add combination field and widget to schema and form,  
respectively.   A combination field allows a user to fill in  
multiple values  simultaneously, and returns a tuple of the  combined 
values.  Use  cases overlap somewhat with object field/ widget, but 
this is simpler  to use for simple use cases.  Use  cases include 
range fields.  *would  need small proposal* *code  exists*



I have an open mind, but I'm a bit skeptical (as you know :).  I  expect
this proposal to be a bit controversal.  Perhaps we can plan to go  
another

round of brainstorming during the sprint.



OK--I must admit that I have a bit of the "hack" willies about it  too.  
:-)  It's useful, though, and I haven't been convinced by any  
alternatives yet.  This one's off the table for the sprint then,  except 
perhaps for discussion.


For the record, here are the use cases that the Combination field  fills 
now:


- range
- main value plus modifier(s): find something supervised by X (a  
person), directly or indirectly (a Bool); and select something for  
publication (an object), in a given context (local, global, whatever).


I know you don't like the first one, and I do ATM :-).  The second  one 
makes me more suspicious, though.  A combination field can  fulfill it, 
but we have had a real use case, or at least desire, for  a list widget 
of this sort

Re: [Zope3-dev] Re: Bug in i18n timezones (was Re: [Zope3-Users] obtaining time zone from http request)



On Aug 30, 2005, at 8:39 AM, Stephan Richter wrote:


On Monday 29 August 2005 22:38, Stuart Bishop wrote:

I'm happy to expose this through pytz. There is a new set of data  
files
released yesterday (including the 2006 changes the US has just  
signed into

law) so I can push out a new release in the next day or two with this
added.



Fantastic!


I agree--sounds great, Stuart.  Thank you!

If you get the pytz changes in, I'll try to get the i18n locale  
changes, unless Stephan is available.


Stephan - Should this update go into the 3.1 branch, or just the  
trunk?


Let's do this only in the trunk. I really would prefer not changing  
RC 2

anymore, so I can make it the final version.


Makes sense to me.

If we do a 3.1.1, it would be arguable to put it in there, I think.   
I don't feel strongly about it atm, but reserve the right to feel  
strongly about it later. :-)


Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] "make check" errors on FreeBSD 5.4

2005-08-30 Thread Vetlugin Yury

Hi everyone,
I have a problem during installing Zope3.1/Zope3X on my FreeBSD 5.4 
(python2.3.5, gcc 3.4.2).

./configure and "make" goes normal, but "make check" gives a lot of errors 
like this:

>Error in test checkBadMessage2 
(ZEO.tests.testConnection.MappingStorageConnectionTests)
>Traceback (most recent call last):
>  File 
"/usr/home/bmc/zope/Zope-3.1.0c2/build/lib.freebsd-5.4-RELEASE-i386-2.3/ZEO/tests/ConnectionTests.py",
 
line 103, in setUp
>self.startServer()
>  File 
"/usr/home/bmc/zope/Zope-3.1.0c2/build/lib.freebsd-5.4-RELEASE-i386-2.3/ZEO/tests/ConnectionTests.py",
 
line 202, in startServer
>zeoport, adminaddr, pid, path = forker.start_zeo_server(
>  File 
"/usr/home/bmc/zope/Zope-3.1.0c2/build/lib.freebsd-5.4-RELEASE-i386-2.3/ZEO/tests/forker.py",
 
line 149, in start_zeo_server
>s.connect(adminaddr)
>  File "", line 1, in connect
>error: (49, "Can't assign requested address")

It seems like error in ZEO test module. As far as i understand test.py gives 
no additional parameters, while zeoserver.py expect -C and -k (line 154-159 
in zeoserver.py):

># We don't do much sanity checking of the arguments, since if we get it
># wrong, it's a bug in the test suite.
>keep = 0
>configfile = None
># Parse the arguments and let getopt.error percolate
>opts, args = getopt.getopt(sys.argv[1:], 'kC:')



So, did anyone compiled zope3 successfully on subj?

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives

Jim Fulton wrote:

> Jean-Marc Orliaguet wrote:
>
>>
>> this is more a design feature than an implementation feature.
>
>
> Could you explain *why* you need relations?
>
>

yes, because adapters provide flexible relations between *components*
(interfaces, classes), but not between *content* objects. I want to be
able to say (or the user)

- this portlet uses this widget
- this portlet uses this style

not for a *class* of portlets, but for *instances* of classes. Adapters
connect interfaces, not instances.

to sum up: for exactly the same reason as why Zope2 moved to a
component-based architecture, but for the content this time. I want to
be able to connect content objects (portlets, styles, widgets, layouts)
in a flexible way.

and by the way it works, so why explain why you need something when it
works as expected?

>>
 yes, I re-read
 http://mail.zope.org/pipermail/zope3-dev/2004-December/012852.html and
 while going through the different definitions I saw that not two
 implementations are done in the same way, which is fine.

 The important aspect is that "portlets" or  "pagelets" as they are
 implemented in cpsskins separate model and view.
 They implement the "data model" part only,  not the view itself, which
 is done later by widget, layout and style filters inside the rendering
 engine.
>>>
>>>
>>>
>>> I'd like to understand how this works.
>>>
>>> Jim
>>
>>
>>
>>
>> A portlet / pagelet generates some data (a list of menu items, for
>> instance) as a data structure in python.
>>
>> - the data goes through a widget filter that convert the data into HTML.
>> Depending on what widget is being used, the same data is displayed
>> differently (vertical list, horizontal list, drop-down list...).
>>
>> - a style filters add the style information (class="..."),
>>
>> the portlet can then be displayed in HTML
>>
>> if other combinations of filters are used (a RSS filter for instance),
>> the same data is displayed in RSS instead of HTML.
>
>
> Why would you want to generate RSS in a portlet?


the portlet data is used for syndication in RSS / ATOM too in a RSS
rendering engine (the [RSS] orange button).

if the portlet already renders HTML, there is no way to convert HTML to RSS.

>
>> which is shown on the following diagram:
>> https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.png
>>
>>
>> and documented here:
>> https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt
>>
>
>
> So
>
> - You get a widget of a particular type.
>
> - You adapt the widget (with a request) to get a widget filter.
>
> - You call the portlet to get some data.
>
> - You call the widget filter with the data to get HTML markup.
>
this is just one example of a rendering engine (the HTML rendering engine)

> I guess the widget filter somehow decides how to generate HTML based
> on the widget and data. Similarly, it somehow chooses a style.
> It's unclear how this is working.
>
the widget knows nothing about the style that is going to be applied
afterwards. The portlet <-> style connection is a relation defined in
the relation store.

> Can you say why you chose this division of labor?
>
it is one example of a chain of filters that covers most of the use
cases to create HTML pages.

Since the engine definition is defined in a zcml file it can  be changed
easily. I could go into the details of the design, but since it works as
expected ...

> I agree that, given a model where portlets only generate data, "pagelett"
> is not a good name. Perhaps "applet" would be a better name.
>
> IMO, the choice of the term "widget" is unfortunate, both because it
> clashes
> with the Zope 3 use of the term and because it clashes with common
> usage in
> GUIS, where widgets are responsible for UI generation, whereas here,
> AFAICT,
> widgets are responsible for UI specification in some fashion.
>
> Here's an alternate suggestion that follows Zope 3 style a bit more:
>
> - We have applets that provide application functionality.  These are
>   like your portlets.
>
> - We define layout types.  These extend something like ISubPage (as
> defined in
>   formlib).  Alternatively, we use named adapters.
>
what is a layout type?


> - We adapt the applets with the request to the layout type:
>
>  view = component.queryMultiAdapter((applet, request), IDropDownList)
>
>   or, with named adapters:
>
>  view = component.queryMultiAdapter((applet, request), ISubPage,
> 'dropdown_list')
>
> Would something like this work for you?
>
> Jim
>

I don't think so, because the relation portlet <-> widget <-> layout
gets hardcoded in python. I would mean that I would have to rewrite the
AJAX theme editor.

the difference with the rendering architecture that I have implemented
is that new rendering engines can be created by reusing components.

I think that your approach is not generic enough, it is too much tied
with the webpage gene

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)



On Aug 30, 2005, at 10:56 AM, Fred Drake wrote:


On 8/30/05, Gary Poster <[EMAIL PROTECTED]> wrote:


Adam, I'm sorry, I don't know much about the CustomWidgetFactory.  We
are using the zope.formlib package exclusively now (http://
svn.zope.org/zope.formlib/), which does not use custom widget
factories or .  Dominik's email sounds promising.



Actually, I have used the two together, using the custom_widget
attribute of form fields.  It's not necessarily a good fit, though,
especially from Python code, since CustomWidgetFactory requires that
you specify the concrete widget factory (it can't simply modify
whatever gets looked up without real help).   does
support that case.


OK, if you understand the problem, then maybe we can look at that a  
bit at the sprint, as Adam suggested.


Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-30 Thread Fred Drake

On 8/30/05, Gary Poster <[EMAIL PROTECTED]> wrote:
> Adam, I'm sorry, I don't know much about the CustomWidgetFactory.  We
> are using the zope.formlib package exclusively now (http://
> svn.zope.org/zope.formlib/), which does not use custom widget
> factories or .  Dominik's email sounds promising.

Actually, I have used the two together, using the custom_widget
attribute of form fields.  It's not necessarily a good fit, though,
especially from Python code, since CustomWidgetFactory requires that
you specify the concrete widget factory (it can't simply modify
whatever gets looked up without real help).   does
support that case.

  -Fred

-- 
Fred L. Drake, Jr.
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re[2]: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-30 Thread Adam Groszer

Dear Gary,

I'm sorry, as I read you are looking for proposals for the sprint.
In fact the problem is, that when I try to add

where an OrderedMultiSelectWidget is the default for the szerepek
field, Z3 fails with an exception. I mean when I do not add the above
line, it is working and an OrderedMultiSelectWidget is displayed.
I thought that would be something to look at.

Of course I'll check Dominik's solution.
I'm testing my stuff against the trunk. I do not really know how the
release is built but if Stephan's branch gets into it, or the problem
is not present in the release just don't care about my mail.

Tuesday, August 30, 2005, 4:21:40 PM, you wrote:

> On Aug 30, 2005, at 2:43 AM, Adam Groszer wrote:

>> Dear Gary and Stephan,
>>
>>
>>
>>   Would you please have a look at my messages with the subject
>>
>>   "[Zope3-dev] problems with "
>>
>>   I'm also having problems with CustomWidgetFactory, but in an other
>>
>>   usecase.

> Adam, I'm sorry, I don't know much about the CustomWidgetFactory. We
> are using the zope.formlib package exclusively now (http://
> svn.zope.org/zope.formlib/), which does not use custom widget
> factories or .  Dominik's email sounds promising.

> Gary

-- 
Best regards,
 Adammailto:[EMAIL PROTECTED]
--
Quote of the day:
A pig is a jolly companion.

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives

Jean-Marc Orliaguet wrote:

Jim Fulton wrote:

Jean-Marc Orliaguet wrote:

Jim Fulton wrote:

Jean-Marc Orliaguet wrote:

basically if the "slot" that you're thinking about contains portlets
then it's a sort of slot not a sort of portlet.

Cool. So we can define new slot-like things (for example,
for JSR 168-style slots) and use your slots or not, as we wish.

In particular, we can use CPS skins without being forced to
install triad registries unless we want to use your slots.

In that case it is possible to plug in other relation store backends
(e.g RDF) that do not support genuine triadic predicates, which means
that only "local folder" types of slots will be available, but some
relation storage is required for the dyadic relations between elements
and styles, widgets... because the relations between the elements are
not stored on the elements themselves.

Sigh. Is this documented anywhere?

Currently the application adds relations into the relation store using a
relation tool, there is not definite documented interface though, since
not all the use cases are defined yet:
https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/relations/tool.py

The idea is to allow any relation store back-end (RDF, SQL, ..) to be
plugged in.

If the relation information was stored in the elements themselves (e.g.
annotations, attributes, ...) this would make it very difficult to move
the storage from the ZODB.

this is more a design feature than an implementation feature.

Could you explain *why* you need relations?

yes, I re-read
http://mail.zope.org/pipermail/zope3-dev/2004-December/012852.html and
while going through the different definitions I saw that not two
implementations are done in the same way, which is fine.

The important aspect is that "portlets" or "pagelets" as they are
implemented in cpsskins separate model and view.
They implement the "data model" part only, not the view itself, which
is done later by widget, layout and style filters inside the rendering
engine.

I'd like to understand how this works.

Jim

A portlet / pagelet generates some data (a list of menu items, for
instance) as a data structure in python.

- the data goes through a widget filter that convert the data into HTML.
Depending on what widget is being used, the same data is displayed
differently (vertical list, horizontal list, drop-down list...).

- a style filters add the style information (class="..."),

the portlet can then be displayed in HTML

if other combinations of filters are used (a RSS filter for instance),
the same data is displayed in RSS instead of HTML.

Why would you want to generate RSS in a portlet?

which is shown on the following diagram:
https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.png

and documented here:
https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt

- You get a widget of a particular type.

- You adapt the widget (with a request) to get a widget filter.

- You call the portlet to get some data.

- You call the widget filter with the data to get HTML markup.

I guess the widget filter somehow decides how to generate HTML based
on the widget and data. Similarly, it somehow chooses a style.
It's unclear how this is working.

Can you say why you chose this division of labor?

I agree that, given a model where portlets only generate data, "pagelett"
is not a good name. Perhaps "applet" would be a better name.

IMO, the choice of the term "widget" is unfortunate, both because it clashes
with the Zope 3 use of the term and because it clashes with common usage in
GUIS, where widgets are responsible for UI generation, whereas here, AFAICT,
widgets are responsible for UI specification in some fashion.

Here's an alternate suggestion that follows Zope 3 style a bit more:

- We have applets that provide application functionality. These are
like your portlets.

- We define layout types. These extend something like ISubPage (as defined in
formlib). Alternatively, we use named adapters.

- We adapt the applets with the request to the layout type:

view = component.queryMultiAdapter((applet, request), IDropDownList)

or, with named adapters:

view = component.queryMultiAdapter((applet, request), ISubPage,
'dropdown_list')

Would something like this work for you?

Jim

[Zope3-dev] Re: [DRAFT] local portlets and perspectives


Raphael Ritz schrieb:

Tonico Strasser wrote:


[..]

If yes, I mean something different. I think I would love a Python 
wrapper for Page Templates that can assemble *macros* from different 
templates provide them with names and render the main template only 
once. (Wait, that is already possible, isn't it?)



Maybe I didn't get your question but isn't that exactly what Archetypes
does to render widgets?


Didn't look into Archetypes, let's see.



Example (from: http://docs.neuroinf.de/programming-plone/ate#2-18)




That looks interesting, the 'widget' returns a macro?


where 'widget' is defined in BaseObject
(https://svn.plone.org/svn/archetypes/Archetypes/trunk/BaseObject.py)

   security.declareProtected(CMFCorePermissions.View, 'widget')
   def widget(self, field_name, mode="view", field=None, **kwargs):
   if field is None:
   field = self.Schema()[field_name]
   widget = field.widget
   return renderer.render(field_name, mode, widget, self, field=field,
  **kwargs)


Hm, the term render implies something rendered, not a macro definition.

That way you can render a field's value for a given object wherever you 
like.


If I understand that correctly I get a unrendered macro?


For this example the macro(s) come(s) from the template configured on
the widget but it shouldn't be too hard to generalize that if needed.

But my gutt feeling says I missinterpret your question ...


That is related to what I want.

I've already built my own Z2 Python scripts to do the following:

##

# a template
main_template = context.main_template

# a page object that will render the main_template
page = context.Page(template=main_template)

# a macro provider
view = context.document_view

# a macro mapping which I can update with various macros
page.macros.update(view.macros)

# assign random names to the namespace
page.foo = 'bar'

# render the page
return page.render()

##

This is my Page object:
...
##parameters=template, **kw
##
from Products.PythonScripts.standard import Object

page = Object()
page.request = container.REQUEST
page.response = page.request.RESPONSE
page.template = template
page.macros = template.macros.copy()
page.update_macros = page.macros.update
page.update(kw)

def render(*args, **options):
options['args'] = args
page.options = options
page.here = context
page.context = context
return page.template.pt_render(extra_context=page)

page.render = render

return page

##

Very primitive, I know :)

Tonico

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)



On Aug 30, 2005, at 2:43 AM, Adam Groszer wrote:


Dear Gary and Stephan,



  Would you please have a look at my messages with the subject

  "[Zope3-dev] problems with "

  I'm also having problems with CustomWidgetFactory, but in an other

  usecase.


Adam, I'm sorry, I don't know much about the CustomWidgetFactory.  We  
are using the zope.formlib package exclusively now (http:// 
svn.zope.org/zope.formlib/), which does not use custom widget  
factories or .  Dominik's email sounds promising.


Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] zc.catalog doctest failures



On Aug 30, 2005, at 9:14 AM, Benji York wrote:


Martijn Faassen wrote:

There appear to be some doctest failures in zc.catalog as  
retrieved from the sandbox yesterday:




I believe these are caused by not having the stemmer installed.   
I'm not sure where the stemmer is available.  I'll ask Gary to  
follow up when he gets in.


No, these tests are not failing for us.  The stemmer needs to have  
either TextIndexNG installed, or just the TextIndexNG stemmer.  We  
have a package of just the stemmer for our own code.  One of my many  
personal "todo"s is to talk with Andreas about options for releasing  
the stemmer individually sometime.  He did that at one point a couple  
of years back.


Anyway, yeah, just install TextIndexNG.

I don't know why the globber would be failing, and again, the tests  
aren't failing for us, but I plan to remove that bit anyway.  It was  
a hack from before I realized I could leverage the TextIndexNG  
stemmer.  We are not using the globber.


We've fixed the deprecation warning in the extent catalog, but that's  
the only change we have internally for zc.catalog of which I'm aware.


Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives

Jim Fulton wrote:

> Jean-Marc Orliaguet wrote:
>
>> Jim Fulton wrote:
>>
>>
>>> Jean-Marc Orliaguet wrote:
>>>
>>>

 basically if the "slot" that you're thinking about contains portlets
 then it's a sort of slot not a sort of portlet.
>>>
>>>
>>>
>>> Cool. So we can define new slot-like things (for example,
>>> for JSR 168-style slots) and use your slots or not, as we wish.
>>>
>>> In particular, we can use CPS skins without being forced to
>>> install triad registries unless we want to use your slots.
>>>
>>
>>
>> In that case it is possible to plug in other relation store backends
>> (e.g RDF) that do not support genuine triadic predicates, which means
>> that only "local folder" types of slots will be available, but some
>> relation storage is required for the dyadic relations between elements
>> and styles, widgets... because the relations between the elements are
>> not stored on the elements themselves.
>
>
> Sigh.  Is this documented anywhere?


Currently the application adds relations into the relation store using a
relation tool, there is not definite documented interface though, since
not all the use cases are defined yet:
https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/relations/tool.py

The idea is to allow any relation store back-end (RDF, SQL, ..) to be
plugged in.

If the relation information was stored in the elements themselves (e.g.
annotations, attributes, ...) this would make it very difficult to move
the storage from the ZODB.

this is more a design feature than an implementation feature.

>>
>> yes, I re-read
>> http://mail.zope.org/pipermail/zope3-dev/2004-December/012852.html and
>> while going through the different definitions I saw that not two
>> implementations are done in the same way, which is fine.
>>
>> The important aspect is that "portlets" or  "pagelets" as they are
>> implemented in cpsskins separate model and view.
>> They implement the "data model" part only,  not the view itself, which
>> is done later by widget, layout and style filters inside the rendering
>> engine.
>
>
> I'd like to understand how this works.
>
> Jim


A portlet / pagelet generates some data (a list of menu items, for
instance) as a data structure in python.

- the data goes through a widget filter that convert the data into HTML.
Depending on what widget is being used, the same data is displayed
differently (vertical list, horizontal list, drop-down list...).

- a style filters add the style information (class="..."),

the portlet can then be displayed in HTML

if other combinations of filters are used (a RSS filter for instance),
the same data is displayed in RSS instead of HTML.

which is shown on the following diagram:
https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.png

and documented here:
https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt

/JM

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)


Garrett Smith wrote:

I'm uncomfortable with this. Right now, I think fields do too much.
They have too much application logic.  This would add more.  The whole
concept of "initial value" seems to be very application dependent.
Maybe it would be best to just drop the default field altogether
and introduce adapters for computing initial values in those special
cases when we need them.



Funnily, I just faced this dilema earlier today. I nearly created an interface 
like this:

  class IInitialValue(Interface):
  """An interface for obtaining an initial value for an object."""

  def get():
  """Returns the initial value."""

IMO, this is superior to field.initial. E.g.

  zapi.getMultiAdapter((field, context), IInitialValue).get()

Perhaps this pattern could be used for getting an ISource from a field. E.g.

  zapi.getMultiAdapter((field, context), ISource)


I think that sources are different than initial value.  I really don't
see any role that "initial value" has in an object specification.

A schema is a specification for an object that provides the schema.
An initial value doesn't constrain or specify the object.  If anything,
it constrains applications that create the object, but in a rather unclear
way.

Sources, OTOH, are about the specification of a value. A source defines the
set from which a choice is made.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives


Jean-Marc Orliaguet wrote:

Jim Fulton wrote:



Jean-Marc Orliaguet wrote:




basically if the "slot" that you're thinking about contains portlets
then it's a sort of slot not a sort of portlet.



Cool. So we can define new slot-like things (for example,
for JSR 168-style slots) and use your slots or not, as we wish.

In particular, we can use CPS skins without being forced to
install triad registries unless we want to use your slots.




In that case it is possible to plug in other relation store backends
(e.g RDF) that do not support genuine triadic predicates, which means
that only "local folder" types of slots will be available, but some
relation storage is required for the dyadic relations between elements
and styles, widgets... because the relations between the elements are
not stored on the elements themselves.


Sigh.  Is this documented anywhere?




- Use of the term "portlet" here leads to confusion with JSR 168
portlets, which are different.   I would prefer to see a different
term used for what CPS calls portlets. Absent that, we'll need to
find some modifiers to disambiguate.

Jim




yes, any term, "boxes" are not OK, since they refer to the portlet's
display (view) with the frame and the decorations but any term that is
understood by users / developers is ok.



Cool. "Pagelets"?

Jim



yes, I re-read
http://mail.zope.org/pipermail/zope3-dev/2004-December/012852.html and
while going through the different definitions I saw that not two
implementations are done in the same way, which is fine.

The important aspect is that "portlets" or  "pagelets" as they are
implemented in cpsskins separate model and view.
They implement the "data model" part only,  not the view itself, which
is done later by widget, layout and style filters inside the rendering
engine.


I'd like to understand how this works.

Jim
--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] zc.catalog doctest failures

2005-08-30 Thread Benji York


Martijn Faassen wrote:
There appear to be some doctest failures in zc.catalog as retrieved from 
the sandbox yesterday:


I believe these are caused by not having the stemmer installed.  I'm not 
sure where the stemmer is available.  I'll ask Gary to follow up when he 
gets in.

--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] zc.catalog doctest failures

2005-08-30 Thread Martijn Faassen


Hi there,

There appear to be some doctest failures in zc.catalog as retrieved from 
the sandbox yesterday:


File ".../lib/python/zc/catalog/globber.txt", line 11, in globber.txt
Failed example:
globber.glob('foo bar and baz or (b?ng not boo)', lex)
Expected:
'(((foo* and bar*) and baz*) or (b?ng and not boo*))'
Got nothing

File ".../lib/python/zc/catalog/stemmer.txt", line 32, in stemmer.txt
Failed example:
list(ix.apply('consoling a constable'))
Expected:
[0]
Got:
[]

File ".../lib/python/zc/catalog/stemmer.txt", line 34, in stemmer.txt
Failed example:
list(ix.apply('knightly kneel'))
Expected:
[1]
Got:
[]


File ".../lib/python/zc/catalog/stemmer.txt", line 39, in stemmer.txt
Failed example:
list(ix.apply('constables*'))
Expected:
[]
Got:
[0]

Have these been fixed outside of the sandbox, or does this not occur in 
your setup?


Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] security problems with database adapters (second edition)

2005-08-30 Thread Velko Ivanov



Dmitry Vasiliev wrote:

zope.app.securitypolicy.zopepolicy.ZopeSecurityPolicy does the following:

1. check for security map at /aFolder
2. get the aFolder's parent (the root folder in our case) through the 
'__parent__' attribute

3. check for security map at /
4. check global security map defined through configuration

If object doesn't have a '__parent__' attribute and any associated 
security map the security check will be based only on global security map.




Oh, now I see it. Thanks :)


Maybe we need always check security map at the root folder?



I don't believe this is the solution. Altrough it will solve my example, 
it wouldn't help in other scenarios.
I would eventually make ZopeConnection and ZopeCursor locatable, if they 
aren't already, and assign the database adapter as the parent of the 
connection and the connection to the cursor at the time of their creation.

Actually I'm going to patch it like that right away.

One last question, to clear things a bit for me, as I don't have a Zope3 
copy here to try -
Imagine the user accesses some python class by the means of submiting a 
form and that class needs to do some work with the database, so it 
obtains a database connection, creates a cursor and executes some 
queries. In this case, will the class access the connection with the 
user's privileges, or is it trusted ?
If it is trusted, my problem here is not of so big importance, but if 
not, I imagine zope.app.rdb needs some urgent updates.



Regards,
Velko Ivanov
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: [Z3lab] Re: [DRAFT] local portlets and perspectives


Jean-Marc Orliaguet schrieb:

Tonico Strasser wrote:



Jean-Marc Orliaguet schrieb:



yes, this is the ZPT way of doing it :-)



Yes, I find ZPT is very suited for this stuff becuase it has that slot
thing. That wouldn't be possible with e.g. DMTL I think. Do CPSSkins
support other template languages than ZPT?

Tonico



python is supported, xml/xslt is supported, DTML, C, ... as long as some
method can be called and provide some data that makes sense for a
filter. This is not the case by the way with ZPT fill-slot macros, you
can't just render a "fill-slot" without having the corresponding
"define-slot"

/JM


Do you render individual HTML snippets first and assemble the whole page 
before sending it to the requester? Or how do you generate the markup?


If yes, I mean something different. I think I would love a Python 
wrapper for Page Templates that can assemble *macros* from different 
templates provide them with names and render the main template only 
once. (Wait, that is already possible, isn't it?)


That would solve most of my use cases. But I will stop my comments now 
because I have to think more about it first ;)


Tonico

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: Bug in i18n timezones (was Re: [Zope3-Users] obtaining time zone from http request)

2005-08-30 Thread Stephan Richter

On Monday 29 August 2005 22:38, Stuart Bishop wrote:
> I'm happy to expose this through pytz. There is a new set of data files
> released yesterday (including the 2006 changes the US has just signed into
> law) so I can push out a new release in the next day or two with this
> added.

Fantastic!

> Stephan - Should this update go into the 3.1 branch, or just the trunk?

Let's do this only in the trunk. I really would prefer not changing RC 2 
anymore, so I can make it the final version.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: Bug in i18n timezones (was Re: [Zope3-Users] obtaining time zone from http request)

2005-08-30 Thread Stephan Richter

On Monday 29 August 2005 21:53, Gary Poster wrote:
> Stephan, do you have any concerns about incorporating the Olson  
> information in 18n?  I suppose another approach would be to see if  
> Stuart would be willing to have pytz grow this mapping, and have the  
> i18n package depend on pytz.  I'd actually prefer that, if you and  
> Stuart agreed and were willing, since he already has his automatic  
> processing of the Olson database, and is already keeping up with the  
> Olson releases.

I would also prefer this mapping in the pytz package. But if Stuart does not 
want to do this, then we'll put it in zope.i18n somehow.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: [Z3lab] Re: [DRAFT] local portlets and perspectives

Tonico Strasser wrote:

> Jean-Marc Orliaguet schrieb:
>
>> yes, this is the ZPT way of doing it :-)
>
>
> Yes, I find ZPT is very suited for this stuff becuase it has that slot
> thing. That wouldn't be possible with e.g. DMTL I think. Do CPSSkins
> support other template languages than ZPT?
>
> Tonico

python is supported, xml/xslt is supported, DTML, C, ... as long as some
method can be called and provide some data that makes sense for a
filter. This is not the case by the way with ZPT fill-slot macros, you
can't just render a "fill-slot" without having the corresponding
"define-slot"

/JM
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: [Z3lab] Re: [DRAFT] local portlets and perspectives


Jean-Marc Orliaguet schrieb:

Tonico Strasser wrote:



Hi!

Jean-Marc Orliaguet schrieb:



Anyway, pagelets or portlets whatever they called and no matter what
data they produce (structured data or raw HTML) must be "pipe-able"
through the rendering engine, i.e. they must return some data, the more
"ready HTML" the data is the less reusable it will be.



Pipe-able, hmm. I think, *if* we could do define-slot and fill-slot
stuff in Python code that would be very nice. We would have a "page"
object that can "pipe" page components together.




yes, this is what cpsskins does:

- the "define-slot" is just a "cpsskins:slot" with a name identifier
('left', 'right', 'main' ...) which means that can be used on several pages.

- the "fill-slot" part has been the subject of the discussion the past
week in the "perspective" thread.

Currently the plan is to support the "perspective" way of filling slots
(1 perspective = 1 set of portlets) and the "local folder" way of
filling a slot, i.e. traversing the site starting from the site root to
the current folder, gathering all the portlets stored in each folder on
the path and displaying them into the slot that they belong to.

here is how the renderer works:
http://www.z3lab.org/sections/front-page/white-papers/draft-renderer/downloadFile/attachedFile/renderer-architecture.png

starting from the top node in the theme tree:

A) is the node a leaf?

   => YES: then render the node according to B)

   => NO: get the list of child nodes in the correct order, for every
node go to A)


B) for every filter associated to the node:

  - is the filter is the first in the chain?

=> YES: then get the data from the leaf (getDisplayData())
=> NO: use the output of the previous filter in the chain and feed
it into the current filter

  - if the filter is the last in the filter chain for that node, feed
the filtered data into the next renderer.

In this way, believe it or not, you can by changing a few lines in a
zcml file render a "theme editor" with all the AJAX stuff
http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/configuration/engines/editor/configure.zcml

or an HTML page ready to be displayed on a web page:
http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/configuration/engines/default/configure.zcml

90% of all the components are reused, simply they are wired together
differently.




A simple example with boxes (sorry, Zope 2 script, don't kill me):


[...] snip example


yes, this is the ZPT way of doing it :-)


Yes, I find ZPT is very suited for this stuff becuase it has that slot 
thing. That wouldn't be possible with e.g. DMTL I think. Do CPSSkins 
support other template languages than ZPT?


Tonico

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] problems with

2005-08-30 Thread Dominik Huber


Excuse my delay, I was out of office last week...

A month ago, I got an error while using a sequence widget factory
referenced by the widget subdirective of an editform. I used the 
zope.app.form package of philips branch and that solved my problem:


svn+ssh://svnzope/repos/main/Zope3/branches/philikon-widget-subdirective

Regards,
Dominik


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Z3lab] Re: [Zope3-dev] [DRAFT] local portlets and perspectives

Tonico Strasser wrote:

> Hi!
>
> Jean-Marc Orliaguet schrieb:
>
>> Anyway, pagelets or portlets whatever they called and no matter what
>> data they produce (structured data or raw HTML) must be "pipe-able"
>> through the rendering engine, i.e. they must return some data, the more
>> "ready HTML" the data is the less reusable it will be.
>
>
> Pipe-able, hmm. I think, *if* we could do define-slot and fill-slot
> stuff in Python code that would be very nice. We would have a "page"
> object that can "pipe" page components together.
>

yes, this is what cpsskins does:

- the "define-slot" is just a "cpsskins:slot" with a name identifier
('left', 'right', 'main' ...) which means that can be used on several pages.

- the "fill-slot" part has been the subject of the discussion the past
week in the "perspective" thread.

Currently the plan is to support the "perspective" way of filling slots
(1 perspective = 1 set of portlets) and the "local folder" way of
filling a slot, i.e. traversing the site starting from the site root to
the current folder, gathering all the portlets stored in each folder on
the path and displaying them into the slot that they belong to.

here is how the renderer works:
http://www.z3lab.org/sections/front-page/white-papers/draft-renderer/downloadFile/attachedFile/renderer-architecture.png

starting from the top node in the theme tree:

A) is the node a leaf?

   => YES: then render the node according to B)

   => NO: get the list of child nodes in the correct order, for every
node go to A)


B) for every filter associated to the node:

  - is the filter is the first in the chain?

=> YES: then get the data from the leaf (getDisplayData())
=> NO: use the output of the previous filter in the chain and feed
it into the current filter

  - if the filter is the last in the filter chain for that node, feed
the filtered data into the next renderer.

In this way, believe it or not, you can by changing a few lines in a
zcml file render a "theme editor" with all the AJAX stuff
http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/configuration/engines/editor/configure.zcml

or an HTML page ready to be displayed on a web page:
http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/configuration/engines/default/configure.zcml

90% of all the components are reused, simply they are wired together
differently.


> A simple example with boxes (sorry, Zope 2 script, don't kill me):
>
> ##
> page = context.Page(template=container.ZPT_A)
>
> # aggregate macro-defs from other page template
> page.macros.update(container.ZPT_B.macros)
>
> # create list of Box instances (not rendered HTML)
> b1 = container.box_a('demo', 'Demo', condition=some_condition)
> # box 2 takes b1 as input
> b2 = container.box_b('foo', 'Foo', some_arg=b1)
>
> left_boxes = [b1, b2]
>
> # make boxes available in PTs as 'lboxes'
> page.lboxes = left_boxes
>
> # now we have aggregated all informations
> # ready to render
>
> # calls pt_render of ZPT_A with extra context
> return page.render()
>
> ##
>
> ZPT_A:
>
> 
>   
> 
>
> ZPT_B:
>
> 
>   
>   
> 
>
> box_repeat macro:
>
>   metal:define-macro="box_repeat"
>  tal:repeat="box lboxes"
>  tal:attributes="id box/id">
>  tal:content="box/title"/>
>   metal:use-macro="box/macros/body|default"/>
> 
>
> Just for your inspiration.
>
> Tonico
>
>

yes, this is the ZPT way of doing it :-)

/JM

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] security problems with database adapters (second edition)

2005-08-30 Thread Dmitry Vasiliev


Velko Ivanov wrote:

The problem is easy to reproduce in a few simple steps - assuming clean 
installation from the .tgz release, here is what I do:


1. create an instance (of course), zope.Manager granted principal is 
crated by the mkzopeinstance script.
2. uncomment the sample zope.Member principal 'frodo' in principals.zcml 
and run zope

-- using the browser from now on:
3. login with the zope.Manager principal use the grant tool to grant 
zope.Manager role at the top of the site to the 'frodo' principal
4. go to manage site -> site management and add a database adapter, 
gadfly will do, dbi is something in the form of dbi://dbname;dir=/tmp, 
or any other dir as apropriate

5. login as frodo and go to /++etc++site/tools/yourdbaname
6. select the test page and just click on 'execute'
7. unauthorized
8. if you try (5),(6) with the zope.Manager principal, you will see the 
database adapter working as expected (producing an error in this example 
actually, but not 'unauthorized' exception)


Ugh. The problem seems is that the UI grant tool work only for locatable 
objects like folders, pages and so on. For example if you go to /@@grant.html 
and grant some role/permission for a principal a local security map will be 
stored in the root folder annotations. Then if you access some folder at 
/aFolder zope.app.securitypolicy.zopepolicy.ZopeSecurityPolicy does the following:


1. check for security map at /aFolder
2. get the aFolder's parent (the root folder in our case) through the 
'__parent__' attribute

3. check for security map at /
4. check global security map defined through configuration

Then global security declarations will be overridden by local security 
declarations.


If object doesn't have a '__parent__' attribute and any associated security map 
the security check will be based only on global security map.


Maybe we need always check security map at the root folder?

--
Dmitry Vasiliev (dima at hlabs.spb.ru)
http://hlabs.spb.ru
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives