Re: [Zope-dev] Re: fdrake's fix for brian's fix for bug 1203 needs to be applied in other branches

2004-01-27 Thread Fred L. Drake, Jr.

Leonardo Rochael Almeida writes:
  Funny, with all the talk about 2.8 including only the ZODB work and
  fixes, I thought we'd have a 2.8 branch by now... :-)

Yeah, we're kind of call that the trunk for now, so we pick up the
general bug fixes as well.  Too many actual (active) branches makes
for true pain in managing patches.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] tcp port not 8080

2004-01-20 Thread Fred L. Drake, Jr.

ben strawbridge writes:
  I just installed zope and plone. It works fine and I can access the
  management console for it.  The problem is I am running tomcat on this
  box as well and it is already using port 8080.  I seaerched around the
  zope and plone sites but can't find anything about where to change this,
  except for references that it can be done. I also googled some terms to
  no avail.

It can indeed be changed.  The recommended way to do so depends on the
version of Zope you're using.  Which version is it?


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] CVS Head: Error Value: iterable argument required when adding objects

2004-01-19 Thread Fred L. Drake, Jr.

Jeremy Hylton writes:
  Where is that documentation?  I'm not able to find it.

There used to be a couple of .txt files for this, but I don't remember
where.  ;-(


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] [ZConfig] wishlist

2004-01-01 Thread Fred L. Drake, Jr.

Dieter Maurer writes:
  It uses top level keys for configuration.

Sigh.  We should change that.

  But anyway (even if session configuration were
  encapsulated in its own section),
  I would need to change the Zope schema (if I understand
  ZConfig correctly, which is not yet sure).

That depends on how we do it.  We could easily make an abstract
section type (think interface), and the current session machinery
and your custom machinery could both implement that.  Each would
define a section type that implements that interface, and the
resulting configuration object would be a factory for the session
manager.  (This is how log handlers are done.)

  Ideally, I would like to be able to combine schemas from schema
  components -- say: use the standard Zope schema and apply the
  following additions/changes.

If we used an abstract section type for a session manager, the Zope
schema would require the abstract type; loading the additional schema
component would be a matter of adding a %import line in the
configuration file.

  Thus, all my wishes are already addressed by the current
  ZConfig :-)

Glad to hear it!  There are probably changes we'll want to make to the
shape of the actual Zope configuration (like moving the session
management configuration to a section with an abstract type); input
like yours is very valuable in this area.  Thanks!


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] [ZConfig] wishlist

2004-01-01 Thread Fred L. Drake, Jr.

Chris McDonough writes:
  In a perfect world, it would be possible to extend or change the main
  section of a schema (or any section in a schema) with altnerate keys or
  sections, I think.  I have no idea how to do it, though.

Phillip Eby and I discussed the override issue a bit, and decided that
it wouldn't be too hard to do, but we had no concrete need.  Adding
keys and sections is easy with Phillip's schema extends='...'
support.  These ideas all revolve around creating new schemas, though,
so aren't quite what we've done with Zope itself.

We can already create new implementations of abstract types and load
them through %import in specific configurations; this only applies to
sections, though.

I suspect the current support is pretty much what we're looking for;
if we're forced to describe things as components in the configuration,
we'll be forced to deal with them as components in the implementation.
I expect this will lead to better understood implementations, as each
piece is more easily understood in isolation, and more readily
maintained.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: [Zope3-dev] ZConfig: a wish list

2003-12-30 Thread Fred L. Drake, Jr.

Barry Warsaw writes:
  I suppose that model precludes even access to %define variables after
  parsing.

That's right.  If you really want to control the structure of the pat
specifications, you need to deal with it explicitly; create a setting
to control the base directory, and then use os.path.join() to deal
with paths relative to that base.

   My usual response has been that it can already be done reasonably
   using something like:
   
   %define topdir /some/path/to/the/top/of/my/tree
   %define logdir $topdir/log
   
   some-logfile   $logdir/interesting.log
   other-logfile  $logdir/another.log
  
  Which is essentially what I do now.

Have your users complained that it's too much?

  That's the primary motivation, for sure.  The idea is that if ZConfig is
  going to be the configuration language that Mailman3 site admins use,
  I'd like to reduce to a minimum the number of options or lines of files
  they need to look at, decide about, and change.  If they can simply
  define a basedir and have all the defaults be defined in terms of that,
  it would be a bonus.

I don't know enough about Mailman3 configuration to know how what's
being done in the config file or how many decisions the site admin
needs to deal with.  Is there something for each list?

  I'm not sure it's useful, but the style of the schemas I've been writing
  make all that extra stuff kind of redundant.  I actually depend on the
  type and attribute names being the same because of the way I dig values
  out when I post-process stuff in Python.

This sounds very strange to me.  Perhaps we should take a look at it
when we're in the same town tomorrow.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] [ZConfig] wishlist

2003-12-30 Thread Fred L. Drake, Jr.

Dieter Maurer writes:
  Today, I incorporated our Zope extensions into Zope 2.7 and had to
  determine how I can provide the necessary configuration through
  ZConfig. I feel the configuration process is not yet as modular
  as it should be?

There's certainly room for improvement.

  Let's explain what extensions I have:
  
   1. an alternate Transience implementation for Zope sessions

I don't know how the session machinery works in Zope; if there's a
section to configure that at all, it should at least be easy to make
it possible to provide an alternate section type that can be used.

What changes did you need to make to Zope to make this configurable?

   2. a new log handler rotated_logfile (which performs automatic
  daily rotation with log files named prefix.date)

This doesn't need any changes in zLOG; you should be able to provide a
new component and use %import to load it in the configuration.

   3. a common piece of configuration used for communication
  between Zope and a checkZope process (which supervises
  that Zope responds sufficiently fast)
  
  I solved 1 and 2 by rudely modifying Zope sources (zLOG/component.xml
  and associated handlers, Zope/Startup/zopeschema.xml and associated
  handlers). I do not yet have a solution for 3 but I probably will
  give the checkZope process the complete Zope schema and configuration
  file.

I'm not sure why you want the checkZope process to load Zope's
configuration at all.  Can't you just use a separate configuration
file?  If there are portions that need to be shared, you can place
those in a separate file and %include that into the Zope and checkZope
configurations.

  Almost surely, it would not have been necessary to modify
  the zLOG configuration to get a rotated_logfile because components
  and sectiontypes provide enough modularity.

