Re: [Zope-dev] why cant i rename an object from an external method

[Shane Hathaway]

Andy McKay wrote:
> 
> Heres a treat. I'm trying to write an external method to rename objects. I
> have approx 10,000 to rename so a script would be nice. No problem I
> thought, imitate a forms manage_renameObject and CopySupport.py can do the
> work.
> 
> Rename works fine from the web form, but not from a script.
> (ASPNTools.getsomeobjectsfromstring returns a bunch of objects, Ive tried
> replicating this with resolve_url and get different namespace error, could
> this be a clue?).

I would try using _delObject and _setObject instead. 
manage_renameObject() does some security checks that don't apply in your
case.

Shane

___
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] I feel your Wiki Pain ;-)

[Karl Anderson]

Martijn Faassen <[EMAIL PROTECTED]> writes:

> I think you could integrate both mailinglists and wikis. On the one
> hand, often we'd like to preserve a good posting in a mailing list as
> a wiki page. So we make a separate [EMAIL PROTECTED] address that's subscribed
> to the mailing list, that keeps listening to the list and sees things
> like this in postings:
> 
> Wiki:StructuredTextWiki:FooBarPage
> 
> This is a bunch of text that should be added to FooBarPage.
> 
> Wiki:end

Check out the MonkeyFist blog at  -
it's generated by scanning their IRC channel.

-- 
Karl Anderson  [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] mailing list 'noise'

[Karl Anderson]

Ken Manheimer <[EMAIL PROTECTED]> writes:

> On Thu, 28 Sep 2000, Chris Withers wrote:
> 
> > Toby Dickenson wrote:
> > > I dont see this as a problem: You only create a new list when the
> > > traffic for that proposal gets too great for zope-dev. Threading is
> > > good enough before that point.
> > 
> > Yes, but zope-dev has a relatively high traffic load... Why should you
> > have to put up with all that 'noise' if you're only interested in posts
> > for your comparatively small discussion?
> 
> Yeah - maillists flow by, and not everyone can follow all the traffic all
> the time!! The cool thing about "content-based" mailling lists, where
> people can subscribe to notifications about changes in subthreads, is that
> you just subscribe to the part of the discussion that has your interests!!

I haven't understood this gripe ever since I started reading mail with
Gnus.  Before anyone groans, I'm not sure that Gnus is ready for
general use by anyone who doesn't want to learn elisp - but surely
there's anther reader with these features?

The point that I'm trying to make is that a mailing list has all the
strucure needed to keep abreast of an important thread.  I don't think
it's perfect when you can't afford to miss a single important article,
but it works great for general lists.

Gnus treats mail & news as the same, and allows you to score posters,
threads, messages, etc. both manually and adaptively.  Threads can be
presented by order of their score.  Adaptive scoring is what really
makes it work.  The normal reading commands - read article, kill
thread, save article, catchup (mark unread articles as read) can
affect the scores.  So, reading articles in a thread tends to make it
float to the top, and posters who contribute to well-read threads
elevate future threads that they contribute to.  The inverse for
killed threads, less so for caught up threads.

I can read comp.lang.python when it has 3000 unread articles, by
skimming 100-500 articles, reading some, catching up or killing the
rest, and saving other 2500 for later.  I draw in what I'm interested
in from the mass of unread articles first, each time, and the stuff
that I rarely get around to is the stuff that I don't miss.  Same with
rec.bicycles.soc - when the article count gets to 200-300, I read the
2-10 articles that I'm probably interested in, and miss the 95% which
is almost always noise.

That's why I resist moving to other fora.  I've never seen one that
lets me use better tools.

Okay, my download finished while I wrote this, back to work :)

-- 
Karl Anderson  [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] why cant i rename an object from an external method

[Andy McKay]

Heres a treat. I'm trying to write an external method to rename objects. I
have approx 10,000 to rename so a script would be nice. No problem I
thought, imitate a forms manage_renameObject and CopySupport.py can do the
work.

Rename works fine from the web form, but not from a script.
(ASPNTools.getsomeobjectsfromstring returns a bunch of objects, Ive tried
replicating this with resolve_url and get different namespace error, could
this be a clue?).

Heres my script:

def search(self, REQUEST=None):
 l = ASPNTools.getsomeobjectsfromstring(self, REQUEST['path'], REQUEST)
 for obj in l:
  ob = obj.aq_parent # get the folder
  ob.manage_renameObject(obj.id(), 'Foo')

 return 'renamed'

Here's my problem:

The object 100BASEFX does not support this operation

  File d:\p4\Zope-dev\lib\python\Products\ASPN/Extensions/foo_rename.py,
line 6, in search
(Object: 100BASEFX)
  File d:\p4\Zope-dev\lib\python\OFS\CopySupport.py, line 288, in
