Re: [Nevow-commits] Replace ID generator values with IDs based on context.key. Group

On Feb 29, 2004, at 6:19 PM, mg CVS wrote:
> +def keyToXMLID(key):
> +    """Convert a key into an XML-style ID """
> +    if not key:
> +        print 'keyToXMLID: no key, but why?'
> +        return None
> +    return '-'.join(key.split('.'))

Did you run into a specific problem forcing the translation of . to -? 
The HTML spec says:
- ID and NAME tokens must begin with a letter ([A-Za-z]) and may be 
followed by any number of letters, digits ([0-9]), hyphens ("-"), 
underscores ("_"), colons (":"), and periods (".").

The XHTML spec seems to be even more open, allowing many many 
characters to be used in names. It says you should only use names 
matching [A-Za-z][A-Za-z0-9:_.-]* if you want to be compatible with 
HTML4.

James

Re: Re: [Nevow-commits] Replace ID generator values with IDs based on context.key. Group

On Tue, 2004-03-02 at 01:13, James Y Knight wrote:
> On Feb 29, 2004, at 6:19 PM, mg CVS wrote:
> > +def keyToXMLID(key):
> > +    """Convert a key into an XML-style ID """
> > +    if not key:
> > +        print 'keyToXMLID: no key, but why?'
> > +        return None
> > +    return '-'.join(key.split('.'))
> 
> Did you run into a specific problem forcing the translation of . to -? 
> The HTML spec says:
> - ID and NAME tokens must begin with a letter ([A-Za-z]) and may be 
> followed by any number of letters, digits ([0-9]), hyphens ("-"), 
> underscores ("_"), colons (":"), and periods (".").
> 
> The XHTML spec seems to be even more open, allowing many many 
> characters to be used in names. It says you should only use names 
> matching [A-Za-z][A-Za-z0-9:_.-]* if you want to be compatible with 
> HTML4.

Not a specific problem as such. I replaced '.' with '-' to make the
elements selectable by ID in the CSS, as well as useful within the
document itself. JavaScript should also have no trouble getting a
reference to the elements using either the DOM or form.elements[] API.

Is this ok, can you think of any problems with doing this?

Cheers, Matt

--

-- 

LiveEvil output buffer patch

Will someone please apply the attached patch to liveevil?  It adds an
output buffer.  The only additional thing that is needed is for the
LiveEvil.output to be reset to None after every request.  I'm
accomplishing this in my own code currently by doing setting mind.output
= None.

I would like this code to be added now though, as it takes steps in the
right direction until we find the best place to put the code to reset the
output.

Comments?

-Justin

Index: liveevil.py
===================================================================
RCS file: /cvs/Nevow/nevow/liveevil.py,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 liveevil.py
--- liveevil.py 19 Feb 2004 06:43:17 -0000      1.1.1.1
+++ liveevil.py 4 Mar 2004 19:08:58 -0000
 <at>  <at>  -38,11 +38,16  <at>  <at> 
         # TODO set up an event hub
         self.events = events.EventNotification()
         self.hookupNotifications = []
+        self.outputBuffer = []

     def hookupOutput(self, output, finisher = None):
         #print "output hooked up."

Re: LiveEvil output buffer patch

After discussing this on twisted.web, I've created a new patch that adds
all necessary code to get buffering working.  Patch is attached.

On Thu, 04 Mar 2004 13:13:25 -0600, "Justin Johnson"
<justinjohnson <at> fastmail.fm> said:
> Will someone please apply the attached patch to liveevil?  It adds an
> output buffer.  The only additional thing that is needed is for the
> LiveEvil.output to be reset to None after every request.  I'm
> accomplishing this in my own code currently by doing setting mind.output
> = None.
> 
> I would like this code to be added now though, as it takes steps in the
> right direction until we find the best place to put the code to reset the
> output.
> 
> Comments?
> 
> -Justin

Index: liveevil.py
===================================================================
RCS file: /cvs/Nevow/nevow/liveevil.py,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 liveevil.py
--- liveevil.py 19 Feb 2004 06:43:17 -0000      1.1.1.1
+++ liveevil.py 4 Mar 2004 20:44:29 -0000
 <at>  <at>  -4,6 +4,7  <at>  <at> 

 from twisted.internet import reactor

Subject: new nevow know-how needs...

Hi all -- I'm rather IRC-allergic, don't particularly love mailing lists,
but apparently gmane should let me access this mlist via my newsreader
(much, much better from my POV), so, let's see.

With Rikard Anglerud, and help from Anders Hammarquist (aka Iko), we're
developing a few web applications, and eventually a new framework for web
applications, with/for AB Strakt's "CAPS" (see www.strakt.com), and we're
basing our work entirely on nevow and other parts of twisted (CAPS already
uses twisted for all communication among its layers, so the new approach
already works much more smoothly than our "previous generation" web-apps
based on Webware, IMHO).  Over the last few days we moved our stuff from
nevow's previous generation (the one that's part of quotient) to nevow's
new, stand-alone incarnation.  The amount of incompatible changes was
staggering (serves us right for working with a new, hotly-developing
framework, of course, but they do seem to be for the better, and we do
have everything working again now (and having nevow as a stand-alone
package does make the task of packaging it up with the rest of what CAPS
needs _way_ easier, of course).

I currently have _one_ serious problem understanding what's going on (or
supposed to go on): nevow:data="whatever" directives.  I don't understand
the rules regarding WHEN this causes a lookup (e.g. of 'data_whatever' on a
rend.Page subclass), WHAT it looks things up when it does do a lookup,
WHEN it calls method 'data_whatever' thereafter, and with what arguments.
Basically, I must be missing something important here -- it mostly feels
that once I've used a nevow:data= directive, I lose control of what's going
to happen and get nasty surprises.  So, I'm gradually moving to using
nevow.render= directives instead -- mixing the "model" aspect (getting the
data on which rendering is to be based) with the "view" one (rendering it).
Not nice, but with nevow.render I _do_ appear to have complete control, or

