[Zope-dev] Object references from dtml

[Ross Boylan]

I have a log composed of sublogs, and so on.  I would like for people to be 
able to see some kind of summary (e.g., short versions of the logs down n 
levels) on the screen and then click on one of interest and see a fuller 
display of it.

Is there a good way to do this using dtml?

I've thought of two approaches.  The "standard" zope way seems to be to 
make each log folderish, and give each entry an id.  Then I can embed the 
address in the html.  The problem with this is that I would have to make up 
the id's and add extra machinery that the logs don't really need.

I'm leaning toward a second approach, of getting an object id and putting 
it in the html.  This also raises some issue.
   * Will the id be stable in the face of the db potentially 
dematerializing objects underneath?
   * If I use a persistent id (_p_oid, I think), will that be stable?
   * (Also, I'll need to be sure everything has persisted, but I think I 
can do that by forcing a transaction end before getting the _p_oid).
   * Can I map from object id back to object?  (_p_jar.something or other)
   * Will this be robust across database changes (minimally, from ZODB to 
ZEO)?
   * Will the object id consist of characters which can be embedded easily 
in html?


___
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] Inheritable Propertysheets!???!!?!?!?!!

[Alexander Schonfeld]

Thanks, that does seem to do the trick.  :)
Much appreciation!!

I added a propertysheets like this:
  ParentClass.Propertysheet.defaultProps.someprop
  ChildClass1.Propertyshoot.props.someprop
  ChildClass2.Propertyshoot.props.someprop (to override the parent's
default when needed)

It sees the ChildClass' "someprop" first so it doesn't go look for
the parent's prop.

This is useful for making lots of classes with only a few changed
properties, but the bulk of which can be inherited.

Alex.


On Wed, 18 Oct 2000 10:50:44 +0100
"Seb Bacon" [EMAIL PROTECTED] wrote:

 AFAIK (but I'm no expert), a ZClass inherits its parents' propertysheets and
 you can access them in the normal way.  The problem is that the all the
 propertysheets have to have different names.  Example:
 
 If your parent class and the child class both have a property sheet called
 "Basic", but the child class is hoping to inherit someproperty from the
 parent class:
 
   ParentClass.Propertysheets.Basic.someproperty
 
 is ok, but
 
   ChildClass.Propertysheets.Basic.someproperty
 
 won't work, because "someproperty" is not in ChildClass's "Basic"
 propertysheet.
 
 If your parent class and child class do not share propertysheets with the
 same name, you *can* access parent properties:
 
   ChildClass.Propertysheets.ChildSheet.anotherproperty
   ChildClass.Propertysheets.Basic.someproperty
 
 will both work.
 
 If I'm correct, this is all wrong and a bad thing, surely?
 
 However that was the worst-explained thing I've ever been responsible for
 and it's probably wrong.  That particular configuration of punctuation in
 the subject header just struck a chord with me...
 
 seb.
 
 
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
  Behalf Of Alexander Schonfeld
  Sent: 18 October 2000 10:25
  To: [EMAIL PROTECTED]
  Subject: Re: [Zope-dev] Inheritable Propertysheets!???!!?!?!?!!
 
 
  I guess I can just use dtml methods that return lists and stuff, but is
  that as cool?
 
  On Wed, 18 Oct 2000 18:21:33 +0900
  Alexander Schonfeld [EMAIL PROTECTED] wrote:
 
   I'm doing an experiment... If I add more '!' and '?' marks will I get a
   response.  Soon with enough experimentation I can find the optimal
   number and frequency of variation.
  
   I want to inherit the properties of one zclass in another zclass, but
   it seems to cause some namespace clashing... shouldn't this be possible?
   Working with the instance of the class is fine, but inter-zclass
   inheritance (acquisition?) would be nice...
  
   Cool feature?
  
   Am I missing something?
   Thanks,
  
   Alex.
  
   1010011010101001101010100110101010011010
   0  Digital Garage$B!!%G%8%?%k

Re: [Zope-dev] Object references from dtml

[Ender]

Ross Boylan wrote:
 
 I have a log composed of sublogs, and so on.  I would like for people to be
 able to see some kind of summary (e.g., short versions of the logs down n
 levels) on the screen and then click on one of interest and see a fuller
 display of it.
 
 Is there a good way to do this using dtml?
 
 I've thought of two approaches.  The "standard" zope

having recently debugged company's zope server, i can safely say that
there is no 'standard'.

 way seems to be to
 make each log folderish, and give each entry an id.  Then I can embed the
 address in the html.  The problem with this is that I would have to make up
 the id's and add extra machinery that the logs don't really need.

 I'm leaning toward a second approach, of getting an object id and putting
 it in the html.  This also raises some issue.

you lost me. your problem with the first method is having ids for your
log entries and your second method starts with getting ids for your
objects. 


looking ahead, YIKES, you just went from can i do this in dtml to
messing with python code in the guts of the ZODB. that was a SERIOUS
leap. IMO i'd highly recommend against messing with the zodb stuff, _p_
attrs are supposed to be reserved. i understand you want to treat them
as read only, but i wouldn't even go near it if it could be implemented
easily otherwise or i had developed a strong masochistic tendency and
already knew the zodb well (well enough to know the answers to the below
questions).

 This also raises some issue.
* Will the id be stable in the face of the db potentially
 dematerializing objects underneath?

what id?

* If I use a persistent id (_p_oid, I think), will that be stable?

see above commentX2.

* (Also, I'll need to be sure everything has persisted, but I think I
 can do that by forcing a transaction end before getting the _p_oid).

transactions are important, but also telling it before hand that the
object is dirty and needs to be saved. you might want to read jim's
paper on the zodb. it and alot of other good material are linked from

http://www.zope.org/Members/itamar/LearningZope/LearningZope.html

* Can I map from object id back to object?  (_p_jar.something or other)

this is getting worse(scarier?) as i go on... i have no idea. consider
also that a url is also a unique persistent object id that maps into the
zodb, why your first method works. 

* Will this be robust across database changes (minimally, from ZODB to
 ZEO)?
* Will the object id consist of characters which can be embedded easily
 in html?
 

...

there are alot of other ways to do this... of the top of my head

you could always store log entries in a sql db. 

since you seem not adverse to doing it in python, despite your original
question...

so why not just write a python class for the log folder thats
persistent, add some methods for managing/storing log entries in a some
attr (maybe list of dicts) of the logfolder. write some dtml accessible
accessor methods to the attrs. write a dtml page for summary and one for
details. 

kapil

___
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] Method binding