manage_renameObject
(Object: Traversable)
  File d:\p4\Zope-dev\lib\python\OFS\CopySupport.py, line 406, in
_verifyObjectPaste
(Object: Traversable)
Copy Error: (see above)


There surely must be simple way of doing this so I dont have to resort to
writing a Perl script to imitate the browser, please!

Thanks in advance as ever.

--
  Andy McKay, Developer.
  ActiveState.


___
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] ZCatalog with UTF-8 Chinese

[Zope mailing lists]

On Thu, 28 Sep 2000, Sin Hang Kin wrote:
> After reading some code of query, I think the regular expression operations
> which in parse, quotes and parse2 were not safe for utf8 string. So, I

That wouldn't surprise me.

> decide to emulate what they do. However, I do not understand what getlexicon
> is doing and I would like to learn what  q should looks like before it is
> passed to evaluate. I do not understand that vocabulary seems to store like
> integer, is getlexicon a step to look up the string to convert them to
> integer? I am getting lost.

I don't fully understand Lexicon myself, but I've at least spent some
time groveling around in the code.  I understand there's been a relatively
recent checkin of a new version of the text index stuff that at least
provides clearer variable names and additional comments; if you aren't
working from cvs version you might want to browse the files on the
cvs web interface.

So, here's what I understand:

The lexicon takes words and associates them with integers.  It is the
integers that are stored in the text index.  So in the final stages
of the search process, the parsed words are looked up in the lexicon
to get the integer, and the integer is then passed to the index
to get back the result set (list of documents containing the word).
The result set is itself a list of integers.  I think it is in fact
pairs (or some more complex data structure); at the least the index
stores the document number and the word offset (I think it's a word
offset) of the word into the document.

As for what q looks like...well, I haven't grovelled through the
parse, quote, parens, and parse2 code much, so I'm guess a bit here:
I *think* that before it goes into evaluate q is a list of sequences
or words, where the sequences are a list of sequences or
wordsrecursive.  The sub-sequences would be the parenthesized
expressions from the original string.  In the original string, any
occurences of the pair of words 'and not' were replaced by 'andnot'.
Any quoted strings (double quotes only, I believe) were replaced
by sequences of words separated by the 'near' operator ('...').
parse2 makes sure that every other item in q is an operator, by
sticking the default operator, 'or', in between any pairs that
aren't separated by an operator.

If I'm right, an expression like:

This is and not a (good "test of") searching

should end up feeding to evaluate a 'q' like this:

('this', 'or', 'is', 'andnot', 'a', 'or', ('good', 'or', ('test', '...'
   'of')), 'or', 'searching')

I'm least sure of those parens around test...of.

Maybe this will at least give you a clue to enable you to figure
out what the code *really* does .

--RDM


___
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] RE: XHTML Templates comments from the peanut gallery

[Jay, Dylan]

>  However, the focus of the new Template architecture will be a new
>  format based on XHTML.  This XHTML Template will be focused on
>  giving Site Designers round trip presentation authoring using the
>  dominant tools such as Dreamweaver.
>
>  XHTML Templates will be complete, well-formed HTML that look like a
>  resource will look when the XHTML Template is applied to it.  There
>  will be no "source vs. rendered" issue.
>
>  In this Presentation Architecture, Site Designers can start mocking
>  up a Zope site by editing real HTML and graphics in Zope from the
>  very beginning.  There will be nothing Zope-ish in what they are
>  doing.
>
>  As the mockups turn into live content, certain regions of the XHTML
>  Template will be "connected" to the live content.  This is done by
>  indicating the object data that will be inserted when the XHTML
>  Template is applied to content.

This all seems like a good idea but its hard its not very concrete. I
proposed something very similar about a year ago.

http://lists.zope.org/pipermail/zope-dev/1999-September/001624.html

It was an extension to DTML that enabled the use of documents that were
rendered html and dtml source combined. This gives you round trip wysiwyg
editing without "doing away" with the whole DTML scripting thing. A designer
might make a mockup, the coder would then zopify it by putting in iterations
etc in DTML as they normally would. The designer could then view the
document in "design-mode" that would render the DTML but keep special tags
in place around the rendered content that contained the code. Whent the
designer saved back this version there would be a spcial "design-mode"
compiler that would work out all the DTML objects etc the relevent bits of
content (and code) belonged to. Content relating to any object that the
designer doesn't have permission to edit or the content was dynamic like
from a database, just gets discarded.

This solution seems to achieve most of your aims for XHTML but without some
of the weird architecture changes.

Dylan Jay
Avaya Communication.

___
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] XHTML Templates comments from the peanut gallery

