Re: [Zope-dev] Core Dump (Zope 2.7, Python 2.3.3, FreeBSD 4.5)

2004-02-19 Thread Jeffrey P Shell
On Feb 19, 2004, at 1:09 PM, Jeremy Hylton wrote:

Jeffrey,

Any luck with your core dump?
I recompiled Python 2.3 with a bigger stack size, and that seems to 
have worked.

We had similar problems with Python 2.1.3 (it's a pretty infamous 
Python+FreeBSD problem, AFAICT), and I thought that it was patched in 
the Python core by now as I thought I heard something along those lines 
a while back, but I may have been hearing about the patch being applied 
to the BSD 'ports' collection.

--
Jeffrey P Shell
[EMAIL PROTECTED]
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Core Dump (Zope 2.7, Python 2.3.3, FreeBSD 4.5)

2004-02-18 Thread Jeffrey P Shell
I've been experiencing the most peculiar core dump under Zope 2.7.  
It's on a web application we only decided to revive late last week, so 
it was never tested under earlier beta/RC conditions.

The core dump occurs when visiting manage_main on a particular folder.  
The contents of this folder are basically just Python Scripts, Page 
Templates, and a few DTML Methods (including standard_error_message).

I can get manage_main to render in zopectl debug (using 
Testing.make_request to make enough of a REQUEST object for it to 
render with).  And I can read everything in that particular folder with 
zopectl debug.  I used this to experiment with moving items around 
between folders - including moving all of the templates/scripts into 
their own folder outside of the web application.  It still core dumps.  
At one point, I thought I had narrowed it down to a particular template 
(although the reasons for why it would be this template elude me) by 
doing some interactive Python work [I had written some helper 
'move_object' and 'copy_object' functions a while back, and used them 
to move items between a pair of folders and then seeing which one Zope 
would crash on].

I got the contents of the template out using ``zopectl debug``, and 
recreated the template by hand, now that I could actually get into the 
target folder.  It worked for a brief moment, but so did the source 
folder, which now had this one particular template remaining.

I tried various imports and exports of the web application, including 
using one that was known to still be working off of a production server 
(Zope 2.6.1, Python 2.1).  I even tried copying the contents 
(individually) of the folder - completely removing them from original 
context.  It still core dumps.  (Before I tried imports and exports, it 
was running in a Data.fs that had been copied from a Zope 2.6.1 
instance to 2.7.  Python Scripts were recompiled)

Finally, I thought it might be a Python 2.3.3/FreeBSD issue (like there 
were issues with default stack size on Python 2.1.x and FreeBSD).  This 
Python 2.3.3 had been built from source just last week, on the day I 
installed Zope 2.7 final on our development server.  So I downloaded 
Zope 2.6.4 and ran that with Python 2.3.3, importing the problematic 
export.  I could list the contents of this particular folder just fine. 
 The import had Python 2.1 compiled scripts, so I recompiled them and 
exported it again just to see if that was causing strange issues - but 
when brought into Zope 2.7, the core dump still happens.

The folder in question is not terribly large - when I extracted the 
scripts/templates manually into a new folder, I think it has about 41 
items in it.

What should I do next?  Should I familiarize myself with gdb and 
inspect the core?  What are some things I could look for if that's the 
next step?

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] how can I prevent undo?

2003-10-27 Thread Jeffrey P Shell
Actually, this should be doable by removing access to the ``Undo 
changes`` permission.

--
Jeffrey P Shell
[EMAIL PROTECTED]
On Oct 26, 2003, at 1:49 PM, Andreas Jung wrote:

By removing the Undo tab or by removing Un doSupport from the 
baseclasses
of your objects?

-aj

--On Sonntag, 26. Oktober 2003 20:38 Uhr +0100 robert 
[EMAIL PROTECTED] wrote:

Hi there,
I have objects that are linked to an external database.
When they are deleted, also the data in the external database is 
deleted.
Now an undo is bad, because I then get an object with ab link to non
existing  data.
I must therefore prevent undo.
How can I do that?

Thanks,
Robert




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [CRITICAL] Conflict Errors, Transactions, Retries, Oh My....

2003-05-30 Thread Jeffrey P Shell
On Thursday, May 29, 2003, at 07:32  AM, Chris McDonough wrote:

On Thu, 2003-05-29 at 01:08, Jeffrey P Shell wrote:
Thanks for the information.  Is it safe at all to try to catch a
ConflictError during the critical part of the code, log some
information, and then reraise the error to let the system do what it
needs?
Sure, but I'm not sure what that buys you in your case.  The system 
will
still retry the request if you reraise a conflict error.  And it would
be spotty coverage at best; it's almost impossible to know where a
ConflictError might be raised.  The only reasonable solution would be
to change ZPublisher's default behavior to not retry requests on
conflict errors, which is probably not what you want either.
Changing ZPublisher doesn't sound like fun times.  I think I'll avoid 
that one :).

The main thing that I want to catch is the fact that this event has 
occurred so that we can (a) get notified by monitoring software that 
something is screwy, (b) have a record identifier in the logs that 
would help us clear the right record out of the external system as soon 
as possible, and (c) let us know with accuracy when this situation 
occurs.  We've only had one report of this happening, but we have some 
other suspicious data that we're not sure about.

I have an idea on how to handle it, thanks to your TransactionManager 
suggestion.  We still need to send the data out through the gateway 
immediately (we can't wait for a transaction commit), but might be able 
to do this:

def send(self, data):
self._txn_note = data['item_id']
...
def abort(self, reallyme, t):
	if self._txn_note:
		LOG('Outro', PROBLEM,
 'Received abort after sending transaction id %s' % 
self._txn_note)
	self._txn_note = None

def tpc_finish(self, transaction):
self._txn_note = None
It's a rough view of the transaction methods that I think I'll have to 
implement to do this.  It might make a good howto/recipe ultimately.  
*shrug*.

We've also found that accessing session data early in the request can
help reduce the number of conflicts that happen later in the request.
See http://mail.zope.org/pipermail/zope-dev/2003-March/019081.html for
more information.
Thanks.  Quite an interesting read (I got a bit of a ways through it 
and have bookmarked it for closer evaluation when I get to the office).

I apologize if this post is making little sense (or stupid sense) -
dealing with threads, locks, conflicts, etc, has been the part of Zope
I've understood the least.  I like that for the most part I don't have
to think about it, but I don't know where to go for [fairly] current
documentation on how to deal with it for those rare times I do.
FWIW, the Zope Book 2.6 edition session chapter speaks a bit to what
conflict errors are.  The ZDG persistence chapter talks a bit about
threading and concurrency.
A little off-topic: any idea when the 2.6 ZB can be marked as current?  
Or are we waiting for Zope 2.7 to do that? ;)

That documentation has been helpful.  Although I still don't know when 
Zope/ZODB start new threads.  Is it for every REQUEST?

Know that any change to a PersistentMapping needs to load and repersist
the entire data set in the mapping when a key or value is updated or
added.  It is very likely that this will cause a conflict, particularly
when two threads try to do this at once.
OTOH, a BTree is made up of many other persistent subobjects, and there
is less of a chance (but still a good chance) that two concurrent
accesses to a BTree will cause a conflict error.
I'll move that data structure to a BTree.  I have to do some other work 
on that code anyways.

The best source of docs for sessions in the 2.6 Zope Book sessions
chapter.  The maillist thread that I mentioned above gives some
information from Toby Dickenson about accessing session data early in a
transaction to reduce the possibility of read conflicts.
Good luck!
Thanks.  I owe you yet more beer.

--
Jeffrey P Shell
[EMAIL PROTECTED]
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] [CRITICAL] Conflict Errors, Transactions, Retries, Oh My....

2003-05-29 Thread Jeffrey P Shell
I need to know more about Conflict Errors.  We're running into a lot of 
them lately, it seems, on production Zope 2.6.1 sites (running on 
FreeBSD).  The primary culprit seems to be Temporary Storage/Sessions.

Something that has happened, and is causing a small amount of alarm, is 
that a large method that interfaces to external non-transactional 
systems seems to (on occasion) send their information off to that 
external system twice, but there's only one matching set of Zope data.  
As the two writes to the non-transactional system are very close to 
each other and contain nearly identical data (except for one bit that 
gets regenerated in the method), and there are conflict INFO reports in 
the Event Log from around the same time, I'm assuming that a conflict 
error is happening somewhere in this method and causing the transaction 
to be retried (if I'm understanding how Conflict Errors work).  Zope 
and the relational databases seem to do things fine with rolling back 
the data, but the non-transactional systems now have duplicate data 
that they **absolutely should not have**.

This doesn't happen often, but (as stated), this is a critical 
operation that needs to be better protected.  All other exceptions and 
bits and pieces in the block of code in question has been tested 
thoroughly and we have not had any other problems that cause erroneous 
writes.  Is there a way I can protect against Conflict Error retries as 
well?  Is there some sort of Try/Except or Try/Finally I can wrap 
around the code that won't interfere with the ZODB?  Is there any other 
sort of best-practice here that could help me (and others) who might 
unknowingly trigger this problem?

I know there are some fixes likely to be in Zope 2.6.2 that may help 
with the situation, but I'd like to put extra protections around this 
code regardless of what may be coming in the future.

Thanks in advance,
Jeffrey P Shell
[EMAIL PROTECTED]
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [CRITICAL] Conflict Errors, Transactions, Retries, Oh My....

2003-05-29 Thread Jeffrey P Shell
On Wednesday, May 28, 2003, at 10:19  PM, Chris McDonough wrote:

This doesn't happen often, but (as stated), this is a critical
operation that needs to be better protected.  All other exceptions and
bits and pieces in the block of code in question has been tested
thoroughly and we have not had any other problems that cause erroneous
writes.  Is there a way I can protect against Conflict Error retries 
as
well?  Is there some sort of Try/Except or Try/Finally I can wrap
around the code that won't interfere with the ZODB?  Is there any 
other
sort of best-practice here that could help me (and others) who might
unknowingly trigger this problem?
Not infallibly.   You can really never know where a ConflictError will
might be raised.  Any concurrent access to a persistent object is a
possible candidate.
Thanks for the information.  Is it safe at all to try to catch a 
ConflictError during the critical part of the code, log some 
information, and then reraise the error to let the system do what it 
needs?

I guess you're right though - it's hard to know when it will occur.

In the production system, in this particular method, there are only two 
known persistent object interactions.  At the end of the entire method, 
after a notification email has been sent, I have something like:

session['pieces'] = {}

(session['pieces'] was a dictionary of {item_id:integer} bits.  It 
never gets large for an individual user).  I think that the one recent 
case of desync'd data happened when we got to this point.  Since it's 
at the very end of the script (no more writes are expected beyond this 
point), I imagine that a get_transaction().commit() might be OK to 
precede this statement, just so that even if any conflicts happen when 
trying to write back to the session, we at least have synchronized data 
between the two systems.  Although, prior to this, there are a few 
reads of this session data.  Might it be safer to do something like 
this at the top of the method?:

pieces = session['pieces'].copy()

I apologize if this post is making little sense (or stupid sense) - 
dealing with threads, locks, conflicts, etc, has been the part of Zope 
I've understood the least.  I like that for the most part I don't have 
to think about it, but I don't know where to go for [fairly] current 
documentation on how to deal with it for those rare times I do.

The other persistent data write occurs earlier in the method, an object 
that generates serial numbers based off of some simple data in a 
PersistentMapping gets updated.  I think that PersistentMapping has 
become fairly large by now.  It maps the item_id referenced above to a 
regular dictionary containing three key/value pairs each.  I make sure 
to follow the rules of persistence when dealing with these 
dictionaries-with-a-PersistentMapping, but I'm guessing that an OOBTree 
might be better instead.  I still don't understand the potential 
pitfalls of Zope/ZODB BTrees (I keep reading about 'bucket splits' 
causing conflicts, and I don't know if that would be better or worse 
than any pitfalls a PersistentMapping gives).

Finally, the system in question has a few (three?  four?) public Zope 
sites using the same session storage.  Is there any documentation, 
notes, etc, about fine tuning the default session storage set up to 
handle large sites (or groups of sites) with less conflicts?

Thanks again for the help.  I'll take a look at MailDropHost.  Maybe 
I'll have to wrap another gateway around the gateway to the external 
system to try to catch these conflict situations.  Fortunately, the 
critical area only occurs once in the current copy of the code.  
Hopefully that will make it easier to protect.

Thanks again,
Jeffrey
 

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] 2.6.1b2?