Yup.

  However, schemas and configuration files seem not to be modular.

Not terribly, no.  That wasn't a requirement that anyone made me away
of at the time.

Bits of configuration files can be stored in separate files and
composed using %include.

  I would like to compose schemas and configuration files from
  components: e.g. combine the standard Zope schema and a small
  schema for our extensions to form the schema used by the extended
  Zope, combine the configuration file from long living
  Zope settings (maintained in CVS), instance specific Zope
  settings (locally maintained) and configuration fragments
  used by Zope and other components (e.g. the checkZope process).

One approach we've taken on some projects is to place all settings
within sections, leaving the top-level as a place to put the
sections.  This wasn't done for the main Zope schema due to various
forces; perhaps that was a mistake.

  I think, a general include function for schemas (including not
  only types but complete schemas) and configuration files
  could provide this kind of modularity.

Have you looked at the schema extends=... support Phillip Eby
added?


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: [Zope3-dev] ZConfig: Keytype and section type extension

2003-12-29 Thread Fred L. Drake, Jr.

Barry Warsaw writes:
  Since I didn't understand what keytype actually provided, even after
  reading the docs on it several times, I've never found a need for it
  wink.

Sounds like I need to improve the docs for this.

Changing the keytype allows different interpretations for keys.  The
only thing required of keys at the lowest level of the parser is that
keys do not contain spaces.  The basic-key datatype is used to
create a case-insensitive handling to keys.  Setting keytype to
identifier would require that all keys in sections of that type be
Python identifiers, and would be case-sensitive.  Another keytype
might allow email addresses to be used as keys:

def email_address(text):
user, host = text.split(@)
host = host.lower()  # normalize what can be normalized
return [EMAIL PROTECTED] % (user, host)

This can be especially useful when implementing a section type that
acts as a mapping:

sectiontype name=email-mapping
 keytype=mypkg.datatypes.email_address
 datatype=mypkg.datatypes.mapping
  key name=+
   attribute=mapping/
/sectiontype

where the additional datatype simply discards the section object and
returns the key-value mapping:

def mapping(section):
return section.mapping

  Even with the above, I'm still not 100% sure what specifying keytypes
  does for me, or why or when I'd want to use it.  On the face of the
  above, if it makes it easier to use generalize base section types, then
  it might be a good idea.

The specific base section type I wanted to provide as part of a
standard library of section type was just such a mapping section as
described above.  If both of the proposals are considered acceptable,
I'd be able to provide a basic type that could be specialized to use
email addresses as keys very simply:

import package=ZConfig.components.basic /

sectiontype name=email-mapping
 keytype=mypkg.datatypes.email_address
 extends=ZConfig.components.basic.mapping /

No need to monkey around with the weird key name=+ .../ stuff.  ;-)


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: [Zope3-dev] ZConfig: Keytype and section type extension

2003-12-29 Thread Fred L. Drake, Jr.

Phillip J. Eby writes:
  That reminds me...  is there any way for section *names* to be 
  case-sensitive, or at least case-preserving?  For example, if one were 
  simulating Apache-style configuration like:

There isn't, but there was at some point.  Nobody here at ZC seemed to
think it useful at the time, so it was removed as a simplification.

What we had was a nametype attribute for sectiontype elements; it
was just another datatype function.

I'd be happy to have that back if there's a real use for it.  The
current situation, where the conversion is coded directly in
ZConfig.cfgparser, isn't very flexible.

Would it suit your requirements if the name type were associated with
the section type, and inherited from the base type if not specified?

  Currently, IIRC, the '_name' attribute of the resulting section will be 
  '/foo/bar/baz'.

The _name attribute is an implementation detail; use the
getSectionName() method instead.  I'm likely to change the _name
detail just to be facetious.  ;-)


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: [Zope3-dev] ZConfig: a wish list

2003-12-29 Thread Fred L. Drake, Jr.

[EMAIL PROTECTED] writes:
  Since the wiki Fred created on zope.org doesn't (or didn't) seem to
  work, I'll post my wish list here.

Good strategy.  ;-)  The wiki definately didn't work, and no one seems
to know why.

  Feel free to tell me why I don't really want what I think I want. :)

Rest assured, my life is based on telling you why you don't really
want *that*!

  - import honors prefixy
  