[Spicklemire, Jerry]

 > >Chris Withers writes:
 > >   A **page** is the result of applying presentation to data in the
 > >   object system.  A page is a particular result of a URL when viewed
 > >   under certain conditions.
 > 
 > I'd like to add to this:
 > components used to make up 'page's should not be URL-visible. Why should
 > they be?
 > (would this raise issues with XML-RPC?)

> whereupon Dieter Maurer responded:
> Because, you want to access them for management purposes (e.g.
> change them).

and, conceptually at least, this should facilitate displaying the 
hypothetical "block" resources as "include virtual" sorts of beasties, 
on the inside of some next generation hyper-editing environment.

Zopefully,
Jerry S.


___
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] XHTML Templates comments from the peanut gallery

[Dieter Maurer]

Chris Withers writes:
 > >   A **page** is the result of applying presentation to data in the
 > >   object system.  A page is a particular result of a URL when viewed
 > >   under certain conditions.
 > 
 > I'd like to add to this:
 > components used to make up 'page's should not be URL-visible. Why should
 > they be?
 > (would this raise issues with XML-RPC?)
Because, you want to access them for management purposes (e.g.
change them).


 > >   Site Designers will create XHTML Template objects that control
 > 
 > Where can I find out more about XHTML?
--> http://www.w3c.org



Dieter

___
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] zope2.2.2 - ZopeTime security thing

[Chris Withers]

ross wrote:
> KeyError: (see above)
> 
> Note, it's not unauthorised - it's just not in the namespace.

IIRC, the new way for security errors like this to work is to throw a
keyerror. So, it's probably a permissions problem manifesting itself as
a KeyError.

Try installing Shane Hathaway's ZDebug and see what that reveals :-)

cheers,

Chris

___
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] zope2.2.2 - ZopeTime not available to users defined in acl_users belowthe root?the root?

[ross]

Here's a problem which bit me today. I'd delegated someone to manage a
Yihaw directory. zope 2.2.2 source running on a sun.

make a folder at the root (eg /foo) with an acl_user folder there
define a new user in the foo acl_user folder (eg foobar) with
manager/owner rights
add a dtml method to view ZopeTime 

(eg 

) 

view it and see the current time. It's owned by a real manager and it
works as expected.

Now, close your browser down and authenticate as foobar and try to view
the page. You'll get:

Zope Error
Zope has encountered an error while publishing this resource. 

Error Type: KeyError
Error Value: ZopeTime



Traceback (innermost last):
  File /udd/rerla/zope222/lib/python/ZPublisher/Publish.py, line 222, in
publish_module
  File /udd/rerla/zope222/lib/python/ZPublisher/Publish.py, line 187, in
publish
  File /udd/rerla/zope222/lib/python/Zope/__init__.py, line 221, in
zpublisher_exception_hook
(Object: Traversable)
  File /udd/rerla/zope222/lib/python/ZPublisher/Publish.py, line 171, in
publish
  File /udd/rerla/zope222/lib/python/ZPublisher/mapply.py, line 160, in
mapply
(Object: test)
  File /udd/rerla/zope222/lib/python/ZPublisher/Publish.py, line 112, in
call_object
(Object: test)
  File /udd/rerla/zope222/lib/python/OFS/DTMLMethod.py, line 172, in
__call__
(Object: test)
  File /udd/rerla/zope222/lib/python/DocumentTemplate/DT_String.py, line
528, in __call__
(Object: test)
KeyError: (see above)

Note, it's not unauthorised - it's just not in the namespace.

ZopeAttributionButton is defined in the same Application.py but it works
fine. I even tried adding
ZopeTime__roles__=None to no avail.

What gives???

___
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] some suggestion..

[Christian Scholz]

Hi!

While trying to code some python Product I had the need for extending
manage_delObjects in some Folderlike object. I simply want to call the
the ObjectManager's version of it and then do my own stuff afterwards
(like deleting some other dependant objects).

Unfortunately when calling manage_delObjects() one cannot decide
if some error occured or everything went ok as in both cases
I get back some string (be it some html formatted error message or
the manage_main dialog).

So what about splitting these methods in two, e.g. one _delObjects()
and one manage_delObjects(). The first one would the the actual work
like testing for error conditions and deleting the objects and the
other one would be the one called by the management interface.
manage_delObjects() would then call _delObjects() and checks for
errors afterwards generating some error message or the next dialog.
The errors could then be passed via exceptions or similar methods
from _delObjects() to manage_delObjects().

This would make subclassing a lot easier and would be at least a
start in separating layout from logic.

Just an idea :)

cheers,
  Christian

PS: Maybe it would even make XMLRPC more usable as there I also get
back only html formatted error messages instead of something making
more sense for a script (like an error code or something).

-- 
COM.lounge  http://comlounge.net/
communication & design   [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] Email the changes

[Ken Manheimer]