2003-01-27 Thread Jeffrey P Shell
I updated the Zope 2.6 project page to reflect this, figuring that it 
should at least be *somewhere* on the web :).

http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/FrontPage

It's nothing fancy, I just included the note and took out some of the 
older Status notes that reflected the development path towards 2.6.0.

On Monday, January 27, 2003, at 11:47  AM, Brian Lloyd wrote:

Here's the status - an engagement that we're doing has been bringing
up some issues regarding ZODB and ZEO in large-scale environments. I
think that the fixes are useful enough that they should be in 2.6.1,
but getting them finalized has taken longer than I expected. I'll
know better later today, but I expect that the fixes will be wrapped
up this week, enabling a 2.6.1 b2 next week.



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope and python compatibility

2003-01-09 Thread Jeffrey P Shell
On Thursday, January 9, 2003, at 10:06  AM, Tena Sakai wrote:


Greetings zope-dev folks,

Please help me out.

I have seen below via google search:

   Zope 2.5 + Python 2.1  -- Good
   Zope 2.6 + Python 2.1  -- Good
   Zope 2.7 + Python 2.1  -- Bad
   Zope 2.5 + Python 2.2  -- Bad
   Zope 2.6 + Python 2.2  -- Bad
   Zope 2.7 + Python 2.2  -- Good

This article/note was from September, 2002.
Can someone please comment if the data
above is still valid?


To my knowledge it is, although I recall reading that Zope 2.6.1 is 
intended to be Python 2.2 compatible - not breaking, but not 
requiring any Python 2.2 features.

2.6.1 is supposed to have its second beta soon.  I suppose I should 
give the first beta a test against Python 2.2 to see how it goes.  
2.6.1b1's been solid under Python 2.1.3, at least on our development 
box.

Jeffrey P Shell, [EMAIL PROTECTED]


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )


Re: [Zope] Re: [Zope-dev] Zope Book call for assistance

2002-12-09 Thread Jeffrey P Shell
On Saturday, December 7, 2002, at 04:11  AM, Tino Wildenhain wrote:


Hi Chris,

--On Freitag, 6. Dezember 2002 21:27 -0500 Chris McDonough 
[EMAIL PROTECTED] wrote:

On Fri, 2002-12-06 at 19:13, Tino Wildenhain wrote:

These are exactly the things you shouldn't neither do in DTML
nor in ZPT :-)


What do you suggest people use for a templating language for email,
JavaScript, SQL, etc?  I think it's too much to expect them to use
Python to do this (esp. wrt SQL methods).


Oh, is it? I'd rather like to write %(name)s %(value)d
then dtml-whatever value
Recently I read the python-dbi spec and its very nice to see
what you could do with the above form. There are even
standard ways to do multiple querys or function calls.
(Hope I can contribute a product for this as time permits)


But SQL Method DTML is very very very very nice.  It has a lot of type 
enforcement/safety measures (ie - autoquoting SQL Strings, ensuring 
that a 'sqlvar type=float' operation is inserting a float); a lot of 
*very* nice features for generating 'where' clauses (the sqltest 
'optional' flag and the smart 'dtml-and and dtml-or' tags that 
won't render if an optional 'sqltest' preceding them was not rendered); 
the 'sqltest multiple' feature is especially nice:

dtml-sqlgroup where
dtml-sqltest foo type=nb multiple optional
/dtml-sqlgroup

If foo is a blank string or empty list, that will render nothing.

If foo is a single string, that renders::

where foo = 'bar'

But if foo is a list of strings, that will render::

where foo in ('bar', 'baz')

Doing that programatically in Python is counterintuitive and awkward 
(just as it was before the specialized 'dtml-sql___' tags in DTML).  
For simple queries, doing it in the host programming language is not 
bad.  But for complex queries, it's very awkward to generate SQL.  It's 
almost as bad as generating HTML inside of a programming language - it 
becomes difficult to maintain.

For E-Mail and Javascript templates I also find it less confusing
if I can use %(var)s form.


It's worth noting that there's a little known DTML format that's of 
this style.  Again - when doing simple insertion, %(var)s is not bad.  
But once anything fancy comes into play - conditional insertion, 
looping, etc - maintainability goes out the window when staying in the 
host programming language.  When I was evaluating Roundup 
http://roundup.sf.net, I wanted to generate emails that looked as 
good as the ones generated by Tracker.  I had to write lines and lines 
and lines of Python code to do it in order to replace a subclassed 
method.  There was no template that I could jigger around.  (To be fair 
to Roundup and Tracker both, I think customizing Tracker's email 
messages is even harder).

I wouldn't mind seeing DTML.String re-emerge, which complements the 
Python formatting string with DTML constructs to handle more advanced 
templating needs.  If you took a lot of the programming-language style 
tags (dtml-try, dtml-return) out of DTML and normalized the expression 
system (ie - to use TALES), you'd have a very usable system.  The core 
design concepts of DTML are good, it's just corrupted itself over the 
years by stepping out of the plain-text templating language domain and 
straddling the templating/programming language domains.  DTML is even 
used to generate DTML, by using the Extended Python Format String 
syntax.  This is how the 'Z Search Interface' custom reports are 
generated.


As a general solution for texts one can use file which has an edit
tab for several releases of zope now. Then use it like this:

context.thefile.read() % context.REQUEST.form

or whatever seems appropriate to get values from.

E-Mail even gets clearer with the solution since you can easyly
loop and do whatever instead of multiple dtml-sendmail tags.


Life would be so much better if odd tags like dtml-sendmail could 
just go away, and instead we had 'SMTP Methods' or something like that 
- mail specific templates that are bound to a mailhost, with special 
DTML tags (like the mime tag), similar to SQL Methods.

I love the SQL Method specific DTML tags.  They make writing dynamic 
SQL statements so easy, especially when compared to _any_ other system 
that I've seen.  It's a good showcase for DTML's ability to turn into a 
domain specific templating language.

Regards
Tino



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] KeywordIndex and PersistentList (Bug?)

2002-11-20 Thread Jeffrey P Shell
What about ``if callable(aq_base(newKeywords)):`` to remove potential 
acquisition wrappers?

On Wednesday, November 20, 2002, at 12:41  PM, Casey Duncan wrote:

Just a note that this can't be put in Zope 2.6 since functions and 
methods
don't have a __call__ in Python 2.1.

-Casey

On Wednesday 20 November 2002 02:33 pm, Steve Alexander wrote:
Thomas Guettler wrote:


Hi!

In KeywordIndex the newKeywords get called
if they are callable:
def _get_object_keywords(self,obj):
newKeywords = getattr(obj, self.id, ())
if callable(newKeywords):   # (*)
			newKeywords = newKeywords()
if hasattr(newKeywords,'capitalize'): # is it string-like ?
newKeywords = (newKeywords, )
return newKeywords

This fails if the newKeywords are stored in a PersistentList.

Callable is true, but there is no __call__ attribute.

I changed the line marked with (*) to
 if hasattr(newKeyword, __call__):

and this seems to work

I think this does not break anything and could be included in the
original.

Am I the first how uses PersistentList for an indexed attribute? Is
there a reason not to do so?



The KeywordIndex should be changed to check for the __call__ 
attribute,
rather than relying on 'callable'. You cannot reliably use 'callable'
when you're also using acquisition wrappers.

See my comment to this Collector report.

   http://collector.zope.org/Zope/578

I suggest you report the bug you have found in the Collector.

--
Steve Alexander

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Proposed Additional reStructuredText Deliverables

2002-11-12 Thread Jeffrey P Shell
I'll volunteer for (1).  I think implementing it will be easy, but 
writing tests for it could be tricky...

On Monday, November 11, 2002, at 10:44  PM, Andreas Jung wrote:

3) is a *must-have feature*, 1) and 2) are *can-have features* 
(especially
2) ). At least for 1) I need a volunteer ;-)

-aj
1. reStructuredText support in the Zope Help System.
2. reStructuredText support for Product README handling.
3. Ensuring that Page Templates and Python Scripts can access the
reStructuredText.HTML() function.



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )


[Zope-dev] Proposed Additional reStructuredText Deliverables

2002-11-11 Thread Jeffrey P Shell
With Andreas plugging away at reStructuredText Integration into Zope, 
I'm thinking of some extra deliverables.  I'm not sure how deep we want 
to put ReST support in at the moment, considering that while the spec 
is pretty solid the codebase is still a moving target, but I would like 
to add and help work on the following proposed deliverables to the 
project:

1. reStructuredText support in the Zope Help System.
2. reStructuredText support for Product README handling.
3. Ensuring that Page Templates and Python Scripts can access the
   reStructuredText.HTML() function.

#1 looks like it would require adding a ReSTHelpTopic class in the 
HelpSys package which could probably mimic (or even sublass) the 
HelpSys.HelpTopic.STXTopic class.  Then support would have to be added 
into ``ProductContext.registerHelp()`` to map certain file suffixes to 
the ReSTHelpTopic ('.rst', etc).

#2 could probably be handled the same way (look for a 'README.rst' 
file), but may be served better if the contents of the README.txt could 
be introspected enough to detect format.  :\

#3 is easy, I just want to make sure it's not forgotten.  We just have 
to decide the right one way to do it: expose it in 
'Products.PythonScripts.standard' where all of the other DTML 
formatters are exposed, or out of its own namespace (ie: 
tal:content=structure python:modules['reStructuredText'].HTML(foo)).  
Or both ways.

--
Jeffrey P Shell
[EMAIL PROTECTED]


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] 2.6.1 Plan?

2002-10-30 Thread Jeffrey P Shell
On Wednesday, October 30, 2002, at 04:22  AM, Chris Withers wrote:


Ross J. Reedstrom wrote:

It what world do you live, and can I move there?


You miss the point ;-)

The flurry to get features into a 'stable' release is what I was on 
about.
If you flurry, the release won't be stable.

I like the pattern of having stable releases and CVS or nightly builds 
for people who want the latest and greatest. That way everyone gets to 
contribute easily and freely and yet we still get truly stable 
versions.

Maybe not to the extent of having seperate 'dev' and 'stable' streams 
a la Linux, but that's a good feeling in essence.

Still, the overarching thing is release early and often. The fewer 
features in each release, the fewer problems of I need this feature, 
but that means I also have to accept this one that I don't trust

But release often is a BITCH for software configuration management.  
Good for developers, bad for deployers.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] My 2.6.0 feature patch didn't make it!?

2002-10-30 Thread Jeffrey P Shell
On Wednesday, October 30, 2002, at 07:07  AM, Andreas Jung wrote:


Better put the patches at a public place (member area on zope.org).


Or a collector issue, since they do allow file attachments.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] __getattr__ and Acquisition

2002-09-23 Thread Jeffrey P Shell


On Monday, September 23, 2002, at 09:14  AM, Andreas Kostyrka wrote:

 Am Mon, 2002-09-23 um 11.12 schrieb Florent Guillaume:
 Anoter way to do that is to play games with __of__.
 Look at the implementation of the skins tool in CMF for an example.
 Doesn't help, as I do NOT know my container :(

 Basically __getattr__ when called does not know it's containment
 anymore. :(

This is why my stock suggestion to needing to do anything with 
acquisition and __getattr__ (or any other acquisition jump-arounds) is: 
Don't.  There are a lot of complexities that can arise out of 
Acquisition, Wrappers, and so on, that really require a deep 
understanding of exactly HOW acquisition works, versus what it usually 
does.

The other problem with __getattr__ is interfacing with Persistence.  
ZODB handles it now, but it wasn't all that long ago that it couldn't.

But with Acquisition - once you go beyond fair use, there's not 
enough Scotch in the world to kill the brain cramp.  :)


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Speaking of Structured Annoyances