In my schemas, I have a number of import statements, each with
package and file attributes (since the default component.xml naming
scheme doesn't work for my code layout).  Unfortunately, if my
schema tag has a prefix attribute, import's package attribute
doesn't honor it, so there's a lot of duplication.  For example:
  
schema prefix=mailman.config.components
import file=databases.xml
import file=domains.xml
...

+0

Well, import package=.foo/ doesn't honor the prefix, but that's
not the same as what you describe above really (you're using the
prefix instead of an omitted package).  I agree that the package
attribute should use the prefix; will fix.

Regarding an omitted package attribute being replaced by the prefix, I
think that's fine as long as there's a file attribute.  No existing
schema is affected.

  - $ substitutions in defaults
  
Often, my defaults for keys can be expressed in terms of $
substitutions that are more general for my system.  Unfortunately,
there doesn't seem to be any way to make this work.  ZConfig itself
doesn't perform $ substitutions on default values, and there doesn't
appear to be a way to get at %define variables from Python.

-1

This would mean that a schema could require that certain %define names
be provided by a configuration.  It's certainly possible to make
changes to ZConfig to support this, but they'd be fairly substantial.

The current model makes the %define and $-substitution a syntactic
detail of the configuration language.

One of the chief motivations for this is to allow some directory to be
specified as the home for other directories to be specified relative
to.  For example, log files might be specified relative to a log
directory or an instance home directory.  My usual response has been
that it can already be done reasonably using something like:

%define topdir /some/path/to/the/top/of/my/tree
%define logdir $topdir/log

some-logfile   $logdir/interesting.log
other-logfile  $logdir/another.log

Another possibility is to perform os.path.join() operations using the
base and relative portions in the application.  This is less than
ideal, but quite workable.

Still another possibility is that a new relative-directory type be
implemented and some way to say relative-to-what (where what is some
other setting, possibly at an outer layer in the configuration
hierarchy).  References to outer layers of the hierarchy makes this
tedious to implement at best.

Given that it's not clear that this is needed, the additional
complexity seems excessive.

If you have a (real) use case not related to specifying absolute
directories, or for which the $-substitution approach isn't viable,
please tell us about it.

  - default sections
  
At some point I thought it might be nice to be able to define
default sections, so that you wouldn't have to require something
like defaultsect/ in your config file.

+1

This is something Chris and I wanted from the beginning, but we never
decided on the best way to approach it.

  - Python command substitutions
  
Something like:
  
%define hostname socket.getfqdn()
  
although I know there are some difficult issues with this (imports
for one).

Do you really want this, or would some way to pre-define %define names
be sufficient?  This feels slightly less nasty than requiring %define
from the schema.  It would require opening up the API a little more,
though.

  - attributes default to type
  
When defining a section, if I don't provide a section name, it would
be nice if the attribute was defaulted to the section type.  E.g. in
this example:
  
section type=databases name=* required=yes attribute=databases/
  
IWBNI I didn't have to duplicate the databases string.

-0

This seems like a really minor bit of syntactic sugar.  It would be
easy to implement, but doesn't seem like it really buys much.

I'd be more interested in making name optional, defaulting to *, if
attribute is specified.  That's about the same amount of sugar, and
seems more useful to me.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: [Zope3-dev] ZConfig: Keytype and section type extension

2003-12-29 Thread Fred L. Drake, Jr.

Phillip J. Eby writes:
  Well, in that case, can we have a 'getItems()' that returns only the 
  key-value pairs for actual attributes, and does *not* include keys for 
  values that weren't explicitly specified in the configuration file and 
  don't have defaults?

Not a bad idea.  It will require snaking information through
ZConfig.matcher a bit differently, but shouldn't be particularly
difficult.

  Unless of course the keys were strings rather than Unicode, in which case 
  it'd be even simpler.

Yes, and so they should be (strings rather than Unicode, that is).
I've changed this in CVS.  It was never intended that identifiers be
Unicode; this was simply an accident of implementation.

  (The issue here is that Python requires keyword arguments to be
  strings rather than Unicode, even though attribute names can be
  Unicode.  ZConfig sets attributes using unicode because ZConfig
  schemas are XML, and therefore Unicode.)

Annoying, isn't it?  Not sure it's worth fixing in Python.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] ZConfig: Section type datatype inheritance

2003-12-28 Thread Fred L. Drake, Jr.

This past September, Phillip Eby and I discussed a variety of ZConfig
issues on one list or another.  Two particular issues I've thought
more about, and think I'm reversing myself on them.  ;-)

I'm going to describe each issue in a separate email, including why
I've changed my mind about them and what the consequences are for
ZConfig users.  Please respond to these messages if you think the
proposed changes will have a negative impact on working code.

Inheritance of the datatype when extending a section type
---

Currently, ZConfig section types that extend another do not inherit
the datatype of the type they extend.  Phillip argued that, at least
for schema extensions, the datatype should be inherited from the base
schema.

I thought it better to explicity request the same datatype was a
better approach because of way we've been using ZConfig in some of the
core packages.  Each concrete section type really uses a different
datatype; sharing configuration handling is accomplished only within
Python.  When this is the only way section types are being used,
explicit is the only way to do things.

While trying to create some fairly basic section types that are easy
to specialize using extension, this can be less than desirable.  What
it boils down to is that it's difficult to create section types that
can be easily specialized with a minimum of additional information in
the schema; a fair bit of boilerplate is needed to change a small
amount of behavior.

If we add inheritance of the datatype for section types, this affects
only section types that extend another section type where the base
specifies a datatype and the derived type does not; in that case, the
datatype of the base will be used instead of the null datatype.  If
the null datatype is needed, section types that expect it to be used
can add the attribute datatype=null to achieve the current effect
(in fact, that works now).

No existing unit tests are affected.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] ZConfig: Keytype and section type extension

2003-12-28 Thread Fred L. Drake, Jr.

This is the second of two messages proposing ZConfig changes.

keytype override and section type extension
-

ZConfig currently requires that derived section types not specify a
keytype attribute, used to change the interpretation of the keys.
The intent is to ensure that keys defined in the base section type
will still be recognized and associated with the same (or equivalent)
settings for the derived type.

In most cases, this is reasonable behavior.  Unfortunately, it makes
it tedious to specialize general base section types in some cases.  Of
particular interest is the case of section types that define no
specific keys, but accept arbitrary keys using

key name=+ attribute=some_mapping/

For such cases, it can be desirable to change what keys are inserted
into the mapping by changing the keytype of the encosing section type.

Allowing keytype overrides would not affect any existing schema, since
such schema are currently rejected.

One unit test would need to change; the test currently checks that
specifying a keytype for a derived section type raises a SchemaError
exception.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] apply()'s PendingDeprecationWarning

2003-12-05 Thread Fred L. Drake, Jr.

Python 2.3, 2.3.1, and 2.3.2 generate a PendingDeprecationWarning when
apply() is called.  This is reasonable since apply() has been
deprecated, but can be a real nuissance for code that intends to be
portable to Python versions back to 1.5.2.  Unfortunately, the logging
package distributed with Python has that constraint (don't ask why,
please; I really don't know!).  Anyone watching the results of the
test runs has probably noticed that these warnings are polluting the
test output still, and aren't being triggered by Zope code.

Guido has conceded that these warnings can be removed from Python, so
I've removed them for the upcoming Python 2.3.3 release as well as for
the future Python 2.4.

Just thought everyone would be thrilled to know.  ;-)


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] typo fix

2003-11-26 Thread Fred L. Drake, Jr.

J. Cameron Cooper writes:
  Here's a super-quick bug fix for someone with a Zope development
  tree. I'm currently trying to decide how one might turn a
  directive.
  
  Zope/skel/etc/zope.conf
   # If this directive is turned, Zope performs 'product installation'
   # If this directive is turned on, Zope performs 'product installation'

Thanks!  I've fixed this for 2.7 and the development trunk.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Rendering xml content in ZPT

2003-11-13 Thread Fred L. Drake, Jr.

Florent Guillaume writes:
  That's a packaging bug in the packaged Linux binary versions of Zope
  2.6.* that Zope Corp won't fix, cf the bug tracker (and anyway there
  will be no binary versions for Zope 2.7.*). The package is missing some
  shared library files for expat.
  
  You'll have to use your own installation of python.

Another solution would be to use the bundled Python to install a
recent version of PyXML; Expat is bundled directly and does not
require any external libraries.