On Thu, 28 Sep 2000, Chris Withers wrote:

> > > The only quoting you need to know is example::
> > >
> > >   The two colons after the word "example" indicate that this contained
> > >   block is all quoted.
> 
> How is a 'contained block' delimited?

As i did in my example, by indentation.  (This is a primary component of
the "structure" in StructuredText.  Maybe we're not being clear enough
about that in our explanations of structured text - i would expect that
not knowing about it could make it much much harder to understand what's
going on, in general, with StructuredText!)

Ken
[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] WikiDot

[Ken Manheimer]

On Thu, 28 Sep 2000, Chris Withers wrote:

> > These are the kinds of things i'm hoping to get at with WikiNG - a
> > smart content widget, with two essential features - good impedence
> > matching to authoring structured, linked content (structured text plus
> > wiki refs),
> 
> A lot of people I know would disagree with the Structured Text bit, but
> I guess it'll have to do for now. Wysiwig editing on the web hasn't
> arrived yet :-(

(I wonder whether having a single quick ref page for structured text,
linked to on every edit form, would go a long way to reducing those
objections.  Particularly if the quick ref page is clear and concise.)

> > and intrinsically determined and easily adjustable
> > organization.
> 
> 'Easily adjustable' could be difficult...

I was just referring to the ease of reparenting a page - if this isn't
familiar to you, see the backlinks pages in any zope.org zwiki.

Ken
[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] XHTML Templates comments from the peanut gallery

[Spicklemire, Jerry]

>> Paul Everitt wrote:
>> o Allow those presentation tools to work by having well-formed
>> markup (e.g. no separation into header and footer)

> to which Chris Withers replied:
> Hmmm... I wonder how refactoring, which _header and _footer were really
> useful for, will happen now...

The most obvious problem was that _header + _footer idiom was presented in 
a way that resulted in tags being opened in _header, and cosed in _footer. 
I personally adopted this as a "Good Example" of how to use Zope, and had 
created quite a mess for myself before a post on one of the lists pointed 
out how genuinley horrible this is, from a well-formedness point of view. 
Duh! 

Still, it's just not that big a trick to factor out the HEAD tag as a 
monolith, and insert references to other pieces parts inside the HTML tag 
that used to be included in _header, but now appears as a "hard coded" 
element in the "presentation" document. On the surface it may look like 
you wind up with things more scattered about, but as far as factoring, it's 
manageable. Even in the worst case, my _headers tended to be made up of 
references to other elements that had been factored out anyhow. Same applies

to _footer, and other items. 

So, there is a change in mind set, but not on the scale of a tectonic shift.

If we can get here:

>>   Zope should move to an architecture with clear separation of
>>   presentation, data, and logic, with clear concepts in Zope for these
>>   tiers and audiences.

it will certainly be worth any adaptation that need to occur.

However, I am a bit puzzled regarding:

>>   The presentation tier will get a tremendous usability increase by
>>   allowing round trip presentation with common tools.  This also
>>   ensures that Site Designers finish with the same stuff they started
>>   with, meaning the programmers don't come in and cast their work into
>>   "code".

Folks really do want to use Dreamweaver et. al. to layout Web "pages", 
that's verifiable. The proposal to meet this need is to "let the 
designer see what they expect, but swap in a Zopification at run time". 

That may be enough to fulfill the requirement, but it looks pretty pale 
from this end. There is a very narrow band of "graphic stuff" that won't 
need to be thoroughly Zopified ("cast into code") in the process of 
adapting a designer's work. Most of the stuff that makes a Web site 
useable, such as menus, navigation bars, etc. must be entirely transformed 
into lists (tables) and scripts (DTML, Python methods, whatever) on the 
way to maintainability nirvana. As for real Web Applications, the range 
is even thinner. 

The illusion of "round trip editing" may be enforcable this way, and 
there may in fact be a long range plan to convert to a real implementation, 
based on DOM, XSLT. If that's sufficient to get past the "let me do it 
my way" objections of temperamental "Artists", so be it.

>>   Site Designers want simple reuse of content within reach of standard
>>   tools.  For instance, the Site Designer wants a standard copyright
>>   "asset" on the bottom of every page.

This is easy enough to provide for, but the proposal seems to imply that 
a "hard copy" of each "asset" will be inserted in the designed "page", 
but a Zopification of that asset will appear in the served "page". Of 
course that's quite feasible with Zope, change an "asset", all instances 
will be composed, at serve time, to display the updated "asset". 

Then, all the designers have to do is go back, and hand edit every 
"dummy" instance that's just there to keep them contented, because those 
"hard copies" aren't going to be updated, since they are not accessible 
by Zope. What has been gained here?

>>   Site Designers will create XHTML Template objects that control

This sounds great, but are these the same folks who can't live without 
their Dreamweaver? Now they're going to design XHTML Templates? My 
guess is that the designer will create an HTML "page", and a Zope jockey 
will tuck some references inside some tags that point to other goodies 
that were concocted far from the gaze of the "designer", and essentially 
override the original. Hopefully the designer won't notice those new 
little gotchas hiding in the tags, and will leave them where they are. 
Can you say "element level locking"?

>>   XHTML Templates will be complete, well-formed HTML that look like a
>>   resource will look when the XHTML Template is applied to it.  There
>>   will be no "source vs. rendered" issue.

Except for the "dummy assets" which will only be an "artists conception" 
of the rendered "resource", if I'm getting this right.

>>   The XHTML Template architecture will facilitate re-use by allowing
>>   blocks in the XHTML Template to be named as a
>>   (component/library/asset) block.  As the Site Designer authors and
>>   updates the block of XHTML, Zope saves the named block as a separate
>>   object in Zope.  This named object can then be used in other XHTML
>>   Templates

[Zope-dev] 'REQUEST' lost on DTML rendering

[Kent Polk]

I have a Product which works fine under Zope 2.1.6 but am having
trouble moving it to 2.2.1

This product creates temporary instances of objects and then uses
__bobo_traverse__ to traverse class operators specified in the URL
which create the objects that are rendered via DTML methods.

The very first time one of these objects is called (after tehe
server is started), all works fine.  With all subsequest calls,
the DTML methods which render the results cannot locate the REQUEST
dictionary anymore. My class methods can still see the REQUEST
dictionary just fine with every call, but REQUEST apparently gets
lost between when the bobo_traverse returns and when the DTML
renderer starts.  (and yes, this all worked fine prior to 2.2x :^)

I'm stumped. How could the REQUEST object get passed the first time
to the DTML renderer and never thereafter?

What changed thereabouts?

Thanks

___
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] WikiDot