2002-09-05 Thread Jeffrey P Shell

On 9/4/02 9:14 PM, R. David Murray [EMAIL PROTECTED] wrote:

 On Wed, 4 Sep 2002, Jeffrey P Shell wrote:
 Um, how does one escape * in STX-NG?  As in - what if one is entering an
 equation inline like 2 * 2 * 3 = 12?  Or, does one just fall back on using
 x?
 
 How about '2 * 2 * 3 = 12'?

Doesn't work.  At least, not where I tested it (ZWiki 0.7-ish).  :\

-- 
Jeffrey P Shell 
www.cuemedia.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: Future of StructuredText

2002-09-04 Thread Jeffrey P Shell

On 9/4/02 10:59 AM, Chris McDonough [EMAIL PROTECTED] wrote:

 IMHO, the indenting hassle is one of the best features of classic
 STX.  It's a pain to line things up but it does make for very
 readable source documents.  I think STX-NG is a little better than
 ReST for constructing readable source docs; especially if they are
 long, like chapters of a book due to this indenting.

When writing books, however, you're most likely using an editor that makes
it easy to reformat blocks at the proper indentation level.  For a lot of
web input where you still want to allow some simple structure, indentation
is a pain in the ass.  I do it because I'm used to it, but a lot of people
just will type in a paragraph as a single line.  Most of the time, this is
fine in Structured Text, until they indent one of the paragraphs even by one
space, turning the parent paragraph into a header block.

The indentation in STX is especially annoying when trying to drop in example
code, most likely pasted in from another source, and having to then move
every line to the right level - thus, code that was formatted to fit well in
eighty columns can be tricky to fit into an eighty column source STX
document if it's a few sublevels in.  I still have to find the right level,
mix of colons and spacing, etc..., after all these years.

-- 
Jeffrey P Shell 
www.cuemedia.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] Speaking of Structured Annoyances

2002-09-04 Thread Jeffrey P Shell

Um, how does one escape * in STX-NG?  As in - what if one is entering an
equation inline like 2 * 2 * 3 = 12?  Or, does one just fall back on using
x?
-- 
Jeffrey P Shell 
www.cuemedia.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Fix broken python on Mac OS X version 10.2

2002-08-26 Thread Jeffrey P Shell

On 8/26/02 11:49 AM, Jens Vagelpohl [EMAIL PROTECTED] wrote:

 well, the basic cause is worse than that: they moved symbols around
 between system libraries.
 
 jens

But nicely, they include Python (2.2, not even 2.2.1) on the Developer Tools
CD.  Finally.

-- 
Jeffrey P Shell 
www.cuemedia.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] DTML and REQUEST data changes about to be checkedin

2002-08-09 Thread Jeffrey P Shell

On 8/9/02 8:43 AM, Toby Dickenson [EMAIL PROTECTED]
wrote:

 I agree it is true in most cases, but not all. Have you analysed how many
 applications will be broken by this? how they can detect the breakage? I
 certainly will not have time to assess the implications on my applications
 before the scheduled release of 2.6.

This is why I raised the flag of can there be a way to disable it?, and
Martijn put a fix in:

 - dtml-var name and dtml.-name; will now automatically HTML-quote
unsafe data taken implictly from the REQUEST object. Data taken
explicitly from the REQUEST object is not affected, as well as any
other data not originating from REQUEST. This can be disabled (at
your own risk!) by setting the environment variable
ZOPE_DTML_REQUEST_AUTOQUOTE to one of 'no', '0', or 'disabled'.

I have the same concerns you do, but I figure that if any problems are found
during normal execution of any Zope release this is attached to that I don't
have time to investigate a fix for myself, I can add this environment
variable (which normally I am not fond of doing), restart, and make a note
investigate fixing site blablabla.  Is there any reason why this solution
wouldn't work for you?
 
 Like I said before, this is probably a good feature. If it was available as a
 patch then I would probably use it on a number of my sites, and would
 recommend it to others. I would be very happy see it (or something like it)
 in 2.7.
 
 But not 2.6.

Oh, 2.6 will never happen anyways ;)  (seriously folks - what's the plan?).

Since there's no current release plan for 2.6, it's hard to plan future
deployments around it anyways.  But if you have any sites you plan to move
to 2.6, you should test this Autoquote change aggressively during the
alpha/beta cycle.  Since the ZOPE_DTML_REQUEST_AUTOQUOTE change has been put
in, I've reserved future judgments until I get a chance to actually do some
testing.  I know that if I do run into any issues in the future that I don't
have time to deal with, I can just flip that switch off.

-- 
Jeffrey P Shell 
www.cuemedia.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] 2.6 / 2.7? (was: DTML and REQUEST data changes about to bechecked in)

2002-08-08 Thread Jeffrey P Shell

On 8/8/02 1:19 PM, Toby Dickenson [EMAIL PROTECTED]
wrote:

 On Thursday 01 Aug 2002 3:46 pm, Martijn Pieters wrote:
 
 Eeek - a week ago. sorry for the late reply.
 
 I am about to land some big changes in the way DTML deals with data taken
 from the REQUEST object when accessed implicitly, in both the Zope Trunk
 and the Zope 2.5 branch.
 
 In my opinion this change is completely unacceptable at this late stage of the
 release cycle. As you said:
 
 These changes could potentially break existing
 Zope sites.
 
 The existing behavior might be flawed, but it is a flaw we have all lived with
 for a long time. In my opinion this needs:
 
 1. To be deferred until the 2.7 cycle.
 
 2. A detailed fishbowl proposal.

Speaking of all this - what's up with 2.6 and 2.7?  2.6a1 is creaking
towards to its two month birthday, and I seem to hear more about 2.7
developments than 2.6 ones lately.  Is there a roadmap / schedule for the
two releases that's up to date?

-- 
Jeffrey P Shell 
www.cuemedia.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: DTML and REQUEST data changes about to bechecked in

2002-08-01 Thread Jeffrey P Shell

On 8/1/02 10:08 AM, Martijn Pieters [EMAIL PROTECTED] wrote:

 On Thu, Aug 01, 2002 at 10:46:44AM -0400, Martijn Pieters wrote:
 I am about to land some big changes in the way DTML deals with data taken
 from the REQUEST object when accessed implicitly, in both the Zope Trunk
 and the Zope 2.5 branch. These changes could potentially break existing
 Zope sites.
 
 It's in. Let the testing begin!

Hopefully I'll get a chance to test it with some of our 2.5 sites - I have a
small worry that old code on small sites that we don't have much worry about
will break if this is put into a 2.5.2 or later release.  Could there be a
way to disable this feature in 2.5 via a z2/environment variable or some
other configuration setting, but have it be automatic in 2.6?  Potential
code breakage and point point release leave me a little worried about
maintaining 2.5 sites.

It may not be an issue - I have to digest the changes in more depth that
I've had (or currently have) time for, but that's the thought that crossed
my mind earlier.

-- 
Jeffrey P Shell 
www.cuemedia.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] Restricted Compiler issues on FreeBSD? (Core Dumps...waaa!)

2002-07-16 Thread Jeffrey P Shell

For a while now, Tracker has been core dumping on my with Zope 2.5.1 with
both Python 2.1.2 and 2.1.3 on FreeBSD 4.5 (Intel).  The culprit seems to be
expressions that are heavy on parenthesis.  For example, the following
works:

!--#let val=(init or (type == 'simple'
and (_['sequence-key']
   not in ['requester',
   'supporter',
   'priority',
   'stage'])
 )) and _['sequence-item']--


But it core dumps when changed to:

!--#let val=((init or (type == 'simple'
and (_['sequence-key']
   not in ['requester',
   'supporter',
   'priority',
   'stage'])
 )) and _['sequence-item'])--


Don't ask me what this expression does - I just kept whittling at it until
the crashes stopped.  Then I went and found quite a few others.  I made a
lot of fixes by turning complex expressions into many smaller ones inside a
single 'let' tag.

Does anyone know other possible fixes for this issue?  Is there some Python
stack size setting I can set at compile time?  I have some other code that
has not survived the move to Zope 2.5.x/Python 2.1.x/FreeBSD.

FWIW, the Python 2.1.2 used was from the BSD Ports, while the 2.1.3 was
compiled by hand.

-- 
Jeffrey P Shell 
www.cuemedia.com




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] Temp Folders and Transient Object Containers

2002-06-20 Thread Jeffrey P Shell

Under the category of feigning smartness by blindly copying what I see, In
a subfolder of the Zope root, I set up a browser_id_manager, a
session_data_manager, a temp folder (cleverly named 'temp_folder'), and put
a Transient Object Container inside that temp folder, named 'tix_sessions'.
Of course, when I restarted Zope, the 'tix_sessions' object itself was gone.

So, why is the default Transient Object Container put in a Temporary Folder?
If I want to use an application specific one that doesn't get lost on
restart, is it OK to put it into a normal persistent folder?

-- 
Jeffrey P Shell 
www.cuemedia.com




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Temp Folders and Transient Object Containers

2002-06-20 Thread Jeffrey P Shell

On 6/20/02 4:01 PM, Chris McDonough [EMAIL PROTECTED] wrote:

 So, why is the default Transient Object Container put in a
 Temporary Folder?
 If I want to use an application specific one that doesn't get lost
 on
 restart, is it OK to put it into a normal persistent folder?
 
 Yup.
 
 The TOC is put into the temp folder mostly because:
 
 1) Sessions are write-intensive and cause bloat on undoing storages
  like FileStorage.
 
 2) Sessions are write-intensive and cause conflicts when accessed
  via a normal ZODB connection.  The temp folder is mounted into
  a database which has a special low conflict connection type
  that ignores read conflict errors.
 
 You will get more conflicts and more bloat if you put a TOC into a
 normal persistent folder (esp. one backed by FileStorage), but it
 will work.  That said, there are a few bugs in the 2.5 transience
 implementation that I'm working on as we speak that might be more
 egregious if you have a truly persistent TOC, so pls. keep an eye
 towards 2.6 (or CVS ;-) in the next few weeks.  You will notice the
 bugs in the form of phantom key errors (not unlike the old Catalog
 bugs ;-)

Oh yes.  Those were fun days!

So, I want to have different TOC's, preferably in non persistent folders
(the site I'm working on could be quite high traffic at times).  A big
problem is - if one is in a temporary folder, it will disappear if Zope ever
restarts.

So, at present, it looks like you can only have one reliable non-persistent
TOC per Zope instance, since that one's always initialized during the time
Zope is checking its root for required objects (Zope 2.5.1
lib/python/OFS/Applicatoin.py (revision 1.179.4.1), starting at line 277).
This could be a rather crappy situation for Zope instances hosting multiple
applications with different Session requirements.  Fortunately for the
project I'm on, I think it will have a dedicated Zope instance.

No one's working on a Kinda Sorta Temporary Folder are they?  ;)  Or, as
Jim might put it Temporary, except for when I don't want it to be.

-- 
Jeffrey P Shell 
www.cuemedia.com




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: [ZPT] Order of attribute execution FeatureRequest

2002-05-13 Thread Jeffrey P Shell

On 5/13/02 1:51 PM, Jim Penny [EMAIL PROTECTED] wrote:

 On Mon, May 13, 2002 at 03:32:21PM -0400, Shane Hathaway wrote:
 Florent Guillaume wrote:
 Jim Penny  [EMAIL PROTECTED] wrote:
 
 Are you referring to what I call magic boolean attributes ?
 
 http://lists.zope.org/pipermail/zpt/2002-March/003013.html
 
 Yes, thanks very much, this is very helpful.  I see that you could find
 no documentation on this, and got no reply.  Is this intended to be a
 permanent feature, or is is experimental?
 
 
 I'm pretty sure it's permanent, only undocumented.
 
 Florent, do you have committer privileges?  You can certainly check in
 documentation of this behavior.  You can also add a comment to the Zope
 book.
 
 http://www.zope.org/Documentation/ZopeBook/AdvZPT.stx
 
 I will write up something and do the feedback thing in the Zope book.
 It seems to me it should be in both the advanced section and the ZPTRef
 section.  Would like a bit of guidance on the Ref writeup, i.e., what
 does ZC want to call it (presumably not magic boolean attributes)?
 

Boolean HTML Attributes perhaps?  From TAL/HTMLTALParser.py ::

BOOLEAN_HTML_ATTRS = [
# List of Boolean attributes in HTML that may be given in
# minimized form (e.g. img ismap rather than img ismap=)
# From http://www.w3.org/TR/xhtml1/#guidelines (C.10)
compact, nowrap, ismap, declare, noshade, checked,
disabled, readonly, multiple, selected, noresize,
defer
]

You should mention that these only get rendered in the classic HTML way when
a page template is in HTML mode (content type equals 'text/html'), which I
presume is the default.

-- 
Jeffrey P Shell
www.cuemedia.com




Industrie Toulouse on Zope
http://radio.weblogs.com/0106123/categories/zope/



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: [ZPT] Order of attribute execution FeatureRequest

2002-05-10 Thread Jeffrey P Shell

On 5/10/02 4:53 AM, Chris Withers [EMAIL PROTECTED] wrote:

 Jim Penny wrote:
 
 on the surface, to be pretty ugly.  I have said that there are three
 specific things I dislike about ZPT -- 0)  lots of things have changed
 spelling again -- request v. REQUEST, here v. context v. container v.
 this v. ? 
 
 Yeah, there was absolutely no need for this and I did find it extremely
 frustrating. That
 said, the whole area has always been a mess, particularly in DTML. I do,
 however, wish
 that Script (Python)'s and ZPT could have been consistent :-((