[Chris Withers]

Maybe the Zope-Dev guys have comments on this

 From: Jim Fulton [EMAIL PROTECTED]
 
 Michel,
 
 You have advocated that methods should always be bound to the objects they
 are accessed in. You argue that there should be no choice in the matter.
 
 I have to disagree strongly. I'll try to explain why.
 
 In Python, methods are bound to instances.  Methods are part
 of an instance's core behavior. They are specific to the kind
 of thing the instance is. In my words, methods are part of
 the genetic makeup of an object.
 
 In Zope, we allow some methods to be bound to their context.
 This is done in a number of ways and is sometimes very useful.
 We have methods, like standard_html_header, which are designed
 to be used in different contexts.
 
 We have other methods, like manage_edit that are designed to
 work on specific instances. It would be an egregious error
 if this method was acquired and applied to it's context.
 
 We have some methods that are designed to bound to an instance
 (container, in your terminology) but that, because they are written in
 DTML, can be bound to other objects. This can cause significant problems.
 For example, methods defined in ZClasses almost always want to be
 bound to ZClass instances, not to other arbitrary objects.
 
 asideThere's a bonus problem with DTML Methods. When
 a DTML Method is invoked from another DTML Method, it
 is bound to neither the object it was accessed in or
 to the object it came from. It is bound to the calling
 namespace. It turns out that this is a useful behavior
 if the DTML Method is designed to be used as a "subtemplate".
 /aside
 
 There is no one "right" way to bind a method. There are good
 reasons to sometimes bind a method to it's context and
 sometimes bind a method to it's container (ie instance).
 There are even sometimes reasons to bind a method to a
 calling namespace.
 
 The principle of least surprise doesn't help here, because
 methods defined in Python classes don't behave the way
 methods defined through the web do currently.
 
 We *need* control over binding, as well as reasonable defaults.
 
 If we can agree that we need binding control, the question
 arises as to some details and default names.
 
 Should it be possible to do more than one binding at a time,
 using multiple names?  If not, then I'd agree that the name
 'self' should be used for either the context or container binding.
 If both bindings are allowed at the same time, then 'self' should
 refer to container binding to be consistent with standard Python
 usage and some name like 'context' should be used (by default)
 for contextual binding.
 
 Jim