Basic authentication in twisted.web

I need basic authentication in twisted.web for an XMLRPC server.

After reading the mailing list, the documentation and the code, 
I came up with the following solution.

Since I'm rather new to twisted web, it would be nice if someone could comment on this code. 
Perhaps it is helpful as an example for others solving the same problem or trying to understand twisted.web
and twisted.cred.

Short usage instruction:

Save the code to basicauth.py
Start the server: twistd -noy basicauth.py
http://localhost:8080/ will show the file "basicauth.py" after authenticating with user "bob" and
password "123"

By the way, twisted is fantastic.

Franz-Josef Grosch
--
Tenovis Comergo - Applications

WebDAV for Twisted

Hi all,

since some people were interested in using WebDAV together with Twisted 
recently, I decided to send you my current work on this.
I essentially used the "pydav" implementation:

http://www.comlounge.net/webdav/

and wrote a twisted extension. Once you are familar with "pydav", the 
twisted extension is self-explaning. I hope, the short README.txt will 
help you. By the way, I tested this implementation  together with the 
Windows Explorer and cadaver, a command line WebDAV client.

In my opinion, it would be very useful to integrate WebDAV support in 
Twisted.
Well,  since I have never contributed code to twisted, I do not know, 
how to do this.

regards,

Thorsten

--

-- 
brainbot technologies AG 
boppstrasse . 64 . 55118 mainz . germany
fon +49 6131 211639-1 . fax +49 6131 211639-2
http://brainbot.com/  mailto:henni <at> brainbot.com

Subject: Re: new nevow know-how needs...

On Mar 1, 2004, at 6:02 AM, Alex Martelli wrote:
> I currently have _one_ serious problem understanding what's going on 
> (or
> supposed to go on): nevow:data="whatever" directives.  I don't 
> understand
> the rules regarding WHEN this causes a lookup (e.g. of 'data_whatever' 
> on a
> rend.Page subclass), WHAT it looks things up when it does do a lookup,
> WHEN it calls method 'data_whatever' thereafter, and with what 
> arguments.
> Basically, I must be missing something important here -- it mostly 
> feels
> that once I've used a nevow:data= directive, I lose control of what's 
> going
> to happen and get nasty surprises.  So, I'm gradually moving to using
> nevow.render= directives instead -- mixing the "model" aspect (getting 
> the
> data on which rendering is to be based) with the "view" one (rendering 
> it).
> Not nice, but with nevow.render I _do_ appear to have complete 
> control, or
> maybe better expressed, _understanding_, of what's gonna happen...

I just totally changed how this worked today. I'll describe what *now* 
happens, which is different from what used to happen:

def data_foo(context, data):
   return 4
def render_foo(context, data):
   return context.tag['Hi: '+data]

Subject: Re: new nevow know-how needs...

James Y Knight wrote:
   ...
> I just totally changed how this worked today. I'll describe what *now*
> happens, which is different from what used to happen:
> 
> def data_foo(context, data):
>    return 4
> def render_foo(context, data):
>    return context.tag['Hi: '+data]
> span(data=data_foo, renderer=render_foo)
> 
> This will first call data_foo, returning '4'. data_foo's context will
> be the context of the span (context.tag is the span tag), without its
> IData remembered yet (thus, the data argument will be whatever the
> containing data is, in most cases, the rend.Page instance.
> 
> Then, render_foo will be called, with the tag's context, again, but now
> with the result of data_foo's result (4) as 'data'.
> Thus, this will result in the string "<span>Hi: 4</span>".

Wonderful!  This new behavior, as you describe it, perfectly matches my
intuition about "what _should_ happen".

> Now, take another example:
> number = 0
> def data_count(context, data):
>    global number
>    number = number + 1
>    return number
> 

Subject: Re: Re: new nevow know-how needs...

On Mar 5, 2004, at 6:15 AM, Alex Martelli wrote:
> So, won't every
> HTML construct coming from a template of some form such as:
>
> <span nevow:data="bar">
>     etc, etc
> </span>
>
> end up "compiled" into a "span(data=directive('bar'))[etc, etc]" 
> anyway,
> leading me right back into subtle issues of "WHERE is this 'bar'
> going to be looked up, depending on phase of the moon etc"...?  Or are
> there two different ways I should code that '<span nevow:data="bar">' 
> in
> the on-disk template depending on whether I mean one thing or the 
> other?

Welll, it doesn't depend on the phase of the moon. directives always 
get looked up on the first data it finds above it in the tree. I'm not 
sure exactly what your question is, but, is it the lack of being able 
to go back up the tree? e.g.:
class MyPage:
   def data_foo(context, data):
     return {'bar':2, 'baz':3}
   def data_other(context, data):
     return 1
   docFactory = xmlstr("""
   <html>
     <span data="foo">
       <span data="bar" render="string">This works fine.</span>