Me too.  I keep typing 'here' in Python Scripts now.  While I know I can
change the bindings, I'm sure that would just make more confusion for me
down the road.

In regards to request v. REQUEST, I do like the page templates spelling.
'request' is just another path root, and all path roots are lower case.

 1) infix notation that makes program scansion hard,
 
 You don't HAVE to use infix ;-)
 
 tr tal:repeat=x xes
 td tal:content=x/idan ID/td
 /tr
 
 ...can also be written as:
 
 tal:x repeat=x xes
 tr
 tdtal:x replace=x/id//td
 /tr
 /tal:x

I think this is another good feature of ZPT which seems almost like a side
benefit of XML Namespace usage (and instead of 'tal:x', you can also use
more meaningful terms like 'tal:loop').  As for program 'scansion', I don't
view a Page Template as program.  But I think programmer readability can be
achieved just by good formatting.  And when using some HTML tools, whether
they're text oriented, visually, or both, some of them hilight unknown
attributes differently.  GoLive 6 by default colorizes unknown
attributes/tags in orange, while known ones are in blue.  Attribute values
remain in brown.  So, a combination of good formatting and a half decent
editor can yield good usability.  If these are problems for the
pure-programming set, there is still DTML.  And, if anyone can plug in a
good XSLT processor, that could open up another alternative templating
system.  XHTML aware editors should present the least amount of problems, as
namespaces (in theory) shouldn't cause any confusion.

 2) the
 order of operations, which I think is baroque.  Six levels of precendence
 for eight statements is pretty amazing.  And it is certainly harder to
 explain/remember than things happen in the order you specify.
 
 *shrugs* I've done a u-turn on this. Tim's comments make it perfectly obvious
 why this needs to be the case, and at least it is very well defined what order
 things happen in (as Ken pointed out). My only beef is that define sometimes
 happens in an order that is less helpful than it could be ;-)
 
 tal:x repeat=fish fishes
  define=species fish/species
 
 ...doesn't do what I'd like it to ;-)

Evan Simpson explained this to me once in a way that made sense, but I can't
remember what it is right now.

[SNIP!]

-- 
Jeffrey P Shell
www.cuemedia.com




Industrie Toulouse on Zope
http://radio.weblogs.com/0106123/categories/zope/



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] ZPT and 'else'

2002-05-10 Thread Jeffrey P Shell

On 5/10/02 9:25 AM, Marc Lindahl [EMAIL PROTECTED] wrote:

 on 5/10/02 12:47 AM, Jeffrey P Shell at [EMAIL PROTECTED] scrivened:
 
 
 You would need something to close off the 'if' statement, otherwise, a
 document full of 'if' statements and no 'else' ones could fill up a stack
 needlessly.
 
 What's so bad about that?  The stack wouldn't carry over after html/html
 or body/body - couldn't practically more than 1000's - insignificant!

Still, yuck.  It's - for better or worse - not a valid XML way.  Even XSLT
does things like this:

xsl:stylesheet version=1.1
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
  xsl:template match=/
xsl:choose
  xsl:when test=system-property('xsl:version') = 1.1
xsl:exciting-new-1.1-feature/
  /xsl:when
  xsl:otherwise
html
head
  titleXSLT 1.1 required/title
/head
body
  pSorry, this stylesheet requires XSLT 1.1./p
/body
/html
  /xsl:otherwise
/xsl:choose
  /xsl:template
/xsl:stylesheet

xsl:if can stand on its own, but to do the equivalent of else, one has to
use:

xsl:choose
 xsl:when test=expression(template)/xsl:when
 xsl:when test=expression(template)/xsl:when
 xsl:otherwise(template)/xsl:when
/xsl:choose

But, Page Templates are not XSLT.  And I thank gods for that.  XSLT is
powerful, but I wouldn't be able to do the type of work I've been doing this
week with them as easily as I've been able to do them with Page Templates.
I couldn't even have done them as easily using DTML.

 You would at the very least need something like:
 condition
 if.../if
 elif.../elif
 else.../else
 /condition
 
 Which would ensure / cut back on needless growth of stacks and/or global
 variables.
 
 Personally, I think the way Page Templates can do it (via a 'not'
 expression) is fine.  When I used it today (and in the past), I never felt
 myself missing 'else', because there's not really an 'if' to begin with.
 Just conditions.  It keeps TAL light, and lets TALES take on the lifting of
 how to write those conditions.
 
 Point is, it's slow and inefficient, and a clunky syntax.  Reasons the whole
 idea of 'else' was invented in the first place.  I worry, that ZPT is
 benchmarked 4x slower than DTML and it's becoming the standard - not a step
 forward.  And issue like this haven't been satisfactorily resolved.

If speed mattered that much, we'd all still be using C and/or assembly
language.  Scripting Languages have become very standard, even though
they're orders of magnitude slower than their compiled counterparts.  I
don't think it would be any more worth turning Page Templates back into an
imperative programming language than it would be to turn Python into C.  Or
Haskell into Python.  Or J into Lisp.  Or Zope into PHP.   Every language
and platform has its strengths and weaknesses, and I think ZPT's strengths
more than make up for its current speed deficiencies.  I spend less time
debugging and cleaning up Page Template code than I did with DTML,
particularly late-generation DTML.  And the results look *much* better.

I personally can't see a way of having an else (or equivalent of
'xsl:choose') without starting to clutter up the current elegance of Page
Templates, and it has to do with the way Page Templates are designed (and
it's a design that I think is done pretty close to right).  One reason being
that, since all TAL things happen on attributes (it is the 'Template
Attribute Language', and by law all XML attributes have to be quoted, you'd
end up with something like this:

div tal:choose=
 h1 tal:condition=some/expressionYay!/h1
 h1 class=warning tal:otherwise=Boo/h1
/div

The only way out of this is to introduce special TAL tags.  And at that
point, we're back to some of the problems with DTML - 'special markup tags
and the editors the bruise them'.  And at _that_ point, we're out of one of
the intended audiences of Page Templates.

 I think, if it's going to have logic in there, make it sufficiently powerful
 and efficient.  Otherwise get rid of it altogether, unapologetically, and
 require Python for such things

Another option is the XMLC route, which is painful.  XMLC identified every
possible writable element with an id, and id only.  Then, corresponding Java
code could refer to that ID and replace the element with something.  It kept
the visual design side very clean, but the code to do the dynamic generation
could get very ugly.

Or, there's the option is to give up on templating altogether and go with
PHP style syntax, or fill up Python code with:

 s += 'emNo contents available/em'

I personally think Page Templates are rather elegant and a joy to use after
five and a half years of DTML usage.  I keep having to deal with other
solutions like 'tea', 'cheetah', ASP/PSP, and it's just a mess.

-- 
Jeffrey P Shell 
www.cuemedia.com




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo

[Zope-dev] ZPT and 'else'

2002-05-09 Thread Jeffrey P Shell

On 5/9/02 7:07 PM, Tim Hoffman [EMAIL PROTECTED] wrote:

 Just my 2c worth, but I would like to defend order of execution of
 ZPT. What it does mean for me is I can guaruntee zpt commands will
 always be processed in a known order irrespective of where you
 put them in a tag, this I like ;-)

Me too.  Occasional alarms, no surprises.

 What I do miss is else  clause  but I think it would be probably
 be too hard to implement, and too much of encouragement for people
 to start putting more logic in the template, so on the whole it
 is probably best to leave it out.
 
 See ya
 
 T
 On Fri, 2002-05-10 at 05:15, Jim Penny wrote:
 My most-missed DTML feature has not been mentioned at all -- it is not
 loop batching -- it is the dtml-else option of dtml-in -- which made it
 much easier to handle the nothing found case.

'else' is tricky within the block oriented structure of anything XML-ish,
because of the concept of 'well-formedness'.  The 'if' statement would have
to be singly wrapped, and the else block wrapped separately, looking at
least somewhat awkward any way you go about it.  The best I can come up with
in my mind is this, in order to have the 'else' pick up on the condition
expressed in its surrounding container.  But, yuck:

if ...
 true stuff
 else
  false stuff
 /else
/if


A good page template way is something like this:

tal:if condition=myTalesExpression
 truth
/tal:if
tal:else condition=not:myTalesExpression
 false
/tal:else

The 'not' TALES namespace is valuable.  The downside is that you evaluate
the expression twice.  A good way to work within this is something that I
did earlier today, outside of this conversation, where I evaluate an
expression earlier and assign it to a variable:

div id=edit-area
 tal:define=editItems python:here.getMenuItem(...)

  h3Edit Menu Items/h3
  form action=Delete method=post name=actForm
tal:condition=editItems

 ... (form and table elements, and a loop over editItems
  contained in here if there were results) ...

  /form

  div class=emph
   tal:condition=not:editItems
   No menu items available
  /div

/div


This is something I did a lot in DTML too, setting a search result to either
a global variable, or inside of a large dtml-let namescape

-- 
Jeffrey P Shell
www.cuemedia.com

Industrie Toulouse on Zope
http://radio.weblogs.com/0106123/categories/zope/




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] ZPT and 'else'

2002-05-09 Thread Jeffrey P Shell

On 5/9/02 9:39 PM, Marc Lindahl [EMAIL PROTECTED] wrote:

 Yecch!
 
 Why not:
 if ...
 True stuff
 /if
 else
 False stuff
 /else
 
 If leaves around boolean result, else picks up the most recent one... It's
 like they push on a stack so you can nest them Something like that?

You would need something to close off the 'if' statement, otherwise, a
document full of 'if' statements and no 'else' ones could fill up a stack
needlessly.

You would at the very least need something like:
condition
 if.../if
 elif.../elif
 else.../else
/condition

Which would ensure / cut back on needless growth of stacks and/or global
variables.

Personally, I think the way Page Templates can do it (via a 'not'
expression) is fine.  When I used it today (and in the past), I never felt
myself missing 'else', because there's not really an 'if' to begin with.
Just conditions.  It keeps TAL light, and lets TALES take on the lifting of
how to write those conditions.

-- 
Jeffrey P Shell 
www.cuemedia.com




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] updateObjectList for objectManagers?

2002-04-30 Thread Jeffrey P Shell

On 4/30/02 8:27 AM, Lennart Regebro [EMAIL PROTECTED] wrote:

 I have had a couple of problems with an object managers self._objects
 getting out of sync with reality, so that it keeps the wrong names or the
 wrong meta_types in the _objects list.
 Is there an update function that you could call to make it scrap this list
 and rebuild it?