___
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] Michel's Reply

[Chris Withers]

From: Michel Pelletier [EMAIL PROTECTED]

Jim Fulton wrote:

  Michel,

  You have advocated that methods should always be bound to the objects they
  are accessed in. You argue that there should be no choice in the matter.

I advocate more points than that, like being able to document python
with python, no XML mixed in with a language, Py Meths working like
other methods do, but yes that is one of them. 

My argument should be more flexible in regard to choice, a willing
compromize is to switch the default binding of context and container,
making 'self' the default for context and something else the default for
container.

  I have to disagree strongly. I'll try to explain why.

  In Python, methods are bound to instances.  Methods are part
  of an instance's core behavior. They are specific to the kind
  of thing the instance is. In my words, methods are part of
  the genetic makeup of an object.

Python methods are meant for through the web usability and programming
ala the existing Zope model.  90% of your audience just scratched their
heads.

  In Zope, we allow some methods to be bound to their context.
  This is done in a number of ways and is sometimes very useful.
  We have methods, like standard_html_header, which are designed
  to be used in different contexts.

this is how I feel python methods should be designed to be used.

  We have other methods, like manage_edit that are designed to
  work on specific instances. It would be an egregious error
  if this method was acquired and applied to it's context.

I think this is a weak argument, none of the built in Zope methods mean
anything to the average user, they can't find them, click on them, edit
them, or copy them to their own method to change and experiment with. 

  We have some methods that are designed to bound to an instance
  (container, in your terminology)

Python Method terminology

  but that, because they are written in
  DTML, can be bound to other objects. This can cause significant problems.
  For example, methods defined in ZClasses almost always want to be
  bound to ZClass instances, not to other arbitrary objects.

  asideThere's a bonus problem with DTML Methods. When
  a DTML Method is invoked from another DTML Method, it
  is bound to neither the object it was accessed in or
  to the object it came from. It is bound to the calling
  namespace. It turns out that this is a useful behavior
  if the DTML Method is designed to be used as a "subtemplate".
   /aside

This is because DTML binding is implicit, not because it's backward.
This problem doesn't effect python methods because you allways bind a
method in python when you call it.  The question is how the initial
method gets bound.

  There is no one "right" way to bind a method. There are good
  reasons to sometimes bind a method to it's context and
  sometimes bind a method to it's container (ie instance).
  There are even sometimes reasons to bind a method to a
  calling namespace.

  The principle of least surprise doesn't help here, because
  methods defined in Python classes don't behave the way
  methods defined through the web do currently.

  We *need* control over binding, as well as reasonable defaults.

  If we can agree that we need binding control, the question
  arises as to some details and default names.

I agree there must be control over binding, although your arguments
above have not convinced me that Python Methods are doing it the right
way, actually, it's convinced more than my argument, compromisingly of
course, is more right.

  Should it be possible to do more than one binding at a time,
   using multiple names?  If not, then I'd agree that the name
  'self' should be used for either the context or container binding.

I'm with you so far with that.

  If both bindings are allowed at the same time, then 'self' should
  refer to container binding to be consistent with standard Python
  usage and some name like 'context' should be used (by default)
  for contextual binding.

That's what I disagree with.  I don't think you've given a strong
corollary to standard python usage.  The only strong argument you've
given so far is the ZClass one, but 10 gives you 1 that's not the
primary use case (it may be the one in Fburg).  People are going to be
defining these methods in Zope to make their lives easier, probably bad
design and mad hacks and no structure, but that's how 90% of the world
gets their work done and easing that burden is the usability task.  You
have not convinced me that:

1. Something called a Python Method should not resemble a method
definition in python.

2. Something called a Method in Zope should not behave like the other
Methods (meaning through the web objects) in Zope

3. Common, *documented* well understood URL manipulations (context) are
less important than (the less common) containment oriented design and
ZClasses.

Consider the following passage in the documentation:

   For example suppose you want to call a method 

[Zope-dev] Python and Perl scripts

[Chris Withers]

This one is probably the most useful of the lot ;-)

From: Michel Pelletier [EMAIL PROTECTED]

Greetings,