This is also the approach taken in newer versions of Python (2.3 and
newer).


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Rendering xml content in ZPT

2003-11-13 Thread Fred L. Drake, Jr.

Antonio Beamud Montero writes:
  I have downloaded the last version of PyXML and I have installed using
  the python version of Zope 2.6 and all was sucessfully, but doesn't work
  either...

Interesting.

There should be a reasonable work-around for this; if you could check
the existing report in the issue tracker and make sure it's complete
(including the complete error message and any traceback information),
and assign it to me to look into a work-around, I'd appreciate it.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Zope doesn't know enough mime types.

2003-11-04 Thread Fred L. Drake, Jr.

Chris McDonough writes:
  Oo, oo, Fred.  I just checked in a feature on the HEAD only that lets
  you configure Python warning filters using the config file.  I think it
  passes Brian's criterion for merge save for any tests.

The MIME types support now passes Brian's criteria; I finally added a
stanza to the zope.conf.in file that describes it.

  It would be nice to have all the config stuff the same on HEAD as on 2.7
  so we don't run into merge problems later... If we agree and I promise
  to write a test for the warnfilter, maybe you could just copy the

Have you written these tests yet?

  zconfig schemas and datatype files from the HEAD for the Zope.Startup
  package and the zLOG package and merge that way instead of surgically
  porting the mimetypes stuff to the 2.7 branch.  The zope.conf.in file
  needs to be merged as well.

What was affected in zLOG?

I'm glad to port these features to Zope 2.7 if you've got the tests
ready and Brian thinks that makes sense.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Zope doesn't know enough mime types.

2003-11-04 Thread Fred L. Drake, Jr.

Chris McDonough writes:
  Thats where I defined the sectiontype.

I don't think it belongs there; it really has nothing to do with the
logging.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Zope doesn't know enough mime types.

2003-11-04 Thread Fred L. Drake, Jr.

Chris McDonough writes:
  I was thinking that too after I did it. ;-)  I'll move it to
  Zope.Startup.

Cool.  I'll be so bold as to suggest using a separate ZConfig
component instead of sticking the section definition in the main
schema.  If you define the section type in warningfilter.xml, import
it using

import package=Zope.Startup
file=warningfilter.xml /

in the main schema.  Any datatype or handler functions can then be in
a separate module within Zope.Startup as well, keeping it nicely
compartmentalized.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Zope doesn't know enough mime types.

2003-10-31 Thread Fred L. Drake, Jr.

Brian Lloyd writes:
  fyi, I'm ok with merging this to 2.7 if it already is on the HEAD, 
  has tests, and has at least some minimal docs.

It's on the head, and I've performed a check on a running Zope process
that new types specified this way are recognized.  I'll check in unit
tests of the lower-level functionality that supports the feature
shortly.  The feature is documented in the configuration schema, and
I'll add something to the example configuration about it as well.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Zope doesn't know enough mime types.

2003-10-30 Thread Fred L. Drake, Jr.

I wrote:
  Adding some configuration to Zope to identify additional mime.types
  files to load may be a good idea, and should not be too difficult.

I've done this on the Zope 2 head; I don't know if it should be ported
to the Zope 2.7 branch.

Zope's configuration file can now have an additional key,
mime-types, which specifies an additional file of MIME type
associations to filename extensions.  The key may be given more than
once if desired.

The MIME type associations are specified in the same way as in
Apache's mime.types file.  Each line in the file may be blank, a
comment starting with #, or a type association:

foo/bar  ext
foo/bat
foo/baz  ext1 ext2 ext3


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Zope doesn't know enough mime types.

2003-10-30 Thread Fred L. Drake, Jr.

robert writes:
  would be nice if we had it in 2.7

That's up to Brian Lloyd.  I think it's a low-risk change, but we
really want to stabilize and finish 2.7.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Failure on make instance

2003-10-27 Thread Fred L. Drake, Jr.

Sidnei da Silva writes:
  I just cvs'upped zope from the 2.7 branch, make clean; make; make
  instance; and it failed with:
  
  running install_data
  error: can't copy 'zdaemon/component.xml': no matching files
  make: *** [install] Error 1
  
  Looks like a file is missing, or some script wasn't updated. 

Sigh.

I was looking over this problem this morning when our automated tests
screamed foul, and I couldn't reproduce it.  ;-(

Of course, once your mail arrived, it was a lot easier t fix for some
reason(!).  When I'd applied the patch from the trunk, I'd applied,
tested, and committed; what I didn't do was cvs add the new files on
the 2.7 branch!

Sorry for the resulting autotest spewage.  The files have now been
added on the branch, so the testers should be happier.  And it should
actually work for you.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Failure on make instance

2003-10-27 Thread Fred L. Drake, Jr.

Sidnei da Silva writes:
  Maybe because the phrase 'file missing' triggered something :)

Something like that, perhaps!  Jeremy's comment wasn't so different,
but didn't clue me in the same way.  I'm glad to have fixed it for you!


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Zope doesn't know enough mime types.

2003-10-24 Thread Fred L. Drake, Jr.

Romain Slootmaekers writes:
  But why the modified mimetypes file has to contain about 40 less 
  mime-types than the corresponding file in a python installation from 
  python.org is a mistery to me.

The mimetypes module in general has a problem: the known MIME types
are stored in the source code.  The table in the module has definately
been extended over time; make sure you're looking at the right version
of the module from python.org.

The module *tries* to load definitions from known external lists of
MIME types (as would have been installed with Apache or Netscape), but
isn't guaranteed to find these external lists (they not be installed,
or may be installed in atypical locations).

Adding some configuration to Zope to identify additional mime.types
files to load may be a good idea, and should not be too difficult.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: [Zope] Using 2.3.2 for Zope 2.7

2003-10-06 Thread Fred L. Drake, Jr.

On Fri, 2003-10-03 at 17:27, Jamie Heilman wrote:
  In 2.3 you can no longer declare new classes in a Script object.  It
  bitches about a lack of __name__ attribute.  I haven't really had the
  time to look into it closely, but it does effect the examples shipped
  with zope, and actually its just a very useful thing to be able to do.
  Whatever this problem stems from, there will probably be more because
  of it.

In Python 2.3.x, when a class is defined the __name__ of the
encompassing module is looked up.  I suspect Python Scripts can be
fixed by defining __name__ in the globals dictionary in which the code
is executed.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: [Zope-dev] Using 2.3.2 for Zope 2.7