I've never seen this problem.  ObjectManager works best when you use its
API's (_setObject/_setOb, _getOb).  Since normal ObjectManager instances
store subobjects as attributes, it would take some trickery to decide what
was a subobject, and what was just an attribute.  If you're not careful, you
could end up with an even worse list in _objects.

That being said, I imagine it wouldn't be *too* difficult to implement
something like this.  However, since (in theory) an ObjectManager subclass
can change the behavior of the core _getOb/_setOb/_delOb methods to store
subobjects in a different fashion, you'd have to take this into account.
Basically, if you don't trust _objects, how do you get the list of actual
subobjects?

-- 
Jeffrey P Shell 
www.cuemedia.com




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] updateObjectList for objectManagers?

2002-04-30 Thread Jeffrey P Shell

On 4/30/02 10:59 AM, Lennart Regebro [EMAIL PROTECTED] wrote:

 From: Jeffrey P Shell [EMAIL PROTECTED]
 Basically, if you don't trust _objects, how do you get the list of actual
 subobjects?
 
 abel deuring suggested that I would check for a meta_tag attribute on the
 attributes. That might work I guess?

Just be sure to avoid accidental acquisition of the folder's meta_type via
Acquisition.aq_base(attr).

-- 
Jeffrey P Shell 
www.cuemedia.com




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Need to instantiate zclass in location other thancurrent

2002-04-19 Thread Jeffrey P Shell

On 4/17/02 4:49 PM, Max Slimmer [EMAIL PROTECTED] wrote:

 I have created a zclass and want to create a new instance of this class and
 have it be child of some other know object in the tree.
 Given that we know the path (url) to the new prospective parent how do we do
 this.

I do this a lot, with my own custom add in screens that add objects in
special locations.  I have it working like this in a python script::

REQUEST = container.REQUEST
target = context.content.documents   # folder to put the document in

### Create a new instance.
new_item = target.manage_addProduct[
'MyProduct'].MyZClass.createInObjectManager(new_id, REQUEST)
## other operations on the new item
new_item.setTitle('Rockabilly Bob')
...

 A second question. I need to manage lists of these zobjects within other
 instances of the same, is there a reason to store the url vs the object(s).
 I have has some problems getting back a string repr of the object instance
 of ..
 instead of the object?  It would probably be better for me (the code) to
 store objects thus not need to get the object each time I want to call a
 method...

You'll want to store the path to the object.  Making other 'hard' references
to a persistent object in Zope is still a scary proposition.

-- 
Jeffrey P Shell 
www.cuemedia.com




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Speaking of 2.6...

2002-04-17 Thread Jeffrey P Shell

On 4/17/02 9:56 AM, Gary Poster [EMAIL PROTECTED] wrote:

 On Wednesday 17 April 2002 11:48 am, Brian Lloyd wrote:
 
 Ok :) As far as vetting virtual host folder, my concerns
 boil down to:
 
   a. dependency / requirement for ordered folder
 
   b. having yet another virtual host thing in the
  core will confuse people
 
 ...
 
 Hey Brian.  Thanks for your response.
 
 All points understood and appreciated.
 
 And I guess, then, that I'll choose not to make that commitment, since I'm
 looking forward to Zope3 these days anyway.
 
 If folks still want OrderedFolder (or, at least ordering capability) in the
 core I'm still willing to help with that.

I'm a little surprised this hasn't come up for inclusion earlier.  When
showing a site to some top-management folk in a previous life, the question
that came up most often was can we organize those links on the side so that
blablabla is first?.  One person would ask it, I'd respond with the hmmm,
not easily - at least, not in time for our deployment date.  Then the next
person would come in late to the meeting, ask the same question, we'd laugh
and tell them the scenario - to make admin easy, it's just listing the
documents in that folder that are public, using the API's already
available!.  They'd go OK.  The tour continued.  Another straggler comes
in, the loop repeated itself...  :).

For add-to-the-core functionality, I'll vote +0.5.  I wouldn't mind seeing
it in the core, but I also like the idea someone mentioned of a sort of
expansion pack of other good products that was well maintained alongside
each core release.

-- 
Jeffrey P Shell 
www.cuemedia.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: death to index_html; ObjectManager?

2002-04-16 Thread Jeffrey P Shell

On 4/16/02 8:53 AM, Casey Duncan [EMAIL PROTECTED] wrote:

 The implementation adds the API to manage browser default for all
 objectmanagers. However, no browser_default handler is actually added to
 the object unless you specify a default other than index_html
 
 What was the specific undesirable effects you were seeing?
 
 If it is agreed that this management should apply to folders rather than
 all object managers, then I can make this change. In that case using a
 separate mix-in makes sense to me. It could even be registered for use
 as a base class for ZClasses then, which would be some advantage I suppose.

+1 for the separate mix-in.  I use ObjectManager as a base class frequently
for non-folderish objects, for which the whole 'death to index_html' notion
is moot. 

-- 
Jeffrey P Shell 
www.cuemedia.com




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] [RFClet]: What about the request method and theclient side trojan?

2002-04-12 Thread Jeffrey P Shell

On 4/12/02 2:49 AM, Toby Dickenson [EMAIL PROTECTED]
wrote:

 On Thursday 11 April 2002 6:37 pm, Jeffrey P Shell wrote:
 
 On 4/11/02 7:55 AM, Toby Dickenson [EMAIL PROTECTED]
 
 Then you're lucky.  Usually, any time I see dtml-var
 someNonIdempotentMethod(), I immediately change it to the name lookup
 call.  Don't blame me, I've been following this paradigm for years (since
 before there were expr's in DTML).  I would hate to have to special case
 those methods
 
 OK, that kills the second half of my proposal.
 
 (I still think your style is bizarre though ;-)

Personally, I absolutely abhor the difference between
dtml-var foo
And dtml-far foo

It's violently non-obvious and confusing, even to seasoned Zope developers
just glancing over code.  So, personally, my bizarre style is to always
explicitly say 'expr=...', but I try to avoid expr's where necessary to
make life simpler.

Fortunately, there's the happy land of TAL and TALES for me to play in these
days.  :)

 (which I use a lot, usually as accessors, ie:
 
 def Summary(self):
return self.title + self._description
 ).
 
 Aha! maybe not!
 
 That example method definitely is idempotent. Under my proposal it should not
 be declared non-idempotent, and would not have restricted dtml-name-lookup
 semantics. I agree being able to write dtml-var Summary is a good thing
 whether Summary is an attribute or method (and not at all bizarre). I agree
 that changing this would be disasterous.

I have to now admit to not having seen the proposal, I've just been
following along here and struggling to capture the meaning of idempotent
as it applies to Zope security, but I *think* I'm starting to grok it.
Since a search for idempotent on zope.org yields no results, I'm assuming
that your proposal isn't up there (or the catalog is up to its old charms ;)

But now, does this mean I have to go through and tag every method that might
cause a state change?  Or might not?

 Im not sure whether you misunderstood the proposal, or just gave a poor
 example to explain why you thought the proposal is bad.

Since I haven't read the proposal, only the recent mail messages, I'm just
trying to get clearer understanding.  Maybe I'm just having the same sort of
trouble with idempotent versus nonidempotent that I did with mutable and
immutable (for some reason, I unlearned the differences between the two
between CS and the real world, and invented new meanings around the word
'mute' instead of 'mutate').

 My proposal only affects method which have been declared to be
 non-idempotent. This declaration would only be added to methods that change
 externally visible state (in ZODB, Filesystem etc) or have external side
 effects (such as sending an email)
 
 Here is a differnet example. Suppose you write a method:
 
 def setEmptyTitle(self):
   self.title = 'empty'
 
 How would you call it from dtml. I think the 'right' answer is that you
 generally wouldnt call this method from dtml. From a PythonScript maybe, but
 not dtml. However if you did call if from dtml, would you still be using the
 name-lookup form, such as:
 
 dtml-var setEmptyTitle
 
 or would you use
 
 dtml-call setEmptyTitle
 dtml-call setEmptyTitle()
 dtml-var setEmptyTitle()
 
 ?
 
 (Im not going to argue that anyone is 'wrong' to prefer the first form in
 this case. Its my *personal* preference that calling non-idempotent methods
 using the name-lookup form should be caught and reported as an error I am
 wondering whether this preference is shared.)

I think that it could be caught and reported as a Warning, but not an error.
It's been a common thing for a long time, and I think it would be bad to
label it as an error.  Warn first, slap later. :)

Now that I'm understanding things more, I never call non-idempotent methods
(I hope I'm using that term right) from DTML anymore, and when I did it was
always with a dtml-call expr=..., with rare uses of direct name use
(dtml-call ...), usually in regards to SQL methods.  So, it was my
misunderstanding of the proposal.

Overall, I still don't know how I feel about the whole thing.  It's good to
have Zope as secure as possible, but if putting that security makes it
suddenly much harder to develop for or upgrade to/for, I worry about the
support costs involved.

-- 
Jeffrey P Shell 
www.cuemedia.com




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] [RFClet]: What about the request method and theclient side trojan?

2002-04-11 Thread Jeffrey P Shell

On 4/11/02 7:55 AM, Toby Dickenson [EMAIL PROTECTED]
wrote:

 On Thursday 11 April 2002 4:39 pm, Casey Duncan wrote:
 Toby Dickenson wrote:
 [snip]
 
 4. Change dtml to not allow dtml-var someNonIdempotentMethod, although
 it should still allow dtml-var someNonIdempotentMethod()
 
 Ahhh!
 
 How do you propose to do that? I see a lot of bruised foreheads
 resulting from this...
 
 Really? dtml-var someNonIdempotentMethod only works with methods that take
 zero parameters (excluding self). The question is: how many zero parameter
 non-idempotent methods are there?
 
 I have only been able to find one such method in the current Zope cvs, and I
 get similarly optimistic results in my products.

Then you're lucky.  Usually, any time I see dtml-var
someNonIdempotentMethod(), I immediately change it to the name lookup
call.  Don't blame me, I've been following this paradigm for years (since
before there were expr's in DTML).  I would hate to have to special case
those methods (which I use a lot, usually as accessors, ie:

def Summary(self):
return self.title + self._description
).

A powerful feature of classic (pre-expr) DTML was the fact that you could
just use a name, and you didn't have to worry about whether !--#var
Summary-- was a method or an attribute.  For people who have lots of DTML
and Python code based upon these assumptions, mass-breakage upon upgrading
would be a huge detractor against upgrading.  It's hard enough to move some
of our sites from Zope 2.3.3 to 2.5 or even 2.4.x.

-- 
Jeffrey P Shell 
www.cuemedia.com




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: ZMI / JavaScript brainstorm

2002-04-08 Thread Jeffrey P Shell

On 4/8/02 1:17 PM, Martijn Jacobs [EMAIL PROTECTED] wrote:

 What is wrong with editing the files trough FTP / WebDAV? I've mounted a
 complete zopedatabase on a directory, and you can edit all files with
 your favorite editor. Why wanting such editing posibilities in a easy to
 use , in everybrowser working interface like the ZMI?

+1.

The ZMI is really good as an object property browser/inspector - good for
managing a huge suite of objects.  It's not the best content editing
environment, and I'm not sure it should be.  For doing quick edits, it'd be
very annoying having to wait for an Applet to reload/refresh every time I
hit something with a rich text area.

On the other hand, Radio Userland http://radio.userland.com/ has a WYSIWYG
editor built in for its web based editor, with a preference to disable it.
The editor, I believe, is for Windows IE only.

-- 
Jeffrey P Shell 
www.cuemedia.com




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Catalogs, Imports, and Path Awareness (was Re: [Zope-dev] ZClassConstructor Cleanup for 2.6)

2002-04-01 Thread Jeffrey P Shell

On 3/30/02 5:55 AM, Didier Georgieff [EMAIL PROTECTED] wrote:

 On Wed, 2002-03-27 at 17:31, Casey Duncan wrote:
 
 ZClasses have been overlooked enough. Nobody has even bothered
 putting a ZCatalogPathAware available for them...
 
 I've done that locally (changing __init__ and the the py but had no
 chance to make it work with __existing__ ZClasses.
 Something was coded inside the zclass instance ;-
 
 So i had to patch ZCatalog for getting the right behaviour for my
 existing products.
 
 So, even if ZClasses are not cooked completely, they allow guys
 like me to use zope, to promote zopet even if we are useless at
 good python programming ;-), and until Z3 exists.
 
 All my support for ZCatalogPathAware in 2.6.
 
 Maybe we should investigate :
 
 - how updating old CatalogAware ZClasses for taking care of that
 
 - what impact for already updated construtor scripts ? (shuild be
 none, but not sure)