Well, Jim, Evan, Brian and I pow-wowed yesterday and came up with an
interesting change.  The world 'Method' is too overlaoded, as it means
too much to too many people.  Also, Python Methods don't work like
methods in python, which was my argument, but they are very useful and
there are sound reasons for them working like they do (which J, E and B
convinced me of yesterdat).  We have decided to change the name of
Python Methods to something else, the current candidate being 'Python
Script'.

'Script' objects make a lot of sense, they don't overload the concept of
methods, they describe an action that people commonly want to do (script
the web) and they clear up a lot of potential confusion for newbie and
old-hat alike.

The bonus for all of this is that the only thing that needs to change is
the name.  Which name is still an issue though, and we want your input.
what do you think of the idea of Perl Script objects?

The other issue, for the sake of documentation, is variable binding
(which was the root of our disagreement yest. Python Methods do not bind
variables and argument like methods in python do).  From what I can see,
Perl Methods seem to get 'self' pass in as a first argument.  Is this
all there is too it or are there more details?  Python Methods have five
special variables (defined on the bindings tab) that get created in the
namespace of the method.  Should perl methods work the same way and not
have special variables passed in as arguments?  This would probably be
more consistent with the Python model, and since 'self' will probably
not be the name of the variable bound to either the container or the
context it should be more explicit for perl methods also.

What do you think?

-Michel

___
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] My $0.02

[Chris Withers]

 From: Michel Pelletier [EMAIL PROTECTED]
 
 Well, Jim, Evan, Brian and I pow-wowed yesterday and came up with an
 interesting change.  The world 'Method' is too overlaoded, as it means
 too much to too many people.  Also, Python Methods don't work like
 methods in python, which was my argument, but they are very useful and
 there are sound reasons for them working like they do (which J, E and B
 convinced me of yesterdat).  We have decided to change the name of
 Python Methods to something else, the current candidate being 'Python
 Script'.

Well, I think script ain't right. How about 'Function', since, to me,
the things you've described sound exactly like normal Python Functions.
A function is callable but has no logic about a magic 'self' argument or
anything else, for that matter.

 methods, they describe an action that people commonly want to do (script
 the web) and they clear up a lot of potential confusion for newbie and
 old-hat alike.

'script' implies a sequential execution of a lump of code that doesn't
'return' anything. That doesn't sound like the old Python Methods.
They get arguments (from the namespace, some of which is introduced by
the bindings tab) and return something, probably text, that results from
their execution and, I guess, their return statement. Just to overstate
the point (;-), that sounds like a function to me...

 Python Methods have five
 special variables (defined on the bindings tab) that get created in the
 namespace of the method.  Should perl methods work the same way and not
 have special variables passed in as arguments?  

Sounds like they should have a binding tab and no 'special' self
argument. Maybe they should both subclass a generic 'Function' object
which provides the interface for this? Then other languages might get
implemented later down the line ;-)

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] Hippo Feed and Acquisition

[Chris Withers]

Toby Dickenson wrote:
 Thats fine until:
 
snip hilarious hippo metaphor

I liked that :-))

very accurately sums up some of the problems...

Although I'm not sure they're problems with the method binding this
thread was about.

The problems you describe seem to be with Acquistion in general. Other
than that, I don't have the answers :-(

Any ideas, anyone?

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] Python and Perl scripts

[jpenny]

On Fri, Oct 20, 2000 at 01:01:59PM +0100, Chris Withers wrote:
 This one is probably the most useful of the lot ;-)
 
 From: Michel Pelletier [EMAIL PROTECTED]
 
 Greetings,
 
 Well, Jim, Evan, Brian and I pow-wowed yesterday and came up with an
 interesting change.  The world 'Method' is too overlaoded, as it means
 too much to too many people.  Also, Python Methods don't work like
 methods in python, which was my argument, but they are very useful and
 there are sound reasons for them working like they do (which J, E and B
 convinced me of yesterdat).  We have decided to change the name of
 Python Methods to something else, the current candidate being 'Python
 Script'.
 
 'Script' objects make a lot of sense, they don't overload the concept of
 methods, they describe an action that people commonly want to do (script
 the web) and they clear up a lot of potential confusion for newbie and
 old-hat alike.
 

Oh, yuck!  Now we have to explain why PythonScript is safe, and JavaScript
sucks rocks (from a security standpoint).  And from common web convention,
it would appear that PythonScript would run on the client side, rather
than the server side.  Since the -let suffix appears to have taken on
a server side connotation, perhaps that can be used.

Python Function is not quite right, as it is fairly common (for me, at
least) to define some helper functions in a Python Method.  But it is
better than Python Script.

So, I guess my preferences would be:

PythonSafeScriptlet
PythonScriptlet
PythonSafeScript
PythonSafeFunction
PythonFunction
PythonBundle
PythonMethod
PythonScript

in descending order of preference.


 
 -Michel
 
 ___
 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 )

[Zope-dev] FYI: away for a few days

[Phillip J. Eby]

I'm going to be out of town for a few days, and won't be as quick to
respond to e-mails, if I respond at all during that time.  Ty will still be
around, though, to answer all your ZPatterns and LoginManager questions.
Right, Ty?  ;)


___
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: Michel's Reply

[Michel Pelletier]

Chris Withers wrote:
 
 From: Michel Pelletier [EMAIL PROTECTED]
 

Hmm.  I thought this was a internal series of emails, I just now noticed
that zope-perl got cc:ed on them somewhere in the middle.  Oh well, it
is some good discussion; I allways like to stir the shit!

-Michel

___
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] Python and Perl scripts

[Michel Pelletier]

[EMAIL PROTECTED] wrote:
 
  
  'Script' objects make a lot of sense, they don't overload the concept of
  methods, they describe an action that people commonly want to do (script
  the web) and they clear up a lot of potential confusion for newbie and
  old-hat alike.
  
 
 Oh, yuck!  Now we have to explain why PythonScript is safe, and JavaScript
 sucks rocks (from a security standpoint).  

The proposal is not for PythonScript but a "Python Script".  We are not
inventing a new language, this is python, we are just coming up with the
name for an object.  Don't capitalize it and you'll see what I mean.  Go
write a python script.  I'm gonna write a python script that handles
this HTML form.  If we do this with a python script instead of a DTML
method, it will be much clearer.  Wow, this perl script has lots of
slashes in it.

 And from common web convention,
 it would appear that PythonScript would run on the client side, rather
 than the server side.  Since the -let suffix appears to have taken on
 a server side connotation, perhaps that can be used.

Hmm.  Yes I agree the -let suffix may have a sttronger server side
flavor, but I disagree that the word script has any strong connection to
the client only.

 Python Function is not quite right, as it is fairly common (for me, at
 least) to define some helper functions in a Python Method.  But it is
 better than Python Script.

Function is just as technical as method.  These are OO techncial
programming terms (function less than method).  The idea is to lower the
bar for people using Zope.  People who only know HTML will be much more
likely to grok what a script is than a method.  We want to avoid
elitism.  Method is total OO elitism, function less so because it's very
language neutral, and script is like plain vanilla ice cream, everyone
gets it.

Like chocolate and coconut-shaving covered almonds, technical details
mixed in with your ice-cream will appeal only to a smaller crowd.  It
will not help define what 'ice cream' is.  It will turn away a group of
users who may have never know they could mix in sardines and sweet
tarts.  Technical details before the key idea is explained is
*dangerous* belive me, and it is the pitfall of all existing Zope
documentation to date.

The new DC documentation motto is "Explain key ideas in simple terms." 
Method is not a simple term.

 So, I guess my preferences would be:
 
 PythonSafeScriptlet
 PythonScriptlet
 PythonSafeScript
 PythonSafeFunction
 PythonFunction
 PythonBundle
 PythonMethod
 PythonScript
 
 in descending order of preference.

I'll add these to the list of candidates.  Thanks!

-Michel

___
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] Python and Perl scripts

[jpenny]

On Fri, Oct 20, 2000 at 02:18:47PM -0700, Michel Pelletier wrote:
 [EMAIL PROTECTED] wrote:
  
 The proposal is not for PythonScript but a "Python Script".  We are not
 inventing a new language, this is python, we are just coming up with the
 name for an object.  Don't capitalize it and you'll see what I mean.  Go
 write a python script.  I'm gonna write a python script that handles
 this HTML form.  If we do this with a python script instead of a DTML
 method, it will be much clearer.  Wow, this perl script has lots of
 slashes in it.

I understand, but if naming is under consideration, I worry about
inadvertant connotations.  I feel that in the web space, _-script
has come to mean that the language is a client side actor, witness
javascript, ecmascript, vbscript.  

(On the other hand, PythonScript, PerlScript, and ReXXScript appear
be server side stuff in ASP.) 

And I see a difference between PythonScript and Python Script, but
I don't hear it!

 Function is just as technical as method.  These are OO techncial
 programming terms (function less than method).  The idea is to lower the
 bar for people using Zope.  People who only know HTML will be much more
 likely to grok what a script is than a method.  We want to avoid
 elitism.  Method is total OO elitism, function less so because it's very
 language neutral, and script is like plain vanilla ice cream, everyone
 gets it.
 
 Like chocolate and coconut-shaving covered almonds, technical details
 mixed in with your ice-cream will appeal only to a smaller crowd.  It
 will not help define what 'ice cream' is.  It will turn away a group of
 users who may have never know they could mix in sardines and sweet
 tarts.  Technical details before the key idea is explained is
 *dangerous* belive me, and it is the pitfall of all existing Zope
 documentation to date.

Actually, I am not sure that script is much less technical than
function.  I think script, as in bash script, or scripting language
is very crabbed and technical indeed.  The only pre-computer usages
I know of script(n.) are indicative of a cursive style of writing,
apeper money,  or a thing that playwrights produce.  I don't think 
that playwrights are going to suddenly start wanting to use python!  
I think that script, as in "scripting language" is simply something 
that most people indeed do not get!

 
 The new DC documentation motto is "Explain key ideas in simple terms." 
 Method is not a simple term.
 

I don't disagree with your goal.  I do disagree with this particular
choice of words.  

I can see four potential properties that one could want to emphasize
about a python method.

1) It is safer (to the Zope server) than a python external method.
2) It safer to the end user than a JavaScript (it never touches the client).
3) It uses python, and not something else as its implementation technique.
4) In OO terms, it is not really a Method.

Hence the preference for Safe in the name.  Even a newbie ought not to
be able to cut himself too badly on a python method.

There is talk of perl methods.  So we need python in the description.

Now we just need a generic term, which will not cause other confusions
later on down the road for the concept.  I really don't like script,
especially next to a language name (in the web domain).  You don't like
function (which was not my suggestion).  Thingie seems a bit too non-
descriptive.  Widget has technical meaning.  Perhaps task or job are
suitable, as in
Safe Python Task
Safe Python Job
Safe Python Subtask
Safe Python Function
Safe Python Script

Then external methods, which are often also not methods, can become
Flexible Python Task
Flexible Python Job
Flexible Python Subtask
Flexible Python Function
Flexible Python Script

But if you really want to use
Tame Snake Thingy, and
Wild Snake Thingy,
go ahead, but please do not credit me in the documentation!

As another obesrvation, substituting script for method is not really all
that helpful for the other (misnamed) method, DTML Method.
DTML Script is just not all that much clearer!

 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] Python and Perl scripts

[Michel Pelletier]

[EMAIL PROTECTED] wrote:
 

snip good discussion

 Now we just need a generic term, which will not cause other confusions
 later on down the road for the concept.  I really don't like script,
 especially next to a language name (in the web domain).  You don't like
 function (which was not my suggestion).  Thingie seems a bit too non-
 descriptive.  Widget has technical meaning.  Perhaps task or job are
 suitable, as in
 Safe Python Task
 Safe Python Job
 Safe Python Subtask
 Safe Python Function
 Safe Python Script
 
 Then external methods, which are often also not methods, can become
 Flexible Python Task
 Flexible Python Job
 Flexible Python Subtask
 Flexible Python Function
 Flexible Python Script
 
 But if you really want to use
 Tame Snake Thingy, and
 Wild Snake Thingy,
 go ahead, but please do not credit me in the documentation!

Well they'll all go on the list of candidates!  Thanks for your input, I
kinda like task...
 
 As another obesrvation, substituting script for method is not really all
 that helpful for the other (misnamed) method, DTML Method.
 DTML Script is just not all that much clearer!

Rumor has it DTML Methods are going to be renamed to "DTML Template" or
something like that.

Keep in mind also that we are moving towards a new architecture with
"Documents" and "Templates" (ala HyperDOM).  I think Scripts fits right
in there:

Documents, Templates and Scripts

or

Documents, Templates and Methods

?

-Michel

___
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] Python and Perl scripts

[Steve Waterbury]

Michel Pelletier wrote:

 snip good discussion