[Chris Withers]

Ken Manheimer wrote:
> I don't think anyone disagrees that wiki pages as they stand are
> imperfect for discussions.  I strongly feel (with lots of experience)
> that mailling lists are also flawed, sorta complementarily, for
> getting definite results out of discussions.  Both work with some
> effort, i think many of us feel that a insightful hybrid could reap
> more than the benefits of both.

Yup, spot on :-)

> > > The Wikis on the
> > > dev.zope site do a bit of this with delegating discussion to a
> > > discussion
> > > page.
> >
> > Yes, but that's only advisory, it's not enforced...
> 
> What's your point?  

Not point, just a comment ;-) As long as this as recognised it's not so
bad...

> We discussed (in a off-list discussion) a point of karls, that the
> tracker and weblog can map onto eachother, with some structural
> provisions.  I can see something very similar with wikis.

Yup, hence WikiDot, for me to work on...

> A weblog could constitute a wiki space, with the topic message being
> the FrontPage and the threads hanging off of it being nested wiki
> pages.  The discussion pages would automatically get names, per their
> nesting status - LogSub1Sub2 or something, overridable by the page
> author to have semantic significance. 

The names aren't so important to me but I think I see where you're
going...
I'm keen to have the structure of replies actually be a storage
structure, unlike in traditional Wiki.
This makes WikiName markup more difficult to handle, unfortunately...

>  - Wiki organizational features - table-of-contents view, ability to
>adjust nesting situation in the discussion (modulo the weblogs
>policy - often the owner may disallow any such adjustment, but in
>some cases it would make sense).

Good point.

>  - With WikiNG's prospective notification mechanism, people could
>"subscribe" to email notifications for any changes - additions,
>edits, etc - within threads/subthreads, or just for additions at
>top levels of threads.  The latter is like "executive summary"
>monitoring, wanting to know only when the uppermost parts of the
>discussions change, without having to worry about changes to the
>outlying parts of the discussion tree.

Swishdot is going to have this stuff pluggable, so WikiDot could have
something to match this...

>  - With WikiNG editing policy control, the weblog *could* have a
>policy that allows authors to amend their messages - eg, to insert
>or append comments to their existing messages.  Or to edit their
>messages, if that fits the task at hand.  (Eg, if what they're
>doing is collaboratively developing a document.)  The basic case
>would not allow this, for more classic, conventional weblog
>conduct.

Another good point...

> Lots of good stuff.  The essential thing in this perspective is seeing
> the weblog as a structured viewing mode for the contents of the wiki -

yup...

> These are the kinds of things i'm hoping to get at with WikiNG - a
> smart content widget, with two essential features - good impedence
> matching to authoring structured, linked content (structured text plus
> wiki refs),