Even with CatalogPathAware (or otherwise smartly cataloged objects), I've
come across a major annoyance that I'm sure others have seen.

The annoyance stems from objects getting re-cataloged somehow upon Import,
so now I've got two entries for each object - one with the correct shortened
Virtual Host friendly path, and one with the big long unfriendly path.  So
now, as I move a site from development to testing to deployment, I have to
run a Python script that goes through the catalog, and removes everything
that has a certain folder in its path, leaving only the correctly cataloged
objects from the previous site in place.  This is especially annoying
because I seem to have to run the script 5-10 times before all of the
re-cataloged-upon-import objects are removed.

If other people have come across this, I think finding a resolution to this
would be a more-than-worthy 2.6 project.  If I'm just smoking crack and it's
only a ZPatterns/TransactionAgents behavior that I'm witnessing, then I'll
just leave my huffing and puffing and whining and yelling and fainting to
myself and immediate coworkers next time I have to go through this
situation.  :/

Oh!  And while on the CatalogPathAware part, documenting how Paths and
SiteRoots and VirtualHostMonsters are all supposed to work together would be
nice.  I still haven't figured it all out, which is currently leaving me
with a few VHM's scattered precariously about a couple of sites.  (:/ ** 2).

-- 
Jeffrey P Shell 
www.cuemedia.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] FW: Catalogs, Imports, and Path Awareness (was Re: [Zope-dev]ZClass Constructor Cleanup for 2.6)

2002-04-01 Thread Jeffrey P Shell

On 4/1/02 5:59 PM, R. David Murray [EMAIL PROTECTED] wrote:

 On Mon, 1 Apr 2002, Jeffrey P Shell wrote:
 If other people have come across this, I think finding a resolution to this
 would be a more-than-worthy 2.6 project.  If I'm just smoking crack and it's
 only a ZPatterns/TransactionAgents behavior that I'm witnessing, then I'll
 just leave my huffing and puffing and whining and yelling and fainting to
 myself and immediate coworkers next time I have to go through this
 situation.  :/
 
 I thought that with ZPatterns one was recommended to avoid the
 Catalog mixins and instead use something like SteveA's
 catalog trigger from ZPAddOns (I think that's the right product
 name).

That's what I did.  But, looking at the import machinery, the newly imported
object is added in to it's parent object with '_setObject', which then goes
and calls self.manage_afterAdd(), which then goes down into all of the
subobjects and calls that.  That's probably the right thing, but it is
what's causing the double cataloging, regardless of how the item is
cataloged.  Catalog*Aware objects call into the catalog during
manage_afterAdd, and I'm sure that the same thing is happening to my WHEN
OBJECT ADDED... triggers as well.

*sigh*.

I've got a few quarter assed solutions in my head, but I don't like any of
them.  Waaa.

-- 
Jeffrey P Shell 
www.cuemedia.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] WebDAV locks disappearing...

2002-03-07 Thread Jeffrey P Shell

A WebDAV client may request a timeout length for a lock, but it's basically
just a suggestion.  You say you investigated again some time later.
Zope's default timeout is thirty minutes.  Clients can ask for longer ones
and Zope will obey, but the 30 minutes is granted for 'infinite' timeout
requests (the spec says that the server may decide the timeout time
independent of the clients request).  The timeout should get refreshed with
every HTTP request made by you (the lock owner).  But the timeout also
exists so that the problem of Person X locks a document for editing, and
then leaves in a hurry (forgetting to release his lock).  Person Y really
needs to edit the document, but it's held hostage by X's lock.

Cadaver may be caching the locks.  Since HTTP/WebDAV are stateless, you have
to refresh your listing in order to see if locks are still there.  Most GUI
based WebDAV clients have a refresh listing option, which is the only way
they can know of new members in a collection and new lock states.

On 3/7/02 11:38 AM, Jerome Alet [EMAIL PROTECTED] wrote:

 Hi,
 
 I've just tested webDAV access for the very first time using cadaver,
 so maybe this is a known problem.
 
 I've locked some objects using cadaver's lock command, and then opened
 a browser keeping cadaver's connection opened.
 
 then I've searched for this locks using the ZMI and also a method of
 my own.
 
 All worked fine, the locks were found.
 
 Then some time later I've retried to find the locks, and both the
 ZMI and my method returned no lock. However in cadaver the locks
 still seemed to be there...
 
 Then I've unlocked the objects and relocked them in cadaver and
 retried, this time the locks were found again...
 
 I hadn't the time to do some more testing but I find this
 surprising.
 
 Does anyone have seen the same problem ?
 
 FYI Zope 2.5.0 + Python 2.1.2 both up-to-date Debian Woody
 packages.

-- 
Jeffrey P Shell 
www.cuemedia.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] improved logging

2002-03-01 Thread Jeffrey P Shell

See PEP 282 [1].  If this PEP is accepted, work should probably follow its
course.  It would be nice to have a single logging mechanism for Python, and
for Zope to use and/or extend it.  Granted, if it is accepted, it won't be
in Python until Python 2.3 which I believe is due in August.

..[1] http://python.sourceforge.net/peps/pep-0282.html

On 2/28/02 3:34 PM, Romain Slootmaekers [EMAIL PROTECTED] wrote:

 
 Yo,
 questions wrt logging:
 
 -) What are the plans to improve the rather primitive logging facilities
 in zope ?
 I couldn't find anything in the plan for 2.6, nor on the 3.0 homepage.
 I think we need at least an extendibl framework with following types of
 components:
 
 - Loggers (fi, file logger, db loggers, remote logger, nulllogger,...)
 - Filters (fi on severity, on subsystem, ...)
 - LogBus (central accesspoint for the logging framework,
 where you can (dynamically) hook your loggers, filters etc...
 
 if time is an issue, we could just copy the design of fi Log4J which is a
 good logging framework for apache.
 
 -) If there are no such plans, can we hack something up ourselves and
 add/donate it to the product ? I hate writing stuff that gets replaced by
 something else afterwards 
 
 input appreciated.
 
 Sloot.

-- 
Jeffrey P Shell 
www.cuemedia.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Zope 2.6 planning - call for contributors!

2002-03-01 Thread Jeffrey P Shell

On 3/1/02 7:30 AM, Chris McDonough [EMAIL PROTECTED] wrote:

 I'd suggest starting with the combination of Evan's zopemake and zctl
 scripts.  One thing that zopemake could be extended with is an
 autoconf-style configure that figures out where the appropriate version of
 Python is, which C compiler to use, etc.

Can't the distutils framework be used?  It's got all of the utilities to
deal with various platform issues already.

-- 
Jeffrey P Shell 
www.cuemedia.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Dynpersist.so and makefile.pre.in

2002-01-31 Thread Jeffrey P Shell

On 1/31/02 5:02 PM, Ed Colmar [EMAIL PROTECTED] wrote:

 Huh...
 
 I found a makefile.pre.in, but I'm seeing tons of errors on make
 
 There was some note in the Zpatterns docs that after zope2.2 the dynpersist
 woudn't be neccesary anymore.  Is this true?

It seems like it should be true.  To the best of my knowledge, DynPersist
got around the issue that it wasn't all-too-safe to override __getattr__ and
__setattr__ for persistent objects.  I know that this issue was fixed in the
ZODB, probably around the time of Zope 2.2.  However, even in the most
recent ZPatterns releases (as maintained in the 'TransactionAgents'
package), some Python code still seems to depend on DynPersist.
 
 Are there any other (simple) solutions to doing authentication through a SQL
 DB?  Jumping through hoops to get Zpatterns working seems silly when all I
 need is basic authentication.  Though it would probably make my life easier
 once I figure it out.

You might want to check out http://www.zope.org/Members/otto/userdb,
although it looks rather old.  If it's what I think it is, it's based on
something done at Zope Corp back in the Principia (Zope before it was Zope)
days.  UserDb was a pretty simple system that might work for you if it still
works.  Much easier than anything ZPatterns based - especially given that
ZPatterns has gone relatively unmaintained for so long.

-- 
Jeffrey P Shell 
www.cuemedia.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Defining Interfaces

2002-01-30 Thread Jeffrey P Shell

On 1/30/02 4:08 AM, Toby Dickenson
[EMAIL PROTECTED] wrote:

 On Mon, 28 Jan 2002 16:37:16 -0700, Jeffrey P Shell
 [EMAIL PROTECTED] wrote:
 
 Many convincing arguments, but somehow I am not persuaded.
 
 Or, if you were defining the interface in IDL (mmm,
 almost-avoiding-redundancy through acronyms!) with the target language being
 Python, would you include self?
 
 But what if you were defining an interface as a Python class, with the
 target language being anything except python. Would you include
 self?

I'm saying that you wouldn't.  The point of IDL/ISL is that you wouldn't,
because the interface that you're specifying is independent of the target
language.

 I think my conclusion here is that using python classes to define
 interfaces may be counterproductive.

It may be the best we have (it's best understood by the target development
audience), unless PEP 245 [1] gets accepted into Python.  You can also
declare interfaces in a more declarative fashion, but I do have to say that
the class way is preferable.  Contrast::

 meths = {'sayHello': Interface.Method(Says hello to the user),}
 IHello = Interface.new('IHello', [], meths)
 IHello.names()
['sayHello']

Is basically the same as:
 class IHello2(Interface.Base):
...   def sayHello():
... Says hello to the user
... 
 IHello2.names()
['sayHello']

..[1] http://python.sourceforge.net/peps/pep-0245.html

-- 
Jeffrey P Shell 
www.cuemedia.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Defining Interfaces

2002-01-28 Thread Jeffrey P Shell

On 1/28/02 8:17 AM, Chris Withers [EMAIL PROTECTED] wrote:

 Jeffrey P Shell wrote:
 
 On 1/27/02 11:25 AM, Steve Alexander [EMAIL PROTECTED] wrote:
 
 Hi folks,
 
 When I define an Interface, are the methods of the interface supposed to
 have self as the first argument?
 
 No.
 
 Can you expand on this a little?
 
 It doesn't make sense to me to exclude 'self'...

Jim [Fulton] explained it to me once.  He can explain it better than I can.
But think of it this way -- theoretically, an interface can be implemented
by a folder full of Python scripts as [relatively] easily as it can be
implemented by a class.  Should you then include all of the binding options
(context, container, etc)?

Or, if you were defining the interface in IDL (mmm,
almost-avoiding-redundancy through acronyms!) with the target language being
Python, would you include self?

An interface defines a contract on the usage of an object/component; it's
not necessarily a specification on how to implement it.  The concept of
'self' as the first argument for instance methods is a product of
implementing in a Python class (not to mention that 'self' is not a required
name, just an extremely common convention.  You could use 'this' just as
easily).  

The big theory behind most component models is that the implementation
shouldn't matter so long as certain interfaces are satisfied.  And the
following simple interface could be satisfied a number of ways in Zope
already - by a normal Python class implementation; by a folder with a Python
Script or External Method; by a ZClass with the same; or (in Python 2.2) by
a class with a static method (which would have no 'self').

class ISubscriber(Base):
 Subscriber base interface 
def EventService_inform(event):
 Informs the subscriber that the event has occurred 

-- 
Jeffrey P Shell 
www.cuemedia.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Defining Interfaces

2002-01-27 Thread Jeffrey P Shell