and move on to something REALLY silly!  :^

 [EMAIL PROTECTED] wrote:
  descriptive.  Widget has technical meaning.  Perhaps task or job are
  suitable, as in
  Safe Python Task
  Safe Python Job
  Safe Python Subtask
  Safe Python Function
  Safe Python Script
 
  Then external methods, which are often also not methods, can become
  Flexible Python Task
  Flexible Python Job
  Flexible Python Subtask
  Flexible Python Function
  Flexible Python Script
 
  But if you really want to use
  Tame Snake Thingy, and
  Wild Snake Thingy,
  go ahead, but please do not credit me in the documentation!

 Documents, Templates and Scripts
 or
 Documents, Templates and Methods

I REALLY like Thingy!  And a very Pythonesque choice it would 
be ... :^)  Python Thingies and Perl Thingies.  How nice to be 
so connotationless!  ... but maybe not so connotationless ... 
recalling the usage of "thingy" in the Python, Monty oeuvre 
("YOU know ... THINGY!!") ... you might want to consider

Tame Snake Sex, and 
Wild Snake Sex, 

so then you have 
Documents, Templates, and Sex

Python Sex vs. Perl Sex? ... wow, just think of it!  
Of course, alibis about working late would have to be 
carefully worded ...

Sorry ... it's late on a Friday ... but I DO like Thingy!  :^)

Cheers,
-- Steve.

   oo _\o
\/\ \
  /
 oo _
"Sometime you're the windshield; sometime you're the bug."
- Knopfler

Stephen C. Waterbury   Component Technologies
Code 562, NASA/GSFC  and Radiation Effects Branch
Greenbelt, MD 20771   Engineering Web/Database Specialist
Tel: 301-286-7557  FAX:  301-286-1695
WWW:  http://misspiggy.gsfc.nasa.gov/people/waterbug.html
_

___
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] Python and Perl scripts

[Michael Bernstein]

Michel Pelletier wrote:
 
 Keep in mind also that we are moving towards a new architecture with
 "Documents" and "Templates" (ala HyperDOM).  I think Scripts fits right
 in there:
 
 Documents, Templates and Scripts
 
 or
 
 Documents, Templates and Methods

I tend to think of things as:

Objects, Views (or Templates) and Blocks.

The diference (for me) between a View and a Block is whether
they are intended to be accessed directly by a client
(browser). Blocks also tend to be reuseable in many views (I
typically have a Block (DTML Method) called main_navigation,
for example), and can be composed of other Blocks. Views
like index_html may be reused, but usually through
acquisition, not recomposition.

The lines are fuzzy though, since I'm usually using the same
types of objects (DTML Methods) for both Views and Blocks.
Perhaps we need an object type that is not directly
accessible from a client (but may only be called or rendered
from other objects) in order to clarify the distinction.

Michael Bernstein.

___
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: [Zope] IIS and PCGI

[Andy McKay]

Well I fixed this using a ISAPI filter which I will release soon (once I
have some time) that takes a url /a/b/c/x.pcgi/f/g/h, and passes
/a/b/c/x.pcgi to IIS so the file will run and /f/g/h to Zope.

My next question is has anyone succeeded in getting this to work to another
box over a mapped or shared win32 drive?

I mapped g:\ to my zope host, and then specified
PCGI_PUBLISHER=g:\pcgi\pcgi_publisher.py in my pcgi file. The problem seems
to pcgi-wrapper.exe which does not like a mapped drive. (line 485 of
parseinfo.c keeps spitting out missing publisher)...

Thanks in advance and apologies for the cross post to zope-dev but it is
more of a zope-dev question.

- Original Message -
From: "Andy McKay" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, October 17, 2000 1:33 PM
Subject: [Zope] IIS and PCGI


 Im fiddling with IIS and PCGI, I've looked at
 (http://www.zope.org/Members/brianh/iis_howto) the docs and got the server
 to work correctly in that http://127.0.0.1/zope.pcgi is the same as
 http://127.0.0.1:8080/

 However it doesnt seem to be carrying through the trailing path info (or /
 's) for example
 http://127.0.0.1/zope.pcgi/manage brings up 404. Using IIS 5.0, Win2k,
Zope
 2.2.1.

 Anyone encountered this and know the solution?

 Thanks.
 --
   Andy McKay, Developer.
   ActiveState.


 ___
 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 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 )