I just checked in a fix for this.
Jim
Jim Fulton wrote:
I'm surprized that this was closed. I'm familiar with this
bug, know how too fix it and had planned to knock it off
during bug day, but it wasn't on the list. I'll fix this
this weekend.
Jim
Roger Ineichen wrote:
Hi Andreas
Stephan
this, please send them to the Zope 3
users list, [EMAIL PROTECTED]
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
widget creation harder (unless you are the author of
SimpleInputWidget :).
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
to use.
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
Stephan Richter wrote:
On Tuesday 05 July 2005 07:55, Martijn Faassen wrote:
Perhaps this is something that can be placed in FunctionalTestCase's
teardown itself, though?
Yep, this seems like a bug. I agree with your fix.
+1
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED
use the action handler name instead
(e.g. form.actions.return_for_changes).
This is likely to affect tests that involve sample generated forms
or form input. In the long run, it will make these tests more readable.
Any objections?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python
Jim Fulton wrote:
Currently, if you have an action defined with a label that
is not an identifier:
@form.action(_(Return for changes))
def return_for_changes(form, action):
...
The submit button name will be converted to hex
(e.g. form.actions.52657475726e20666f72206368616e676573
with Contaner implementing IContainer.
I'd be happy to see IContainer go away. I don't think the distinction
between ILocation and IContainer is worth the complexity they cause.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
Martijn Faassen wrote:
Jim Fulton wrote:
Martijn Faassen wrote:
Christian Theune wrote: [snip]
I'm actually interested in what the plans/needs for zc.page are to
move into core. Maybe I/we can spend some time on bug fixing ...
Even if not in the core, it'd already help if this wasn't
. :)
There are various ways that one could design an index that would
handle objects of different types, if necessary or handle None as
a special case. Thar would require a fairly different design.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361
Martijn Faassen wrote:
Jim Fulton wrote:
[snip]
It would only be safe to use None as a BTree key if all of the keys used
were None, which wouldn't be very interesting. :)
It'd also make sense if you didn't do a range query, right? I.e. you're
just looking for (None, None). I realize though
location information.
or
- Don't generate events amout the located objects (e.g. modification
events) from within content object methods. The content objects
don't have enough information. Rather, generate the events from views
on the objects obtained from the container.
Jim
--
Jim Fulton
Martijn Faassen wrote:
Jim Fulton wrote:
...
- Implement ILocation in your content objects. This is the simplest
course. It sounds like, for your application, the content objects
should know about their locations, since you want them to be able to
generate events that contain location
and not by
ITransientLocation.
What do you think?
I think it is unnecessary. Persistency and location are
unrelated.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http
on this in Zope 3.2.
There won't be any backward-compatibility code to support
unusual usages like yours.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http
?
Only if it is modified after creation, which I doubt.
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
.
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
change, so the user's permissions
shouldn't really have anything to do with it. The system can do whatever
it wants, which we represent via removeSecurityProxy or trusted adapters.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
Martijn Faassen wrote:
Jim Fulton wrote:
Martijn Faassen wrote:
[snip]
* the snapshot is probably aging as bugs get discovered and fixed in
your repository. Could you perhaps update the snapshot?
Sure.
Looking forward to the update, though we haven't found bugs yet in our
will be in two parts, a Zope 2 part that includes the current
Zope 3 and a Zope 3 part.
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
Martijn Faassen wrote:
Jim Fulton wrote:
Max M wrote:
Jim Fulton wrote:
Further, we will coordinate the releases. Essentially, *Zope*
is switching to a new release schedule. Zope will be released every
6 months
and the releases will be in two parts, a Zope 2 part that includes
a problem for large shared containers that people are
very likely to add to at the same time, so it's a somewhat
specialized problem.
If people don't actually care about ids, you could generate them
randomly.
Another common scheme is to use high-precision times in th names.
Jim
--
Jim Fulton
Ivo van der Wijk wrote:
On 6/16/05, Jim Fulton [EMAIL PROTECTED] wrote:
Ivo van der Wijk wrote:
On 6/14/05, Jim Fulton [EMAIL PROTECTED] wrote:
In preparation for the 3.1 release, I made these packages (as
well as zope.app.observable and zope.app.schema) optional and thus
configured vie
it. I'd be interested to see how well it works over
the long run.
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
inconvenient property
that you can't compute a key reference for a persistent object until
it has been added to a database. Key references based on guids wouldn't
have this negative property.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
Ivo van der Wijk wrote:
On 6/14/05, Jim Fulton [EMAIL PROTECTED] wrote:
In preparation for the 3.1 release, I made these packages (as
well as zope.app.observable and zope.app.schema) optional and thus
configured vie package includes. If you have an instance that
uses these, you will need
In preparation for the 3.1 release, I made these packages (as
well as zope.app.observable and zope.app.schema) optional and thus
configured vie package includes. If you have an instance that
uses these, you will need to add package includes for these.
Jim
--
Jim Fulton mailto:[EMAIL
Stphane Brunet wrote:
Jim Fulton wrote:
First, you are confusing schema definitions and widgets. You should
start from the definitions of the field types.
That was a typo... Sorry for the confusion :-P
As Derrick (sort of) suggested, Bytes fields are fields that contain
Python strings
Roger Ineichen wrote:
Hi Jim
Behalf Of Jim Fulton
Sent: Monday, June 13, 2005 11:21 PM
To: [EMAIL PROTECTED]
Cc: zope3-dev@zope.org
Subject: Re: [Zope3-dev] Re: Existentialquestionabout
BytesWidget v.s. ASCIIWidget
Roger Ineichen wrote:
Hi Jim
Behalf Of Jim Fulton
Sent: Monday, June
this be for 3.2? Keep in mind that we want to generate a beta
release this weekend.
I can do it tomorrow since there are only a few places where modification
events are actually used.
If that seems to risky I will wait for 3.2.
Sounds good.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED
Sidnei da Silva wrote:
On Sun, Jun 05, 2005 at 10:08:40AM -0400, Jim Fulton wrote:
| No, that would be a feature. So we either have the choice of waiting a
| week or making an alpha release. I am for the first option, since I would
| like to have all packages included in the release.
|
| +1
Philipp von Weitershausen wrote:
Stephan Richter wrote:
On Sunday 05 June 2005 09:35, Jim Fulton wrote:
- What's the deadline for this?
Well, um, Stephan was hoping to make the beta today. :)
I don't know if we can treat the absense of DAV locking as a bug and
get it in after the beta
Philipp von Weitershausen wrote:
Jim Fulton wrote:
Philipp von Weitershausen wrote:
Stephan Richter wrote:
On Sunday 05 June 2005 09:35, Jim Fulton wrote:
- What's the deadline for this?
Well, um, Stephan was hoping to make the beta today. :)
I don't know if we can treat the absense
Sidnei da Silva wrote:
On Sat, Jun 04, 2005 at 09:46:39AM -0400, Jim Fulton wrote:
|
| A few months ago, we gained a locking framework. We still need to provide
| a DAV interface to it. Are there any DAV-knowledgeable volunteers that can
| do this
| quickly? It would allow us to include
A few months ago, we gained a locking framework. We still need to provide
a DAV interface to it. Are there any DAV-knowledgeable volunteers that can do
this
quickly? It would allow us to include external editor in the 3.1 release.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED
is to provide support for object
versioning. But, as Jim's pointed out, this is probably better handled
at a lowed level, since there's no guarantee *any* event model will be
sufficient.
I'm 99% sure that this event model will not be sufficient for object
versioning.
Jim
--
Jim Fulton mailto
of optimizations you want to do.
Uwe, I still think you need something else for your versioning work.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http
Dieter Maurer wrote:
Jim Fulton wrote at 2005-5-26 14:43 -0400:
...
Probably the indexes that we *most* want to avoid reindexing are
text indexes. We have a ISearchableText interface that we
commonly adapt objects to to get the text to index. We really
can't predict how this text
Dieter Maurer wrote:
Jim Fulton wrote at 2005-5-27 08:29 -0400:
...
Then, we probably do something wrong...
That's always a possibility. I think what we are doing is
pretty reasonable. Perhaps you have other suggestions.
I think we need more control over what modifications trigger
-grained modification events that justifies the complecity of
proposals we've thought of so far.
Thoughts?
Are there other applications for modification events that
I haven't considered?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
Julien Anguenot wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
Roger Ineichen wrote:
Hi Jim
I like to work on the activity based wfmc workflow.
Can I help you with the UI work. Do you need some views or something
else for adding workflow definition or instances
is specially treated:
``have package ldap``
How about: have-module? Is there any reason to limit this to packages?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com
be a core feature of Zope 3, if or
no other reason than so we can use them in tests. :)
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
has changed.
IObjectAnnotationsModifiedEvent, which isn't well named, should indicate
that extrinsic/meta information has changed.
I agree that a more precise model might be useful, if one could design one
that made sense. shrug
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python
Philipp von Weitershausen wrote:
Jim Fulton wrote:
Martijn Faassen wrote:
...
If someone that is not interested in Zope 3 in the first place wrote
a Python library we'd like to include, the relicensing hurdle will be
larger, though. What's to be done with Twisted integration, for
instance
Martijn Faassen wrote:
Jim Fulton wrote:
Well, libxml2/libxslt cannot be relicensed by me, so the MIT license
will stay.
Of course. I don't think we should include those libraries in the release.
I suggest we simply make those prerequisites of Zope 3.
Most 'nix platforms seem to have it already
.
That is, my hope is that Martijn can release lxml under
ZPL as well as any other licenses he wishes.
It needn't be copyright ZC and Contributors. It could be
copyright Infrae.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http
myself but either I'll have to implement my own
catalog or continue the existing one.
I recommend that you build what you want as an application that uses
the Zope 3 catalog.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http
).
Wouldn't it be the best solution to generate an
IObjectContentModifiedEvent in the File._setData method and
not the view classes?
I think this would be OK for this specific case.
What I don't want to see is some general implicit event-generation
scheme.
Jim
--
Jim Fulton mailto:[EMAIL
mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http
for bug fixes.
You're right. It's probably best to save this for 3.2.
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
raise TypeError(iface_type, is not an interface type)
78directlyProvides(interface, iface_type,
directlyProvidedBy(interface))
+1
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation
widgets,
moving it to form code.
Thoughts? Questions? Any objections to getting this into
3.1? If not, I'll write a more detailed proposal.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope
--
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
Shane Hathaway wrote:
Shane Hathaway wrote:
Jim Fulton wrote:
Thanks for the positive feedback. Fred Drake worked very hard
on this. One thing we did right was to leverage distutils
ability to build binary releases. I'm also encouraged by work done
at the recent PyCon sprints that someday we'll
Zope 3
features in the form of Five.
OK, I like this. Let's make it so. :)
Let's drop the X and the extra 3 from the release and include this
in the release notes and announcements.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope
Fulton wrote:
Martijn Faassen wrote:
Jim Fulton wrote:
[snip]
2. The X in Zope 3X means that there is not yet support for
Zope 2 transition. It's about setting expectations.
But we're setting the expectation that one day there will be a
version of Zope 3 that supports Zope 2.
No. We are setting
Dominik Huber wrote:
Jim Fulton wrote:
Dominik Huber wrote:
Excuse me late response I was busy that weekend...
Jim Fulton wrote:
I fixed that issue within the branch
'Zope3/branches/dominik-locatableadapters'
Jim, could you take a look at that please. Thank you very much in
advance!
[...]
We
whether it will clutter
anything.
3. If I have anything to say about it, there will never be a Zope 4. :)
4. I'm OK with dropping the extra 3 in the release names. IMO
either Zope X3.1.0 or Zope 3.0.1 are fine.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
Michael Kerrin wrote:
On Monday 18 April 2005 10:39, Jim Fulton wrote:
This is simply a result of the fact that no one has written a credentials-
extraction plugin for FTP yet.
I wouldn't mind writing a credentials-extraction plugin for FTP which isn't
that hard. But what I am confused about
of zope.publisher. This problem will be
fixed, since the app server will take over the logging.
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Dominik Huber wrote:
Jim Fulton wrote:
...
How can I ask for trusted adapters explicitly inside a framework such as
edit view?
You can't.
If we adapt a context to a certain schema (given by the schema attibute
of the editform directive) we have no chance today to ask explicitly for
a trusted
, they provide a powerful tool to solve extra hard problems,
but they should be used sparingly.
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
Dominik Huber wrote:
Jim Fulton wrote:
OK, here's an alternate proposal:
If the permission attribute is used in the adapter directive and the
permission is not zope.Public, then:
If the adapter doesn't provide ILocation, we location proxy it and
set the parent.
If the adapter does
Stephan Richter wrote:
On Wednesday 06 April 2005 08:47, Jim Fulton wrote:
Thoughts?
+1.
Also note that not many people use this way yet, since it is (a) not
publicized and documented (only in README.txt) very much and (b) has not been
released yet.
Right, that's why I want to change it now
wonder if it would make sense for the trusted adapter machinery to
simply set __parent__ on adapters if either the adapter provides ILocation
*or* the adapter doesn't already have a __parent__. This would solve the
problem and avoid the proxy.
Jim
-- Garrett
Dominik Huber wrote:
Jim Fulton wrote
one interface cannot be registered
with the implicit adapts and implements informations.
True.
- A regular schema does not extend ILocation therefore it is not obvious to
write an adapter implementing ILocation.
True.
Any objections?
Yes. :)
Why not simply use an untrusted public adapter?
Jim
--
Jim
701 - 768 of 768 matches
Mail list logo