On 1/27/02 11:25 AM, Steve Alexander [EMAIL PROTECTED] wrote:

 Hi folks,
 
 When I define an Interface, are the methods of the interface supposed to
 have self as the first argument?

No.

 It certainly seems that way from
 ./lib/python/AccessControl/IUserFolder.py in Zope2.  It also seems that
 way from the Interface Interface.
 
 However, many of the interfaces in Zope3 omit the self argument.

-- 
Jeffrey P Shell 
www.cuemedia.com



Sent using the Entourage X Test Drive.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Defining Interfaces

2002-01-27 Thread Jeffrey P Shell

On 1/27/02 3:09 PM, Steve Alexander [EMAIL PROTECTED] wrote:

 In which case, perhaps we should change InterfaceInterface and
 InterfaceBaseInterface from Interface/iclass.py to reflect this.
 
 The ZDG should also be updated to reflect this, as the example is wrong.
 
  http://www.zope.org/Documentation/ZDG/ComponentsAndInterfaces.stx
 
 from Interface import Base
 
  class Hello(Base):
   The Hello interface provides greetings. 
 
  def hello(self, name):
   Say hello to the name 
 
  class HelloComponent:
 
  __implements__ = Hello
 
  def hello(self, name):
  return hello %s! % name
 
 
 Shall I throw this into the Collector?

Probably.  I made a comment on the page itself, just a couple of days ago,
but it's unknown how often those comments are reviewed:


 jshell - Jan. 24, 2002 12:56 pm - This should all be updated to reflect where
 interfaces are going for Zope 3. First, the interface should be named
 IHello, and there should be no 'self' in the signature for the 'hello()'
 method. 


-- 
Jeffrey P Shell 
www.cuemedia.com



Sent using the Entourage X Test Drive.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] FYI: Sprint schedule online

2002-01-15 Thread Jeffrey P Shell


On Tuesday, January 15, 2002, at 07:45  AM, Paul Everitt wrote:


 Whew, at long last, I've posted a Sprint Schedule at:

 http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SprintSchedule

 Boy, that URL is too long.  I edited the dev.zope.org homepage to 
 add links to the Zope3 page and the sprint schedule.  This page 
 also answers the question, What is a sprint?

You of all people better not be whining about Zope URLs!  ;)

Jeffrey P Shell, [EMAIL PROTECTED]


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] References, persistence, BTrees

2002-01-03 Thread Jeffrey P Shell

I'm experimenting with an event notification service based on a 
publish-subscribe model for some projects I'm working on.  When a 
subscription comes in, a 'Subscription' object is made, that 
basically looks like this:

class Subscription(Base):
 def __init__(self, subscriber, eventType, filter=None):
 self.subscriber = subscriber
 self.eventType = eventType
 self.filter = filter

 def __hash__(self):
 return hash(self.subscriber)  \
hash(self.eventType)  \
hash(self.filter)

'subscriber' is a reference to the subscribing object, and it's 
very likely to be to an object in the ZODB.  Is it wise to have 
more than one persistent reference to a single persistent object?  
I swear that I had once heard Jim say (vocally) that you could do 
references like this in the ZODB now.  I'm trying to avoid using 
Paths because objects have a tendency to move around[*], and I have 
performance concerns for a single event service object to have to 
call 'unrestrictedTraverse' to every subscriber.

[*] (it's due to the annoyances with manage_beforeDelete() and 
friends that
I'm writing this tool.)

Second question: If I use the hash of the Subscription as a key, is 
there any advantages/disadvantages with using an IOBTree to hold 
Subscription objects instead of a PersistentMapping?

Jeffrey P Shell, [EMAIL PROTECTED]


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Open Letters and Zope 3

2001-12-04 Thread Jeffrey P Shell

On Tuesday, December 4, 2001, at 06:37  AM, Joseph Wayne Norton wrote:

[SNIP[
 p.s. It is my own personal taste but I don't really care for the tkgui
 interface for running the zope test suite.  Any possibilites of making
 the test suite run in a fashion similar to the python installation
 test suite?


You can run unittest.py directly.  Instead of doing python2.2 
utilities/unittestgui.py ..., do python2.2 
/usr/local/lib/python2.2/unittest.py ... (based on wherever your 
python2.2 libraries are).

It works just the same.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Open Letter to zope-dev

2001-11-30 Thread Jeffrey P Shell
 
software shortcomings that may exist as much as any of us in the 
community.  Give them some credit for the great work that they do.  
They've given up more for the cause of keeping Zope Open Source 
than most people will ever truely realize.  And, after I'm done 
dealing with my current situation, I'd be willing to head back east 
for them again if they'll have me.  :)

Jeffrey P Shell, [EMAIL PROTECTED]


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Catalog improvements

2001-11-21 Thread Jeffrey P Shell


On Tuesday, November 20, 2001, at 03:35  PM, Wolfram Kerber wrote:

 Hi,

 i'm currently working on a product that allows to attach relational
 information to zope-objects. It works quite well so far, but to further
 enhance it i need to make some changes to the Catalog. I could perhaps
 implement it as a separate product, but i strongly feel that those 
 changes
 are best applied to the Catalog itself, as they are of general use 
 (i think)
 and involve a lot of changes to the inner workings of the Catalog. In
 particular i need the following:

 - named/stored queries
 these are precompiled queries, so they can be executed without 
 parsing and
 are easily cacheable
 i.e. similar to what is implemented in CMFTopic, but stored in the 
 Catalog
 and a bit smarter

There used to be something like this in ZTables/Tabula (a Zope 1.x 
product that was sort of the genesis of the Catalog, for better or 
worse) called 'Hierarchies'.  Hierarchies were actually indexes (I 
think the current Keyword index is descended from the Keyword 
Hierarchy).

I don't know what happened to that code.  If it's not available, 
you could probably achieve the effect that you're looking for here 
with PluginIndexes, which wouldn't require changing the Catalog at 
all.  Just write a Query Index that indexes objects that match 
its pre-cooked Query.  This would speed up searching tremendously, 
but you could take a big hit at indexing time if you have many of 
them.

Jeffrey P Shell, [EMAIL PROTECTED]


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] PathIndex query options

2001-11-19 Thread Jeffrey P Shell

I've looked hard at the two pages returned for PathIndex on 
Zope.org, and cannot make sense out of how to use 'level'.  From 
the example, which is full of paths like '/aa/bb/cc' and 
'/cc/bb/cc' - all of the same size and using the same three 
letters -, I cannot tell if I can do a path query to find objects 
ONLY in a certain path, and not above or below it.

I have a situation where I have a hierarchy of Task content 
objects, and in one case I only want to display the immediate child 
tasks at certain paths (basically to top-level tasks), using the 
catalog query except for (hopefully) one changed parameter.

http://www.zope.org/Members/michel/ZB/SearchingZCatalog.dtml
http://www.zope.org//Wikis/DevSite/Proposals/PathIndexDocumentation

Jeffrey P Shell, [EMAIL PROTECTED]


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] WebDAV API

2001-11-01 Thread Jeffrey P Shell

On Thursday, November 1, 2001, at 05:20  PM, Dethe Elza wrote:
 Because many existing Windows programs understand FTP but not 
 WebDAV, we're trying to create an alternative way to lock/unlock 
 files when we FTP them.  This could be a simple HTTP call 
 (preferred) or XML-RPC. The documentation I've been able to dig up 
 on Zope's DAV implementation isn't too clear on how to 
 programmatically lock/unlock files.

 I can easily check if a file is locked using DTML Methods, but 
 actually locking it has eluded me.  Do I have to create a Lock 
 object first?  At first wl_lockItems, wl_lockTokens, and 
 wl_getLock all looked like methods to create a lock, but they seem 
 to be methods for retrieving existing locks, wl_setLock seems to 
 be what I want but I don't see how to create a token or a lock 
 item.  Can I do this in a DTML Method?

When the WebDAV writelocking project was in its early stages, some 
debate went to whether the locking mechanism should be exposed to a 
higher level, and what that mechanism would be.  Ultimately, 
however, it was decided that WebDAV writelocking would be kept 
entirely within the WebDAV system.  It's not recommended that you 
try to use these outside of that, primarily due to the importance 
of the 'locktoken' objects, which you need to understand in order 
to use wl_setLock() and other methods.



Jeffrey P Shell, [EMAIL PROTECTED]


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] WebDAV API

2001-11-01 Thread Jeffrey P Shell

On Thursday, November 1, 2001, at 06:53  PM, Dethe Elza wrote:

 Andreas Jung wrote:

 See Lockable.py and LockItem.py.


 OK, I was confused and thought an object could serve as it's own 
 lock (Java does something like this).  So I need to create a 
 LockItem.  Is this class accessible from  a DTML Method or should 
 I be looking at an External Method?

An external method.

LockItems basically model all of the data required by WebDAV to 
represent what is expected in a WebDAV lockdiscovery property.  
An object cannot serve as its own lock as there is not a larger 
locking mechanism in play here - only the WebDAV system.  Thus, 
LockItems are very WebDAV specific - 'exclusive write lock' 
specific in fact.

See also webdav/davcmds.py, classes Lock and Unlock to see how 
the locks are created and applied.


You might also want to check out the seatbelt mechanism in the 
CMF's Document class as an alternate approach.

Jeffrey P Shell, [EMAIL PROTECTED]


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] _getOb or __getattr__?

2001-02-27 Thread Jeffrey P Shell

"Chris Withers" [EMAIL PROTECTED] wrote:

 Jeffrey P Shell wrote:
 
 _getOb and _setOb are for placing subobjects somewhere besides attributes
 (which is the default implementation).
 
 When would __getattr__ be used then?
 

In what context?  You could wire __getattr__ to call into _getOb (and
probably __getitem__ too, since that's also used in traversal and as a way
of getting non-Pythonic ID'd objects).

def __getattr__(self, attr):
return self._getOb(attr)

Until very recently, __getattr__ on persistent objects was like playing with
nuclear fire.  But now, I *believe* it behaves properly, which means
__getattr__ gets called when it receives an unknown name.  How that affects
Acquisition, I don't know.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope] ZopeLDAP 1.1.0 release

2000-12-18 Thread Jeffrey P Shell

"ZopeLDAP 1.1.0", http://www.zope.org/Members/jshell/ZopeLDAP/ is released,
bringing in a bevy of changes, including:

 o New ability to run in a non-transactional mode (this is critical to avoid
   a known bug when updating more than one entry object per transaction)

 o Much improved Entry object API that is Python Scripting\DTML Scripting
   friendly

 o Some new documentation (not yet in help system format though) about
   programming Entry objects.

The *manage_* style of programming Entry objects has not changed, but the
core API has.  Anything using methods like '_set()', '_addSubentry()' will
be affected.


___
Zope maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )




[Zope-dev] Re: [Geeks] Interface Meta Data proposal

2000-11-28 Thread Jeffrey P Shell

On 11/28/00 4:05 PM, "Michel Pelletier" [EMAIL PROTECTED] wrote:

 
 I've added a sub-proposal to the Interface proposal for describing
 additional meta-data with Interface objects:
 
 http://www.zope.org/Wikis/Interfaces/ExtesableMetaData
 
 Please comment about this interesting possibility.
 
 -Michel
 

Without these things being supported more in the core language, it seems
quite awkward.  Being able to do the followng is nice:

class ILockToken(Interface.Base):
def frame(self, width, height):
"a frame"

class LockToken:
__implements__ = ILocktoken,
...

The following would (will?) be better:

interface ILockToken:
def frame(...):

class LockToken implements(ILockToken):
...

But I'm not sure how one would go about setting your meta-data in a way that
is at all natural to Python.  I think that exceptions that a method
must\should raise *should* be part of a signature\contract.  This is one of
the really cool things about Java.  If you use a method, 'readFile' that
says it raises IOError, you *HAVE* to catch that exception (I believe in
order to compile).  But it looks like what you're really wanting is to use
interfaces for documentation purposes, not for contract purposes.  Not for
interfaces at this level of the language.