A lot of people I know would disagree with the Structured Text bit, but
I guess it'll have to do for now. Wysiwig editing on the web hasn't
arrived yet :-(

> and intrinsically determined and easily adjustable
> organization.

'Easily adjustable' could be difficult...

cheers,

Chris

___
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] Namespace trouble

[Martin Grönemeyer]

Hello everyone,

if've had little namespace problems with this code-snipped (dtml-method):


 
  
  
  
 


This produces an output like this: 0,0,0,0,0,0,... The zero is the first
index set by REQUEST.set... The running index isn't reflected into the
current namespace. Why not ? It know it depends on , but
it didn't find an answer.

Thanks for any comment,

martin



___
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] mailing list 'noise'

[Ken Manheimer]

On Thu, 28 Sep 2000, Chris Withers wrote:

> Toby Dickenson wrote:
> > I dont see this as a problem: You only create a new list when the
> > traffic for that proposal gets too great for zope-dev. Threading is
> > good enough before that point.
> 
> Yes, but zope-dev has a relatively high traffic load... Why should you
> have to put up with all that 'noise' if you're only interested in posts
> for your comparatively small discussion?

Yeah - maillists flow by, and not everyone can follow all the traffic all
the time!! The cool thing about "content-based" mailling lists, where
people can subscribe to notifications about changes in subthreads, is that
you just subscribe to the part of the discussion that has your interests!!

--
Ken
[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] WikiDot

[Ken Manheimer]

On Thu, 28 Sep 2000, Chris Withers wrote:

> > 4.Some people think Wiki discussions are easily dispersed. Bad Wiki
> > discussions are, but discussion products are almost always dispersed by
> > nature. On many occasions I have (already) seen people summarize and
> > structure maillist discussions into a Wiki web.
> 
> Yes, but does that mean the Wiki is good for the initial discussion?

The point you've cited seems to be about something else (why wikis can
work for discussions, not why they're good for setting them up).  My
response to your challenge is that the lack of a clearly designated
document or other artifact as the focus of a discussion can, and, i
think, usually does, lead to drift in the discussion.  In weblogs, the
document at the top anchors the discussion.  In our proposals site,
the proposals serve as (evolving) subjects of the discussion.

I don't think anyone disagrees that wiki pages as they stand are
imperfect for discussions.  I strongly feel (with lots of experience)
that mailling lists are also flawed, sorta complementarily, for
getting definite results out of discussions.  Both work with some
effort, i think many of us feel that a insightful hybrid could reap
more than the benefits of both.

> > The Wikis on the
> > dev.zope site do a bit of this with delegating discussion to a
> > discussion
> > page.
> 
> Yes, but that's only advisory, it's not enforced...

What's your point?  It seems to work, though there's possibility for
it to breakdown.  We recognize that possibility is significant, and
would like to address it - hence the WikiNG proposal, and many other
expressions of desire to fix these sorts of things.  Actually, we're
sorely chafing under lack of such fixes, but we can't afford to
neglect our other commitments (clients, including zope community!) at
the moment to do so.  And we feel that we're better off, for the time
being, with fixed points as the focus of proposal discussions, for
instance.

> > Most of these points are addressed in the proposal, but what I wanted to
> > add is the notion of the necessity of integrating the three types of
> > discussion into one product. That would make for a new generation. How
> > would that look then:
> 
>  
> 
> Funny you should say that. Some other people I'm chatting to have come
> up with roughly the same ideas...

We discussed (in a off-list discussion) a point of karls, that the
tracker and weblog can map onto eachother, with some structural
provisions.  I can see something very similar with wikis.

(This came out of a discussion with ethan - we were wondering how the
WikiNG stuff fits in with the PTK.  We came up with a bunch of stuff
that i really like, including this vision of integration with
s{qu,w}ishdot - just a concept, to demonstrate the kinds of things
that would be possible - i'm not looking to impose it on you if it
doesn't seem suitable to you.)

A weblog could constitute a wiki space, with the topic message being
the FrontPage and the threads hanging off of it being nested wiki
pages.  The discussion pages would automatically get names, per their
nesting status - LogSub1Sub2 or something, overridable by the page
author to have semantic significance.  The benefits:

 - Structured text.

 - Easy for authors to refer to other messages in the discussion by
   name, using wiki references.

 - Wiki organizational features - table-of-contents view, ability to
   adjust nesting situation in the discussion (modulo the weblogs
   policy - often the owner may disallow any such adjustment, but in
   some cases it would make sense).

 - With WikiNG's prospective notification mechanism, people could
   "subscribe" to email notifications for any changes - additions,
   edits, etc - within threads/subthreads, or just for additions at
   top levels of threads.  The latter is like "executive summary"
   monitoring, wanting to know only when the uppermost parts of the
   discussions change, without having to worry about changes to the
   outlying parts of the discussion tree.

 - With email-in wiki pages [i have to comment on mj's proposal, i
   have similar ideas in the WikiNG proposal, but haven't had time to
   evaluate his specifics!], people could use their subscriptions to
   hierarchies within the weblog to make their contributions via email 
   - often for submitting new messages, but perhaps sometimes for
   annotating existing ones, a la...

 - With WikiNG editing policy control, the weblog *could* have a
   policy that allows authors to amend their messages - eg, to insert
   or append comments to their existing messages.  Or to edit their
   messages, if that fits the task at hand.  (Eg, if what they're
   doing is collaboratively developing a document.)  The basic case
   would not allow this, for more classic, conventional weblog
   conduct.

Lots of good stuff.  The essential thing in this perspective is seeing
the weblog as a structured viewing mode for the contents of the wiki -
or the wiki as being an substrate f

[Zope-dev] A few Questions

[Keith Larson]

Title: A few Questions





Hello I just joined so sorry if you have answered these before or if it the right place to ask but : 


I have a 4 new sites in Zope that is mirrored on two servers and load balanced. A third server is for qa and editing in Zope. 

Now , is there a way to have a python script go into Zope and delete all the acl users and pack the database ? ( for when a script copies the Data.fs into the live environment) 

Also is it possible to have the management only run via :8080 and be an error is tried via http://foobar.com/manage 


The apache is built via pcgi and redirects. I would like to be able to have apache serve out Zope on one nic and kill the port 8080 and the other serve all ports . 

If you have any ideas please email and I will get more in depth as far as I can anyways.


Keith Larson 
Web Developer
[EMAIL PROTECTED]

Re: [Zope-dev] XHTML Templates comments from the peanut gallery

[Chris Withers]

(sorry I'm so late on this, things have been hectic :-( )

Paul Everitt wrote:
> o Allow those presentation tools to work by having well-formed
> markup (e.g. no separation into header and footer)

Hmmm... I wonder how refactoring, which _header and _footer were really
useful for, will happen now...

> o Match the appropriate level of capability currently in DTML
> usage

That's interesting. I see a lot of DTML's problems being caused because
it is 'overcapable'...

>   Zope should move to an architecture with clear separation of
>   presentation, data, and logic, with clear concepts in Zope for these
>   tiers and audiences.

:-))

>   The presentation tier will get a tremendous usability increase by
>   allowing round trip presentation with common tools.  This also
>   ensures that Site Designers finish with the same stuff they started
>   with, meaning the programmers don't come in and cast their work into
>   "code".

:-))

>   The architecture should make sure those presentation tools are
>   effective by having well-formed markup (e.g. no separation into
>   header and footer).

...still not sure what this means

>   The new presentation architecture should match the appropriate level
>   of capability currently in DTML usage.  For instance, common idioms
>   like browse-by-batch should be possible.

...that's going to be a fine line to tread :-S

>   Site Designers want simple reuse of content within reach of standard
>   tools.  For instance, the Site Designer wants a standard copyright
>   "asset" on the bottom of every page.

How does this fit with the "no separation into header and footer" thing?

>   The presentation architecture should not know about the details of
>   the data tier or the logic tier.  Rather, the presentation
>   architecture will just provide a view onto the model expressed in
>   the object system, where the model uses standard APIs.

...not 100% on what that means...

>   A **page** is the result of applying presentation to data in the
>   object system.  A page is a particular result of a URL when viewed
>   under certain conditions.

...I'd like to add to this:
components used to make up 'page's should not be URL-visible. Why should
they be?
(would this raise issues with XML-RPC?)

>   Ultimately, data such as documents will be matched to a presentation
>   according to implicit and explicit rules.  The simple case will be
>   simple (invisible); the complex, custom cases will be
>   straightforward.  In the initial rev of the architecture, only one
>   presentation will be implicit for a resource.  Other presentations
>   of that resource will require explicit traversal to obtain them.

...that's a little unclear :-S

>   Site Designers will create XHTML Template objects that control

Where can I find out more about XHTML?

>   XHTML Templates will be complete, well-formed HTML that look like a
>   resource will look when the XHTML Template is applied to it.  There
>   will be no "source vs. rendered" issue.

Does this mean the 'rendered' stuff could be considered 'bloated' as it
contains stuff only needed for what would have been the 'source' editing
mode?

>   The connectors will allow different "modes" that provide the
>   alternation and conditional facilities present in DTML.  These modes
>   are just simple attributes to extend the semantics of existing XHTML
>   tags.

This sounds interesting...

>   The XHTML Template architecture will facilitate re-use by allowing
>   blocks in the XHTML Template to be named as a
>   (component/library/asset) block.  As the Site Designer authors and
>   updates the block of XHTML, Zope saves the named block as a separate
>   object in Zope.  This named object can then be used in other XHTML
>   Templates.

...that was confusing...

>   DTML has permitted the rendering on non-markup such as SMTP
>   messages.  The XHTML Template does not try to satisfy this job.
>   Other objects, such as DTML Methods or Python Methods, would have to
>   handle this chore.

:-( (but I can see why it has to be so...)

>   Clarifying the "DTML namespace" confusion felt by authors is not in
>   the scope of this proposal.

Is it being covered anywhere else?

>   *Replacing magic with magic*.  If too much magical stuff happens
>(e.g. how data gets implicitly bound in different ways to
>presentation, the component idea creating new stuff in the
>background) for people to handle, we're just replacing the
>confusing old magic with the confusing new magic.

Hmmm

Well, sorry for being so late on this. I hope I haven't made too many
comments that other people have already. The proposal looks really cool
and should hopefully take a lot of the pain out of developing the
presentation layer in Zope...

cheers,

Chris

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

Re: [Zope-dev] mailing list 'noise'

[Chris Withers]

Toby Dickenson wrote:
> I dont see this as a problem: You only create a new list when the
> traffic for that proposal gets too great for zope-dev. Threading is
> good enough before that point.

Yes, but zope-dev has a relatively high traffic load... Why should you
have to put up with all that 'noise' if you're only interested in posts
for your comparatively small discussion?

Chris

___
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] WikiDot

[Chris Withers]

Rik Hoekstra wrote:
> maillists vs discussion platforms. This problem is caused by the
> intermingling of too many different functions of a wiki. I'll go a bit
> at length to expose these and try to strike a balance, which should be
> in a combination (did I hear WikiDot?):

Yes, well, that's the idea ;-)

> Even if there is a
> mail-notification possibility, this leads to the situation that mails
> are sent as replies to the notification (by accident) and not to the
> forum itself (I'm not sure about Squishdot on this last point).

This is a real problem for Squishdot. I hate to think how many emails
Butch has recieved at [EMAIL PROTECTED] because it's the default reply
to address in the Squishdot demo sites. Swishdot will hopefull not have
this problem when used in conjunction with ZMailIn.

> 4.Some people think Wiki discussions are easily dispersed. Bad Wiki
> discussions are, but discussion products are almost always dispersed by
> nature. On many occasions I have (already) seen people summarize and
> structure maillist discussions into a Wiki web.

Yes, but does that mean the Wiki is good for the initial discussion?

> The Wikis on the
> dev.zope site do a bit of this with delegating discussion to a
> discussion
> page.

Yes, but that's only advisory, it's not enforced...

> Most of these points are addressed in the proposal, but what I wanted to
> add is the notion of the necessity of integrating the three types of
> discussion into one product. That would make for a new generation. How
> would that look then:

 

Funny you should say that. Some other people I'm chatting to have come
up with roughly the same ideas...

cheers,

Chris

___
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] Email the changes

[Chris Withers]

Toby Dickenson wrote:
> > The ability to subscribe for notification (above) and/or to track what
> > you personally have seen, and not, is intended for this kind of thing.
> 
> It would keep me happy if the notification includes a link to the new
> content (rather than a link to the page that contains new content). Even
> better, the email notification could *include* the new content.

...yes :-)

Something like a diff would be great :-)

> > The only quoting you need to know is example::
> >
> >   The two colons after the word "example" indicate that this
> > contained
> >   block is all quoted.

How is a 'contained block' delimited?

> Perhaps I should rephrase my objection. The *real* problem is that this
> isnt happening - discussion is stored in Wiki pages like
> http://dev.zope.org/Wikis/DevSite/Proposals/XxxxDiscussion

Good point :-)

___
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] I feel your Wiki Pain ;-)

[Chris Withers]

Toby Dickenson wrote:
> >> How about running the 'Discussion' parts of (in particular) dev.zope.org
> >> from ZDiscussions, ZUBB or Squishdot?
> >
> >This may be a good idea...
> 
> What's wrong with a mailing list? Is this just a case of NIH?

Setting up a mailing list for each proposal is painful.

Setting up a Squishdot site for each proposal takes 5 minutes, and could
even be worked into a 'Create New Proposal' DTML or Python method...

Chris

___
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] MySQL : help !

[Monty Taylor]

I can send you one, but if building it is giving you lots of problems,
you may have larger problems, and the _mysql I send may not really help.
Building should be sort-of straight forward.

What version of ZMysqlDA are you using?
What version of Mysql?
What errors are you getting?

[EMAIL PROTECTED] wrote:

> I need the binarie file named  _msql
> does anybody got it (for any Linux)?
> Because I can't build this file : I've got too many errors 
>
> Thanks in advance
> Jérôme DIEBOLD
>
> ___
> 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 )