2003-10-03 Thread Fred L. Drake, Jr.

Paul Winkler writes:
  then by all means, 2.3.2.  These audits seem to be hard to get going
  on a regular basis (we've been on python 2.1.3 for how long now?)
  so I see no point in blessing a version of python that's already not
  latest-and-greatest.

It's not just that Python 2.2.3 is no longer the latest and greatest,
but that it's no longer on a maintenance track; that's what 2.3.x is.

  The only counterargument i can think of is that 2.3 may not be
  bundled with many linux distros yet. I've always compiled my own
  python for use with zope, so I don't know how big a deal that is.

If someone can set up Zope, they can install Python in their sleep.  I
don't think this is an issue at all.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: [Zope] Using 2.3.2 for Zope 2.7

2003-10-03 Thread Fred L. Drake, Jr.

Chris McDonough writes:
  Currently, Zope still claims it works with 2.2.X (via the configure
  script's acceptable versions feature).  Should we continue to make
  that claim true by not depending on any Python 2.3-specific features in
  the Zope core?  I don't think there are a lot of super-compelling core
  and/or library differences between Pythons 2.3.2 and 2.2.3 that would
  make this a hardship on core Zope developers.

Requiring 2.3 (any flavor) would allow us to drop the copy of the
logging package from Zope 2.7 and newer.

There are greater benefits for Zope 3, where we have several modules
and packages laying around that would no longer be needed (logging,
csv, gettext).

I also don't know that we should consider 2.3.1 acceptable for any
version of Zope.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] ZConfig changes

2003-10-03 Thread Fred L. Drake, Jr.

Phillip Eby and I both checked new functionality into ZConfig today;
the documentation has been updated.  If these changes are still
looking good in a week or two, I'll plan on releasing it as ZConfig
2.0.

Both sets of changes revolve around schema extension, but they support
different things.  Phillip's changes allow one schema to be derived
from one or more other schema.  My changes allow configuration files
to load additional schema components.

Please try these changes and see how they work for you.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] PythonLibraries Product

2003-09-11 Thread Fred L. Drake, Jr.

Tres Seaver writes:
  Actually, the restricted case is the one which has the real win;  the
  free-floating library is pretty, but not semanticaally needed.  An
  added argument:  a ZPT with its own private library becomes, in effect,
  a Zope3 view component;  adopting such beasts will ease migration to
  Zope3.

And it keeps all the pieces easy to locate!  +1

  For the filesystem representation:  what if we just have two files for
  templates with libraries:  'foo.html' and 'foo.html.py'?  Tools will
  like that better than either of the approaches which try to preserve the
  twins as a single file:

The current Zope 3 filesystem synchronization doesn't currently
support writing multiple files for a single object; every object is
expected to be either file-like or directory-like.

There are a few ways to approach serialization of a view that contains
both a template and Python code:

- Serialize it as a directory containing two files.

- Serialize it as a file containing the template, and make the Python
  code live as an extra, which would be written to a file in the
  metadata storage area (tedious to work with, but could be an
  otherwise normal .py file).

- Change the filesystem serialization so that multiple files can be
  generated to represent a single object.  I think this would require
  a substantial amount of work.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: tal i18n and ZopeStarter test failures

2003-08-29 Thread Fred L. Drake, Jr.

Chris Withers writes:
  Can I take a peak at the config.xml you're using for autotester.py?

I'm running make ftest test from the command line.

  What versions of python are you using for Python 2.1 and Python 2.2
  resepctively?

Python 2.2.3 for everything.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: tal i18n and ZopeStarter test failures

2003-08-28 Thread Fred L. Drake, Jr.

Chris Withers writes:
  I see these tests fail on both Windows and Linux.
  
  What gives? Who checked in this code without running the tests?!

As I've indicated previously, I don't see these tests failing on Linux
at all.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] A First Look at Zope3

2003-07-31 Thread Fred L. Drake, Jr.

Chris Gray writes:
  I checked out Zope3 from CVS yesterday and had a go at it for the first
  time.  Granted that it is a work in progress, I did have a few comments
  from a user's (rather than a developer's) perspective.

Thanks for taking the time to look at Zope 3!  We definately
appreciate comments from users and potential users.

  About the new look to adding objects in a folder -- I see the point of
  going to a list of contents with a text input to assign a name (so you can
  see what names are already in use),

This can vary based on the type of object and how it's been
configured.

  but I see one problems.  The text
  input appears at the top of the list and the button to commit the change
  is at the bottom of the list.  This will become more inconvenient as a
  container's list of contents grows.  Perhaps the buttons should always be
  near the text input.

That's a good idea, and very reasonable.  I will take this opportunity
to note that simply pressing Enter (or Return, depending on your
keyboard!) will submit the form as well.

There is a zope3-dev list available that specifically deals with Zope
3; sending your comments and observations there will reach more of the
active Zope 3 developers.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: TALES idea: tuple unpacking

2003-07-29 Thread Fred L. Drake, Jr.

Shane Hathaway writes:
  - You have to be careful not to use double quotes in expressions. 
  (Ampersands and less-than/greater-than signs are tricky too.  Watch out 
  for pairs of hyphens!)

This is FUD.  TAL can handle these things quite well; the problem is
that many web developers don't have a clear understanding of layers of
encoding (a seriously unfortunate state of affairs, though
understandable given the time pressures of creating/updating a site).
Encoding quotes inside an attribute values means that the expression
(Python or not) is harder to read, but if it doesn't still work,
there's a bug in the implementation.  I'll be glad to donate some of
my time to fix any such bugs.

Othan than this, I agree with you on this topic.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: TALES idea: tuple unpacking

2003-07-29 Thread Fred L. Drake, Jr.

Shane Hathaway writes:
  I'm not quite sure what you're saying.  The following fails compilation:
  
  span tal:content=python: abc /

That's because you've broken the syntax.  It should have been:

span tal:content=python: quot;abcquot; /

or, more legibly,

span tal:content=python: 'abc' /

I think the problem is that it's easy to think of TAL as little bits
of different syntaxes, but that's not actually what's happening.  The
syntaxes are layered on top of each other, and where there are
characters meaningful to more than one layer, they have to be encoded
so they are interpreted by the proper layer.

  Hence you need to be careful not to use double quotes in expressions.  I 
  run into this every day.
  
  I'm a little wary of expressions like this:
  
  span tal:content=python: 1  0 /
  
  ... being converted by buggy XML or HTML software to this (I've seen it 
  happen before):
  
  span tal:content=python: 1 gt; 0 /

That's not buggy; that's what you should have written to start with.

  Finally, if you use a pair of hyphens in an expression and later use XML 
  syntax to comment it out while leaving the pair of hyphens, the block is 
  technically not well-formed.
  
  http://www.w3.org/TR/REC-xml#sec-comments
  
  For example:
  
  !--
  span tal:content=python: 'What should we do--walk or run?' /
  --
  
  This is not something that should bother anyone, but I wanted to support 
  my assertion. ;-)

That's life.  If you change the document, you may have to change
context.  If you want to make it possible to enclose something in a
comment, you have to encode your content differently.  For the double
hyphen, encode at least one of them like so:

!--
span tal:content=python: 'What should we do#45;-walk or run?' /
--

In general, I'd recommend using a syntax-highlighting editor to help
detect this one early, or even a proper XML editor for those who can
tolerate them.

I hope this makes sense as I've described it.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] breaking apart INSTANCE_HOME.

2003-07-25 Thread Fred L. Drake, Jr.

Chris McDonough writes:
  I propose that we add two more options to the config file:
  
  import-directory
  extensions-directory

I'd like to suggest that we call these imports and extensions, to
be parallel with the products multikey.

For products, we use the specified directories to add to the Products
package, but that makes sense given that the base Products package is
a required component.

For imports and extensions, we should consider using the specified
directories *instead* of the default.  This is easy enough; if the
directories are given as relative directories, they should be resolved
relative to config.instancehome; the schema can then include the
defaults and very little new code will be needed.

  I'm sure that utilizing these options in the config file will break
  things that rely on having a monolithic INSTANCE_HOME such as products
  that attempt to do something like import_dir =
  os.path.join(INSTANCE_HOME, 'import').

Any product that does that will prove fragile eventually.  We just
need to make sure the core doesn't do anything like that.  ;-)

  So I propose that the stock Zope instance home install continue to
  follow the old pattern (where everything is installed into a single
  instance home directory), but we provide the advanced config file
  options for roll-your-own packagers and advanced users.

This sounds like a really good plan to me!


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] breaking apart INSTANCE_HOME.

2003-07-25 Thread Fred L. Drake, Jr.

Chris McDonough writes:
  Actually,  both of these directories have historically worked in much
  the same way as the Products package does.

Ok, well, that's still not hard to do; we just add the bootstrap
directories to each of the lists once we've read the config.

  A software home may have (actually currently must have) an import
  directory.  Zope currently slurps various TTW examples from a zexp
  file in the software home import directory.  I'd really like to dump
  this dependency, but it would take a bit of work.

Ah, that's right.  I keep trying to forget about that.

One approach may be to use the import mechanism but not the import
search mechanism for that.  So there's still a .zexp file in the
software, but it's not part of the general import/export support.

  The Extensions directory... errr.. this should probably not be in a
  software home anymore.  I can't think of anything that would break were
  it to not be there anymore (besides products that depend on the physical
  layout of the software home, which shouldn't exist).

So this one doesn't present a problem.  The default list will only
include the Extensions in the INSTANCE_HOME, and configuration will
override that if something else is desired.

  Personally, I think we should just hardcode '/home/fred/zope/import'
  into the core as the import directory and be done with it. ;-)

That's fine with me.  At least it won't be accessing *your* imports
directory.  ;-)


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] TALES idea: tuple unpacking

2003-07-23 Thread Fred L. Drake, Jr.

Paul Winkler writes:
  In this case, consider a trivial change to (or wrapper around) 
  listFilesByUser to make it return a sequence of dictionaries
  like {'user': some_user, 'files': (file1, file2...)}

This is exactly what the proposal I posted a couple of weeks ago was
trying to avoid.  While adding another layer of indirection around the
actual call to listFilesByUser() isn't all that costly, these things
add up, especially since so many temporary objects are getting created
and thrown away.

I know for Zope 3, we'd like to get away from having to write a view
class simply to hook up helpers like this when something simpler would
do.

So far, two distinct approaches have been presented, with minor
variations for each.  I won't go into the variations, but the two
approaches are:

- Use a Python-like sequence unpacking syntax.  This is probably most
  comfortable to template authors who are Python programmers first,
  and web guys (or gals!) second.

- Use the namespace qualifiers to get an adapter to handle converting
  container lookup to a sequence indexing operation.  This plays off
  the machinery being built anyway, so is quite attractive, and
  doesn't affect the basic syntax or implementation of TAL, but only
  of the TALES expression engine.  This is very attractive because it
  pushes the support for this feature somewhere the application
  controls in as much detail as it wants.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] TALES idea: tuple unpacking

2003-07-23 Thread Fred L. Drake, Jr.

Gilles Lenfant writes:
  I'm interrested into adding some other wishes for the next ZPT versions.
  Where could those wishes be posted  ?

This is the place.

There's only very limited resources available at Zope Corp to make
changes happen right now, so be prepared to help make changes if
there's concensus that your proposal should be accepted.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: TALES idea: tuple unpacking

2003-07-23 Thread Fred L. Drake, Jr.

Philipp von Weitershausen writes:
  Why wouldn't that be possible with a_list/index:?i?

I think making it a_list/index:i is fine.  The adapter for index:
will get the index as a string and convert that to an integer and
return a_list[i].  The index: adapter simply represents a namespace in
which all names look like integers.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: TALES idea: tuple unpacking

2003-07-23 Thread Fred L. Drake, Jr.

Paul Winkler writes:
  I guess I don't understand the goal. Are we trying to make it
  so that zpt authors don't have to know any python?
  I really think that's a mistake.

There are those that consider using python: expressions in ZPT should
be discouraged, primarily because it's yet another syntax for a web
developer to learn.

I'm not necessarily one of them, but I am sympathetic with that
reasoning.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] current zope2 head warnings with cur-cvs python

2003-07-11 Thread Fred L. Drake, Jr.

Anthony Baxter writes:
  Running the current Zope2 HEAD with current-cvs python, 
  starting gives the following 3 warnings.
  
  /home/anthony/src/zope/ZopeHead/lib/python/ZServer/medusa/test/max_sockets.py:53: 
  DeprecationWarning: integer argument expected, got float
for i in range(1 + len(sl) * 0.05):
  
  /home/anthony/src/zope/ZopeHead/lib/python/AccessControl/User.py:438: 
  DeprecationWarning: assignment shadows builtin
SpecialUsers.super=emergency_user

These two are now fixed.

  --
  2003-07-11T22:40:10 PROBLEM(100) OFS.Application Duplicate Product name
  After loading Product 'README.txt' from '/tmp/z27/Products',
  I skipped the one in '/home/anthony/src/zope/ZopeHead/Products'.

Hmm.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] setup.py bug

2003-07-03 Thread Fred L. Drake, Jr.

Eugene Morozov writes:
  I've decided to try Zope 2.7 from CVS. I prefer to package everything
  installed on my system, so I've built Zope RPM package but it didn't
  work with ZEO because setup.py doesn't install ZEO.auth package. 

You're right; I've added this to the current Zope 2.7 CVS.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] ./configure on Zope27HEAD with Python 2.2.2

2003-06-19 Thread Fred L. Drake, Jr.

Jamie Heilman writes:
   Does anyone care enough to fix configure to work properly on BSD?
  
  i=$(($i+1))

Whatever happened to the old tried-but-true:

i=`expr $i + 1`

Running an external process may be slower, but you don't need to run
./configure all that often unless you're developing Zope itself (and
even then, not all *that* often).  I suspect using expr is more
portable to the whole family of sh-derived shells than any of the more
new-fangled ways.

Sheesh, who ever imagined I'd be the curmudgeon?


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] ZConfig 1.0 release

2003-03-25 Thread Fred L. Drake, Jr.

I've just released ZConfig 1.0 for people who'd like to try it out
outside of Zope.  Chris McDonough will be presenting our paper on
ZConfig at PyCon DC on Thursday; be sure to catch it!

ZConfig is a configuration library intended for general use.  It
supports a hierarchical schema-driven configuration model that allows
a schema to specify data conversion routines written in Python.
ZConfig's model is very different from the model support by the
ConfigParser module found in Python's standard library, and is more
suitable to configuration-intensive applications.

ZConfig schema are written in an XML-based language and are able to
import schema components provided by Python packages.  Since
components are able to bind to conversion functions provided by Python
code in the package (or elsewhere), configuration objects can be
arbitrarily complex, with values that have been verified against
arbitrary constraints.  This makes it easy for applications to
separate configuration support from configuration loading even with
configuration data being defined and consumed by a wide range of
separate packages.

ZConfig is licensed under the Zope Public License, version 2.0.  See
the file LICENSE.txt in the distribution for the full license text.

Information on the latest released version of the ZConfig package is
available at

 http://www.zope.org/Members/fdrake/zconfig/

Reference documentation is available in the ZConfig/doc/ directory of
the distribution.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] ch-ch-ch-changes (post-merge fallout)

2003-03-20 Thread Fred L. Drake, Jr.

Jamie Heilman writes:
  I'm slowly fumbling my way through the massive changes of the latest
  branch merge... am I missing where the open databases (Globals.opened)
  get closed, or did that just get dropped entirely (and if so, how does
  that relate to the goals of the clean shutdown work)?

Hmm.  I hope that didn't get lost!  I'll look into this to be sure.

  Also, now that the hacked asyncore is no longer wedged into place in
  ZServer/__init__.py are there any known gotchas if one should import
  say, Zope and running Zope.startup() before importing ZServer?  Not
  that I plan on doing that mind you, but the side-effects that Zope 2
  suffers from in its various import dependancies drive me up a wall.
  It'd be cool if that one got fixed.

There's no longer a hacked version of asyncore, so that particular
constraint should no longer hold.  I agree that import order
dependencies are a significant source of obfuscation.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] New installer branch

2003-03-20 Thread Fred L. Drake, Jr.

Christian Theune writes:
  I'm reconfiguring my dev setup for the freshly merged new installer. My
  zope instances refuse to load the products from the Products directory
  but don't complain. Here my configured Pathes:

I think I see the problem; will see what I can do about this one.

Thanks!


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] New installer branch

2003-03-20 Thread Fred L. Drake, Jr.

Christian Theune writes:
  I'm reconfiguring my dev setup for the freshly merged new installer. My
  zope instances refuse to load the products from the Products directory
  but don't complain. Here my configured Pathes:

Fred L. Drake, Jr. writes:
  I think I see the problem; will see what I can do about this one.

I've committed a fix for this, but it does differ slightly from the
Zope 2.6 approach.  I think the new way matches the rest of the new
configuration philosophy much more effectively.

Instead of simply checking for INSTANCE_HOME/Products, the directories
used to define the Products package are listed in the configuration
file (the standard Products are included regardless).  The
INSTANCE_HOME/Products directory is included in the default
configuration file; it can actually be removed if desired.  The
configuration file can completely control the order in which the
directories are searched.

Please let me know if you have any difficulties with this approach.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Merging the new-install-branch

2003-03-18 Thread Fred L. Drake, Jr.

Chris Withers writes:
  Will I have to change the way Zope is built and/or the etsts are run?

Yes.

  If so, where could I find otu what they now need to look like?

There is a scenario for Linux in the newinstallbranch.xml in
Packages/TestScripts; I'll test it again before the merge takes
place.

I don't know about the Windows scenario, but it's probably OK for
now.  It may need to change in the future (I'll try to help as much as
possible; Tim just tried the new-install-branch tests on Windows and
we found one buglet there).  I won't be in front of a Windows box
myself until tonight.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: [Zope-Coders] Merging the new-install-branch

2003-03-18 Thread Fred L. Drake, Jr.

I wrote:
  I'll send a note to the zope-coders list before I actually start the
  merge.  For a description of the changes (and the ensuing discussion),
  refer to this thread:
  
  http://mail.zope.org/pipermail/zope-dev/2003-March/018999.html

The unit tests work on Windows for the branch at this point, so I
don't expect any real surprises there just yet.

I'm starting the mechanics of the merge into the trunk now; I'll send
another email when the merge is complete.

Anyone running an automated test of the Zope 2 trunk should review
this message to determine what impact this will have on the test
process:

http://mail.zope.org/pipermail/zope-coders/2003-March/003450.html


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: [Zope-Coders] Merging the new-install-branch

2003-03-18 Thread Fred L. Drake, Jr.

Fred L. Drake, Jr. writes:
  I'm starting the mechanics of the merge into the trunk now; I'll send
  another email when the merge is complete.

I'm done.  The new-install-branch is now dead.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Proposed installation changes for review

2003-03-18 Thread Fred L. Drake, Jr.

Adrian van den Dries writes:
  The 'make install' step creates files in the source tree.  It probably
  shouldn't do this, because if you want to do this as root (sudo make
  install to install under /usr/local, say), these file are created as
  root.  This is impolite more than anything else.
  
  The build and install targets just call setup.py, so is this a bug in
  the distutils?

This still essentially does an in place build, which is what the
previous Makefile did as well.  Offhand, I'm not sure how difficult it
would be to support both in-place and out-of-place builds; I may be
able to look into it tomorrow.

How important is it to support out-of-place builds?


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Proposed installation changes for review

2003-03-18 Thread Fred L. Drake, Jr.

Adrian van den Dries writes:
  On March 19, Fred L. Drake, Jr. wrote:
   How important is it to support out-of-place builds?
  
  http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration

Ok, I'm too tired to read that now; I'll look at it tomorrow between
meetings.

   configure; make; make install source package installation process
   and some form of INSTANCE_HOME installation thereafter.
   
   INSTANCE_HOME setup becomes the default kind of installation.
  
  Is this still current?

Can't say about the wiki offhand, but the quoted statement still
applies.  doc/INSTALL.txt has been updated; see the section Building
Zope for the relevant procedure.  (The Quick Start section uses an
abbreviated procedure that creates an instance home in the source
directory.)

Time for me to get some sleep.  ;-)


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Proposed installation changes for review

2003-03-10 Thread Fred L. Drake, Jr.

Adrian van den Dries writes:
  Debug mode needs to be broken out into directives for its real
  effects.  I always want Zope to run as a daemon, but I also want
  automatic PT/DTML reloading, and immediate tracebacks.  I think there
  should be a separate no-detach for those people who want that
  feature.

I'm happy with this (more so than the single option).  I think it's
fair for us to get this implemented before we're done; not sure if it
has to happen before the merge (I'm mostly tied up this week).

  The ZODB section doesn't work:
  
   Error: 'mount-point' is not a known key name

I think we haven't spend enough time figuring out the right way to
deal with DBTab-style mounts yet; leave out that key for now.  To see
the current spellings of the storage- and database-related
configuration values, take a look at the ZConfig schema component in
the ZODB package:  lib/python/ZODB/component.xml

  Also, it needs to support arbitrary storage types.  I don't know how
  ZConfig works internally, but I'm guessing each storage type would
  supply a ZConfig thingie that registers its configuration paramaters
  to ZConfig.  I'm hoping to roll out some large production Zopes with
  partitioned, distributed storages.

I'm not sure what you mean; it sounds like you're looking for either
DBTab-style mounts or something different.  Please describe the
configuration so we can be sure that there's some way to support it.

Thanks for your comments!


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: [Zope-dev] Proposed installation changes for review

2003-03-10 Thread Fred L. Drake, Jr.

Edward Muller writes:
  Actually I like the way z2.py detaches or doesn't detach. Perhaps a
  separate config option would be good to control this.

Detaching, or daemonizing, will be a separate configuration
parameter from everything else.  The basic mechanism will be that
provided by the zdctl.py/zdrun.py scripts in the zdaemon package.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: [Zope-CMF] i18n for CMF And Plone,backporting i18n to Zope 2.x

2002-07-01 Thread Fred L. Drake, Jr.


Barry A. Warsaw writes:
  concerns.  After talking with Fred, I came to understand that much of
  the code's current obscurity is due to optimizations to make TAL
  perform at least as fast as DTML.

Well, faster than it used to.  We need to spend time on performance.

  So while I'd love to have the code be cleaner and more pluggable, we
  have to decide 1) if we're willing to give up some performance to
  acheive this, and 2) if not, can you provide a design and
  implementation that will perform adequately?

It might be time to investigate Pyrex:

http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/


  -Fred

-- 
Fred L. Drake, Jr.  fdrake at acm.org
PythonLabs at Zope Corporation


___
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: [Zope3-dev] Are there Graphic Designers?

2002-04-05 Thread Fred L. Drake, Jr.


Jens Vagelpohl writes:
  mac OS X browsers:
  
  - IE 5.1
  - mozilla 0.99 (=1.0)
  
  i won't include OmniWeb because its CSS support is still flaky.

Whether a browser should be included depends on what portion of the
audience uses it, not how broken it may be.  I don't see it listed in
the stats you sent earlier, but I don't know if it spoofs itself to
get reasonable behavior from sites that require you to run the same
browser as the site designer.  (I know Opera spoofed itself as MSIE by
default at one point; since Opera 6 was in your stats, I presume that
version doesn't do that.)


  -Fred

-- 
Fred L. Drake, Jr.  fdrake at acm.org
PythonLabs at Zope Corporation


___
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: [Zope3-dev] Are there Graphic Designers?

2002-04-04 Thread Fred L. Drake, Jr.


Stephan Richter writes:
  I think we can safely rely on CSS. Common, Zope 3 is a new product, and if 
  someone needs to make it backward Browser-compatible, he can always 
  implement a less fancy CSS-free skin.

Argh!

I can hear Guido tell us about his Netscape 4 now...  There are still
a *lot* of people using that one and it's ilk.  Browsers at that level
know just enough CSS to make it painful.  ;-(  I've spent more time
making the Python docs work in NS4 than making them look good in more
modern browsers, and the more advanced efforts I've made can't go in
because the older browsers just don't come close!


  -Fred

-- 
Fred L. Drake, Jr.  fdrake at acm.org
PythonLabs at Zope Corporation


___
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: [Zope3-dev] Are there Graphic Designers?

2002-04-04 Thread Fred L. Drake, Jr.


William Trenker writes:
  Would you be comfortable with CSS Level 2?

My own thought is that we could use CSS 2 and as much of CSS 3 as we
can coax out of advanced browsers.  We should use the advanced CSS
features to avoid needing *Script, since that's evil and many users
turn it off due to security and privacy concerns.


  -Fred

-- 
Fred L. Drake, Jr.  fdrake at acm.org
PythonLabs at Zope Corporation


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