I'm guessing along your proposal, to state that a method raises ValueError
or Attribute I'd have to do the following?:

class ILockToken(Interface.Base):
def frame(self, width, height):
"a frame"
frame.setMetaData('exceptions', (ValueError, AttributeError))

...

Meta Data is a deadly term.  Be careful with it.
Anyways, I doubt we want to invent our own IDL (no!) or reinvent Eiffel
(specifying pre and post conditions are only truely useful if they're
enforced, and without this enforcement in the core language I imagine that
could be expensive. They're a good thing for large systems, but Python
doesn't support them automatically), so it seems that this information seems
to be best put in the documentation (since doc strings in an Interface don't
also mean "Publish Me!", they can be used to document!).

Interfaces are contracts and pretty darn good ways of specifying parts of
the system, but don't confuse them with headers in C\C++\Objective C.
'IObjectManager' is a critical interface for Zope (so instead of having
attributes like 'isPrincpiaFolderish', we can ask
'IObjectManager.implementedBy(fooObject)'.  Folder, on the other hand, is an
important class in Zope, but is primarily an amalgam of classes implementing
important Interfaces (ICopyable, IPropertyManager).  It's unlikely that
we'll really have a need for a Folder Interface, because what's important
about Folder's is that they implement ObjectManager behaviors and
CopySupport behaviors.

To bring Java back into play here for a moment, a simple example is the
interface 'Cloneable'.  By implementing 'Cloneable', well then..  when it's
time to clone, you can be cloned.  If you don't say you implement
'Cloneable', an exception gets raised (even if you implement the proper
method).  This is similar to how we sniff things today, but we just do
things like 'if hasattr(obj, "cb_isCopyable") and obj.cb_isCopyable()):'

I get the feeling sometimes that what you want with interfaces is actually a
bit closer to what Objective C does with the word Interface.  And that is
that in Foo.h, you have the interface for class Foo:

@interface Foo {
...

And in Foo.m, you have the implementation:

@implementation Foo {
...

These interfaces are header files, and they're damn nice to use for
documentation since the specification of the class is separate from the
implementation.  But they don't imply contracts in the way that Java's use
of the word Interface does.  (Some implementations of Objective C call those
things Protocols).

Both needs are valid, but I think we'll benefit most from the first
(contracts).  In order to make those work, we probably shouldn't make them
too foreign to specify, or the incentives to write them go way down (as is
evidenced by the amount of doc strings that go """ """ or "XXX: Fill in
later", getting developers to fill in too much 'meta data' is hard).

But if we can get some of the information in your proposal more integrated
with the language, I think it would be beneficial.

Jeffrey P Shell, [EMAIL PROTECTED]
http://www.digicool.com/ | http://www.zope.org


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope] re: requests for some dtml tags

2000-11-14 Thread Jeffrey P Shell

 From: jacintha menezes  [EMAIL PROTECTED]
 
 Hi,
  Is there any dtml tags for creating a new work space also for locking
 some page.Locking some page in the sense for second user the operations in
 that page should not be processed
 unless the process for first user is completed.If there dtml tags for these
 kindly give me
 those tags.
 
 waiting for your reply.

Regarding locking:

Do you mean in the sense that if person A wants to edit a page (like a Wiki
page), person B shouldn't be able to update the page until person A clicks
"Submit changes"?  The WriteLocking project (see the Projects area on
http://dev.zope.org/) will include an API that can be called, even from DTML
(with proper permissions), to grant an exclusive write lock to a user.

If you mean you want to protect against two HTTP requests that are operating
on the same page\object from overwriting each other in process, the built in
ZODB\ZPublisher transaction handling that's been in Zope before there was
Zope takes care of this automatically.  A REQUEST-RESPONSE cycle is treated
as a single transaction.

Jeffrey P Shell, [EMAIL PROTECTED]
http://www.digicool.com/ | http://www.zope.org



___
Zope maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )




Re: [Zope-dev] Tag DTML

2000-11-02 Thread Jeffrey P Shell

On 11/2/2000 3:12 PM, "Aitor Grajal Crespo" [EMAIL PROTECTED]
wrote:

 
 Yeahhh, thanks.
 
 But , one more step.:-) can i do it in the init method ???
 The init method no have the md parameter. no???
 

No, __init__ is called at parse time and has no knowledge of the surrounding
environment.  render\__call__ is called at render time when the namespace
becomes important.

Jeffrey P Shell, [EMAIL PROTECTED]
http://www.digicool.com/ | http://www.zope.org



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] WriteLocking RiskFactors updated

2000-10-24 Thread Jeffrey P Shell


The WriteLocking RiskFactors artifact has had some new work done on it and
I'm interested in some editorial comments and review before work begins on
Architecture and UseCases.
 http://dev.zope.org/Wikis/DevSite/Projects/WriteLocking/RiskFactors

Make any comments you have at:
 http://dev.zope.org/Wikis/DevSite/Projects/WriteLocking/ProjectDiscussion

--
Jeffrey P Shell, [EMAIL PROTECTED]
http://www.zope.org/ | http://www.digicool.com/


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




Re: [Zope-dev] Meaning :-S

2000-10-23 Thread Jeffrey P Shell

On 10/23/2000 11:37 AM, "Chris Withers" [EMAIL PROTECTED] wrote:

 ...yeah, Zopelet means absolutely nothing, and will just add to
 confusion :-(

The worse confusion is choosing a name that means something and then either

 o Having to explain that it means different things in different contexts,
   even within Zope.  (This is a bigger problem with the name Method than
   the whole binding issue.  Ditto for script.  Instructing a user to
   write a Python Script will cause a Python programmer to go to the file
   system).

 o Having to explain "it's like ... but different..."  This was apparently
   one of the other problems with the name Method, in that PythonMethods
   (the through-the-web variety) may or may not behave like traditional
   Methods in programming languages.

This is especially bad when the code is Python since Python is also what we
develop in.  Python can now exist in many places in Zope (web, Extensions/,
and Products (disk based)).  External Methods were a nice name in that they
connoted that it was a chunk of code that was external to Zope (at least the
ZODB).  The use of 'method' can come back into issue regarding how they got
bound (ugh), but the External bit fit.  If I was told "write an External
method", I knew what that meant.  When*ever* I hear someone mention writing
a new python method to do something, it has to be qualified with "you mean
in a product\class on the file system or a _PythonMethod_?"

Function, Script..  They all fall prey to the same thing.

Zopelets follows the cute naming of Applet, Servlet, Scriptlet...
(IE has Scriptlets).  I'm not advocating it entirely, but it follows a nice
silly tradition in a way that is explainable - small chunks of Zope code
managed through the web.  And they happen to be in Python. (or could be
predicated by the language of choice).

Jeffrey P Shell, [EMAIL PROTECTED]
http://www.digicool.com/ | http://www.zope.org



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] WriteLocking Project Initialized

2000-10-19 Thread Jeffrey P Shell

http://dev.zope.org/Wikis/DevSite/Projects/WriteLocking/FrontPage

WriteLocking became a full fledged Fishbowl Project this week, and I've been
spending the past couple of days getting the initial Artifacts and structure
of the Project site together.  The current structure should stand through
elaboration.  There is no planned schedule yet as the Risks themselves are
still being scoped out and the UseCases haven't even been started on yet,
but it is currently planned to get the proposed functionality into Zope 2.3.

The main pages of interest right now are:

VisionStatement (what the project is about, from the original proposal)
 http://dev.zope.org/Wikis/DevSite/Projects/WriteLocking/VisionStatement

RecentChanges
 http://dev.zope.org/Wikis/DevSite/Projects/WriteLocking/RecentChanges

CurrentStatus (I really will work on keeping this up to date)
 http://dev.zope.org/Wikis/DevSite/Projects/WriteLocking/CurrentStatus

There are other pages outlining

 o RiskFactors (this is the one most actively being worked on right now),
 o TargetClients (LOCKing WebDAV clients we're planning to test against),
 o ProjectGlossary (Terms and definitions)

And the general ProjectDiscussion page at
 http://dev.zope.org/Wikis/DevSite/Projects/WriteLocking/ProjectDiscussion

I ask that if you make comments on the proposal to either do them on the
ProjectDiscussion page or on the [EMAIL PROTECTED] list.  Please read the
Scope section of the VisionStatement first, which outlines both what the
intended goals Are and Are Not.

Remember that the project is still in the early stages of Elaboration, and
some of the artifacts are incomplete.  In light of this election season, I
pledge to you I will try my hardest to go to work 50+ miles south of
Washington and fight to keep the information flowing through the Wiki
updated and available to ALL Zope people, everywhere.  No fuzzy math in
these parts!


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




Re: [Zope-dev] Typo in Version.py

2000-10-18 Thread Jeffrey P Shell

On 10/18/2000 9:04 AM, "Greg Ward" [EMAIL PROTECTED] wrote:

 Now if only I could figure out why Zope is trying to raise that
 exception on me... (I'm not deleting a version, I'm just renaming
 something within a version!)
 
   Greg

Because Rename deletes.  The basic sequence of a renameObject command is (in
short):

In short, it:
1.Gets the object off of the objectmanager using the old id.
2.Deletes it from the objectmanager (doesn't delete the object
  itself!).
3.Changes the id of the object.
4.Adds it back to the objectmanager with the new id.

The detailed version is:
1.Check ID (is the new id invalid or already used?), raise
  Invalid ID if so.
2.Get the object using _getOb
3.Check if object supports copying\moving using cb_isMoveable,
  raise CopyError
4.Use _verifyObjectPaste (Does some verification to make sure the
  user.
5.Try to notify recipient of the copy (in this case "self" - the
  ObjectManager or other CopySupport-subclassed class instance),
  if that fails, raise a Rename Error.
6.Delete the object off of the object manager (self._delObject)
7.If possible, get the aq_base of the object, then set the objects
  id to the new id.
8.Set the modified object on the ObjectManager, leaving the ownership
  info unchanged.  (self._setObject).


Jeffrey P Shell, [EMAIL PROTECTED]
http://www.digicool.com/ | http://www.zope.org



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




Re: [Zope-dev] Typo in Version.py

2000-10-18 Thread Jeffrey P Shell

On 10/18/2000 9:27 AM, "Jeffrey P Shell" [EMAIL PROTECTED] wrote:

 On 10/18/2000 9:04 AM, "Greg Ward" [EMAIL PROTECTED] wrote:
 
 Now if only I could figure out why Zope is trying to raise that
 exception on me... (I'm not deleting a version, I'm just renaming
 something within a version!)
 
   Greg
 
 Because Rename deletes.  The basic sequence of a renameObject command is (in
 short):

Actually, I'm not sure what you're asking here: are you renaming the Version
object itself?  Or renaming something else while inside the version?

Jeffrey P Shell, [EMAIL PROTECTED]
http://www.digicool.com/ | http://www.zope.org



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] Writelocking Proposal rev 3.1

2000-10-16 Thread Jeffrey P Shell

http://dev.zope.org/Wikis/DevSite/Proposals/WriteLocking

The proposal has been updated with a new deliverable discussing
documentation as noted and requested by Brian.


Jeffrey P Shell, [EMAIL PROTECTED]
http://www.digicool.com/ | http://www.zope.org




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] WriteLocking Proposal Revisited. Again.

2000-10-13 Thread Jeffrey P Shell

WriteLocking http://dev.zope.org/Wikis/DevSite/Proposals/WriteLocking

Revisited and rewritten again after some internal discussions and a decision
to ensure that the proposed Write Locking for WebDAV behaves in a matter
that the clients (particularly the more popular ones) expect.  There's less
architectural discussion in this revision of the proposal, intentionally.

--jeffrey


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] Locking (supercedes original writelocking proposal)

2000-10-06 Thread Jeffrey P Shell

This supercedes the original WriteLocking proposal which was initially just
to cover WebDAV's current write locking ability.

http://dev.zope.org/Wikis/DevSite/Proposals/WriteLocking

-- 
Jeffrey P Shell, [EMAIL PROTECTED]
http://www.zope.org/


































 

.oO


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )