betabug... Sascha Welter

home english | home deutsch | Site Map | Sascha | Kontakt | Pro | Weblog | Wiki

Entries : Category [ zope ]
All around the Zope application server
[digital]  [language]  [life]  [security]  [media]  [zope]  [tourism]  [limnos]  [mac]  [athens]  [travel]  [montage]  [food]  [fire]  [zwiki]  [schnipsel]  [music]  [culture]  [shellfun]  [photography]  [hiking]  [pyramid]  [politics]  [bicycle]  [naxos]  [swim] 

26 June 2005

Plone: Getting NavTreePortlet to Display Always 2 Sublevels

Sitemap-Mode and getSiteMapDepth might be the answer?
 

Yes, another of those boring technical posts. Trying in Plone to display a NavTreePortlet with always the first and second level of the navigation tree shown. Plus the current page highlighted. Found a hackish solution, but it may not be 100% what other people need. Basically we are switching to "sitemap" mode, set the sitemap depth to 2, and patch NavTreePortlet to highlight the current page in sitemap mode too. Here it comes...


First step is to switch to "sitemap" mode. So customize "portlet_navtree_template" and change the first div with the tal:define of "data" as such:

<div class="portletContent odd" 
tal:define="data here/getSitemapData">
Now go to settings of the NavTreePortlet and change "Depth of sitemap" to "2" (or whatever you like). I believe this will not show sublevels below that, but I may be wrong, haven't actually tested.

This will change the display of the navigation tree a lot, but the downside is that the current item is not highlighted any more. (The current item gets another css class assigned, so by changing that in ploneCustom.css we can alter the appearance of the current item.) We need a fix in the actual code of the NavTreePortlet:

*** NavTreePortlet.py_orig      2005-06-26 08:52:49.000000000 +0200
--- NavTreePortlet.py   2005-06-26 08:48:23.000000000 +0200
***************
*** 54,59 ****
--- 54,61 ----
          if context == self or sitemap:
              currentPath = getToolByName(self, 'portal_url').getPortalPath()
              query['path'] = {'query':currentPath, 'depth':self.getSitemapDepth()}
+             # trying to fix detection of current item in sitemap mode
+             currentPath = '/'.join(context.getPhysicalPath())
          else:
              currentPath = '/'.join(context.getPhysicalPath())
              query['path'] = {'query':currentPath, 'navtree':1}
Apply this patch to NavTreePortlet.py in the INSTANCE_HOME/Products/NavTreePortlet directory with something like
patch -p0 < navtree_sitemap_highlight.patch
As usual this change is at your own risk and you better know what you are doing :-)

Posted by betabug at 09:24 | Comments (0) | Trackbacks (0)
06 July 2005

GZip compression on COREBlog entries

Smaller is beatyfull
 

In order to speed up download time and save some bandwidth I've now setup gzip compression for some of my weblog pages. I really hope this works for everyone. If you discover something that does not work, drop me a note. Setting this up in COREBlog was quite easy, all it needed was one line of dtml

<dtml-call "RESPONSE.enableHTTPCompression(REQUEST)">
to be added to the templates in question. The effect on some of the bigger "pages" is impressive: A big category page can go down from 140kB to 40kB. The page feels quite speedy too (client on ADSL, though I assume on a modem line the speedup will be even more noticeable).

On a sidenote: I have added a category "zope", in order to get the size of the category pages a bit down. I will later move some of the "digital" entries to this category. Last step will then be to set up batching ([previous page] / [next page] links) on category/month templates.


Posted by betabug at 12:48 | Comments (0) | Trackbacks (0)
15 July 2005

Zope Methods with a Dot in the name

Playing the game with setattr
 

Again one of those boring work problems: I have a bunch of Zope python / filesystem products. Most of them when instantiated contain an image called "preview.jpg". One of the little critters is different though. It wants to have a Zope Page Template (ZPT) instead of "preview.jpg". But Zope (and I think python) don't allow dots in method names. I banged my head on this particular wall for a while, until first Peter Bengtsson and then Chris McDonough gave me a big push on #zope. Read on for the solution...


What I have in the end is a class definition (in the .py file of my zope product, e.g. mythingy.py), like:

class mythingy( based_on_thingy_class ):
    """
    Pretends to have a preview.jpg
    """ 
    def __init__(self, id, title):
    ... and so on ...
    ... and so forth ...

    security.declareProtected( view, 'index_html' )
    index_html = PageTemplateFile(_www+'/thingy_index.zpt', \
        globals())

... and at the end of the file, ...
... outside the class definition, after the ...
... manage_add and manage_addForm methods, comes this:

setattr( \
    mythingy, \
    "preview.jpg", \
    PageTemplateFile(_www+'/zoom_index_html.zpt', globals()))
The magic part is the setattr, outside the class definition. This adds the attribute "preview.jpg" to the class. The attribute is the same for all instances of this class. That is fine with me, it's a ZPT, so it adjusts to whatever the instance has to show.

In the "setattr" line, the parameters might need some explaining (they needed for me :-). mythingy is the name of the class, naked without quotes. "preview.jpg" is the name that the "faked" method should be callable by, this one is a string, it has quotes around it. The last one (PageTemplateFile...) is the object that will be called. If I had a method called "gogo_method" on my class, I could as well have said:

setattr(mythingy, "preview.jpg", mythingy.gogo_method)
and the gogo_method would be called anytime someone requested preview.jpg. In my example above I could have done the same with mythingy.index_html to make it shorter.

Posted by betabug at 14:04 | Comments (0) | Trackbacks (0)
28 July 2005

Plone NavTreePortlet Sortorder Problem and Workaround

Objects "falling out" of the sort order
 

Having problems with objects not appearing in the right sort order in your Plone NavTreePortlet? I had that problem on a Plone 2.0.5 with LinguaPlone, which gives me the "new style" navigation portlet. Sometimes, especially after changing the id of an object, that object would just "fall down" to the end of the list, no matter where it was sorted in inside the folder_contents list. Read on for a workaround...


The same thing happened after we added and sorted in a lot of folders. They got out of order. It turns out, what happens is that the Catalog is getting messed up. So there is a workaround: When this happens, go into the ZMI, locate the root of your portal, open the "portal_catalog" object there. Hit the "Indexes" tab. Check the "getFolderOrder" and click on "Reindex". This takes only an instant. It rebuilds the index of the order that folders are in.

I think newer versions of Plone will have code to do this automatically after reordering operations. And if you dig deep enough you might discover this anyway. But still this workaround might be handy if you happen to mess with folder id's in the ZMI, and for other problems it might give you a hint where to look.

Posted by betabug at 15:12 | Comments (0) | Trackbacks (0)
14 August 2005

Show Subcategorized Patch

Make COREBlog Subcategorized Entries Show Up in Category Pages
 

Stephan Goeldi from zopehosting.ch brought to my attention that COREBlog entries that have been set at a subcategory are not showing up on the page for that category. Of course this is a matter of taste or expectations. But once you want e.g. to show on the page for "digital" an entry which has "digital" only as a subcategory, you have to dive into the code. I did and produced a short patch. BTW: This all happened in July, but due to much work and then this vacation, now is that I get around to publish this...


The patch is working on my own machine and has been tested by Stephan Goeldi, it seems to work for him too. Even then, procede with caution, use at your own risk etc. The patch essentially changes just one line. The original code checks if there are any categories set (for safety I guess, since I believe this should not happen under normal conditions) and then lists only entries which have the category in question as the first entry of the list. The changed code keeps the check, then lists entries which have the category in question anywhere in the list. Trivial really. Here is the patch:

*** COREBlog.py Wed Jul  6 15:19:04 2005
--- COREBlog.py_backup  Wed Jul  6 15:09:56 2005
***************
*** 913,919 ****
                  break
              id = self.entry_list[c]
              obj = self.getEntry(id)
!             if obj.category and int_cat in obj.category:
                  if not consider_moderation or obj.moderated:
                      l.append(obj)
          return l
--- 913,919 ----
                  break
              id = self.entry_list[c]
              obj = self.getEntry(id)
!             if obj.category and obj.category[0] == int_cat:
                  if not consider_moderation or obj.moderated:
                      l.append(obj)
          return l
Apply as usual with patch -p0 < coreblog_subcategory.patch.

There is only one problem with this code: The numbers behind the category display are off now. The count only the entries with that category as "main category". This could of course be corrected too. And in the end all this maybe should become an option in the administration interface, "list subcategorized entries too".

Posted by betabug at 20:14 | Comments (1) | Trackbacks (0)
09 September 2005

HTML and CSS (and Zope) job offer

We're hiring, I'm looking for help
 

We're looking for someone to help me with application development. Mainly it's HTML (handcrafted, please!), CSS2 and some Zope integration. So if you are looking for a job and either live in Athens, Greece or would be interested to move here, contact me! Read on for some observations on my candidate search...


I'm also browsing through online biographies on a job site here. It's rather numbing. These documents come out of some web form and they all look a bit alike. It's hard to stand out, so if you ever fill out a form like that I suggest using the comment box to give your CV some life. Those are the ones I can have my eyes rest on.

A lot of the information on these CVs comes out of checkbox farm fields. People tick on all the buzzwords they have a knowledge about. There is no distinction about the level of knowledge. So is someone who checked "HTML" aware that there is this funny code running behind Adobe GoDeath, or do they really know how to handcraft proper HTML and maybe mix in some Zope ZPT stuff?

Then there is the M$ sickness abound. OK, the business world seems to use the stuff. So if you want to get hired you may want to check all kind of Windozes, be it 95/98/ME/2000/XP whatever... but do you really think you should put a checkmark on X-Windows too? (Since nothing UNIXish is listed, I assume you really wanted to check "UNIX-clueless" :-)

Update: I just posted this on the Zope mailinglist:

Hello Zope-World!                                                               
                                                                                
We have a job offer for someone with good experience on handcrafted HTML        
and CSS, working on Zope projects. Knowledge of Zope can be acquired on         
the job, but we want good HTML/CSS that can be mixed in with ZPT.               
                                                                                
This is not a job for someone with years of knowledge of Zope already.          
But if you know a bit of Zope or are interested to learn about it and           
have the mentioned HTML/CSS background and a rough idea what building a         
web application is, then this may be for you.                                   
                                                                                
The job is in Athens, Greece. Yes, that's where the sun is shining and          
the sea is only a short ride away. You can take weekend trips to islands        
other people see only on postcards. And we get to eat fresh fish on             
business lunches :-) Telecommuting to other countries is *not* available        
for this position, as you would get cheated out of the fresh fish.              
                                                                                
We are a small to medium advertising company, with a robust business            
background. We are developing tools for providing more benefits and             
improving communication with our clients. Right now it's me as a Zope           
dev, next month we will have another Zope newby starting, and then we           
want you.                                                                       
                                                                                
If you are in Greece, this is obviously for your. If you are outside            
Greece (in EU), please note that Greece is not a high salary country,           
but a country with high quality of life. It might be interesting for you        
if you are the adventurous type. Speaking Greek would be nice, but we           
also do business in English.                                                    
                                                                                
Please send your CV to me, not to the list! :-)

Update: We found someone, job offer closed!

Posted by betabug at 13:42 | Comments (2) | Trackbacks (0)
19 September 2005

Introducing the RewriteRule Witch

Get those pesky Apache RewriteRules for Zope VHM right
 

Are you fluent with Apaches RewriteRules for Zope virtual hosting with VirtualHostMonster? Do you have to dig that stuff out of the documentation each time you use it? Save a little bit of guesswork with a spell from the "Rewrite Rule Witch"...

Virtual hosting with Zope usually involves setting up Apache "in front" of Zope, putting a Virtual Host Monster into your Zope Root and configuring some RewriteRules in your httpd.conf. Since I don't do this every day (like most zopistas, I guess), every time I have to dig up my knowledge of rewrite rules again from almost scratch. Now I wrote a little script to help me with the most frequent cases of those RewriteRules. You can try out the Rewrite Rule Witch online.

Still testing!

Please note that there might still be bugs and mistakes in there. I'm happy to receive feedback about this thing. Especially interesting would be to try out some of the configurations you have and see if the result is what you actually use. I cover only the most basic variants, but likely the ones used for 95% of Zope setups. I do not yet cover rewriting "/manage" URLs to https (next project!)


Posted by betabug at 15:29 | Comments (2) | Trackbacks (0)
27 September 2005

Introduction to some Zope security settings

How to declare Roles and Permissions to your Zope Product
 

Say you have made your own disk based python product in Zope. Now we want to secure some of your methods. We have two classes of users, let's call them "Client" and "Supervisor". We have two sample methods, which we want to secure for who is allowed to view them. Let's call these methods "display_sprockets" and "display_sprocket_orders". Obviously mere Clients can't be allowed to see orders, only Supervisors should. We could click our way through ZMI, but we want this to be as smooth as possible when installing our product. So let's look at a sample setup...


Prepare security declarations

For the setup we decide to build our product with a container object that contains our sprocket information, sales, adminstration, and ordering logic. It contains sprocket subobjects, order database connections and a host of other boring stuff. We are not interested in them right now. Actually we are not interested in them at all, we just want to lock down our sample methods. In our container object (class, product, whatever you care to call it), we prepare to set up the security declarations as we have learned in the Zope Developer Guide:

class sprocketcenter( ObjectManager, PropertyManager, SimpleItem ):
    ... lots of stuff omitted ...
    
    security=ClassSecurityInfo()

Automatically setup roles

Our two classes of users correspond in Zope parlance to "roles". We will in the working application define our users with their user names and assign them one of those "roles". Now, usually we can go into the Zope Management Interface (ZMI) and assign new "local roles" to any object that behaves like a folder. That is nice and dandy as long as it should be done just once. If there is any chance that we will re-use our product, we should automate that setup. Next time you will have to migrate to a new machine, or need a test setup, you will be thankfull. We will add this snippet of code to add new roles:

localroles = ['Client','Supervisor']
for role in localroles:
    if role not in container.valid_roles():
        self._addRole(role)
Where do we have this code? It can either go into a method called "manage_afterAdd(self, item, container)", in which case you can leave those variables in the code snipped as is. (manage_afterAdd is a special name for a method that will be called right after a new instance of your product is added to the Zope database. It's a hook.) Or else you could work it into your constructor method (maybe called something like "manage_add_sprocketcenter"), in which case you will have to juggle "self" and "container" around to fit. What have we done there? We assigned new roles to the "container", which is the folder surrounding our products new instance. We checked that these roles are not already there.

Decide on Permissions

Next thing is, we have to decide on some "Permissions". What we call "Permissions" in Zope, is a name to bundle the rights for something. We then use this Permission to make a link from a group of users (that's users who have the same "role") to a group of methods (who are declared to be accessible with this Permission).

One permission already there is the "View" permission, or the "Change Images and Files" permission. Obviously you can set up some "role" of users to only view stuff, while others can change stuff. But it get's more fine grained. For example the blog product "COREBlog" has permissions for "Add COREBlog Entries", "Moderate COREBlog Entries" and "Manage COREBlog". Obviously this allows for more control of who is allowed to do what. The programmer assigns these permissions to a bunch of methods and in this way she controls who is allowed to do what.

It is good practice to re-use existing permissions wherever they fit, but to invent your own if it makes sense. In our example we will use "View" as a readymade and "Approve Sprocket Orders" as our own custom permission.

Assign permissions to methods

Permissions are assigned to methods. This is usually done right above the "def methodname" line in our class code:

security.declareProtected( 'View', 'display_sprockets' )
def display_sprockets( self, REQUEST ):
    ... more stuff omitted ...

security.declareProtected( 'Approve Sprocket Orders', \
                                'display_sprocket_orders' )
def display_sprocket_orders( self, REQUEST ):
    ... lots of stuff omitted ...
The arguments to declareProtected are the permission name and the name of the method (both as strings). Another option for a permission setting is security.declarePrivate( '_internal_sprocket_calculator' ). This declares that this method is not allowed to be called through the web, for anyone. On the other hand, our declareProtected declaration allows anyone to call this method in their web browser, as long as they belong to a role who has the proper Permission.

Automatically assign Permissions to our Roles

What we are still missing is the link from Permission to Roles. If we do our product with the code as we have it now, nobody will be allowed to do anything but "View". Why? Because "View" is predefined, while our "Approve Sprocket Orders" is a new permission and no role has this Permission yet. We cold go into the ZMI, click on the "Security" tab and assign our "Supervisor" role this new Permission. But again, we want to have this ready for new installations. So we add some more code, in this case in our manage_add_sprocketcenter method, where we set up various stuff of our sprocket center product. (It could of course go into other places too, your choice.)

# ... we assign the newly created object into my_instance ... then:
my_instance.manage_permission\
    ("View",('Client','Supervisor','Manager'), acquire=0)
my_instance.manage_permission\
    ("Approve Sprocket Orders",('Supervisor','Manager'), acquire=0)
In both cases, with "acquire=0", we make sure that no permissions are acquired from folders "above" our own. This is just to make sure that settings outside our application do not affect our security settings. It may not be desirable in all cases. In any case we also helped "Manager" to these permissions, that's the guy who works in the ZMI, usually the Developer... you! So good idea to give you that Permission too or you would not be able to work with the stuff.

So I hope this little overview has been usefull. I had the idea to put this down after answering some questions on IRC. The idea is that this might work as an introduction for you and as a reminder for you and me :-). Be sure to read the Zope Developer Guide and the Zope book to get the complete image.

Posted by betabug at 11:15 | Comments (0) | Trackbacks (0)
06 October 2005

Thinking about the Zope Witch's Future

Extend and expand!
 

There was not that much feedback on the Zope witch (a RewriteRule generator) yet, but what I got so far was positive. This morning on freenode's #zope, TinoW suggested including the witch into the Zope distribution, possibly as part of the Virtual Host Monster (VHM) or its help system. I had already been thinking about this, and about some other expandation plans. Desired endresult? Why, world domination of course, read on...


There would be some advantages to the witch being integrated into the Virtual Host Monster:

I don't think it would be a good idea to try to mess with the Apache httpd.conf file directly, that gets incredible messy with permission and file locations. What would have to be definitely worked upon is the witches user interface. The interface would have to be more in line with the Zope admin interface style. Downside to all this? I would have to work on it (and I'm as busy as everyone else). And then I actually like to provide the service on my own humble site :-).

What is definitely on the roadmap is redirecting of access to the manage interface. The witch should offer a second spell interface to generate rules like those (which redirect all acces to URLs with "manage" in them to the https secure server):

RewriteRule \
^/(.*)/manage(.*) \
https://%{SERVER_NAME}/$1/manage$2 [R=301,L]
RewriteRule \

^/manage(.*) \
https://%{SERVER_NAME}/manage$1 [R=301,L]
The hardest part in writing the witch was getting the UI (user interface) to become halfway understandable. The same would be true for this second spell generator: What options make sense, what is there to customize? For example I do use these simple rules for my ZMI access, but on other installations I have similar rules to other applications which are only to be accessed over SSL. Sometimes the redirecting should only happen on an exact URL start, other times (as with manage) we trigger on any part of the URL. More thought work.

Posted by betabug at 10:28 | Comments (0) | Trackbacks (0)
10 October 2005

Found Someone for the HTML/CSS Job

Welcome Andreas to the world of Zope!
 

As mentioned in HTML and CSS (and Zope) job offer, we were looking to hire someone with HTML/CSS skills. After a long, long search we finally got Andreas at the office. He is full of interest and drive to get going, he is very interested in Open Source, so he'll probably get along fine with Zope. On the other side he uses Emacs... but maybe we'll teach him to use vi anyway :-) But what this means now: Job offer closed!


Posted by betabug at 12:16 | Comments (0) | Trackbacks (0)
17 October 2005

IE Bug Bitten

Internet Explorer Cannot Save to Cache error

We had been bitten by another IE bug here with the application we're building. Our customers using IE6 got a message "Internet Explorer can not save to cache", whenever they tried to save an image. Our application is working over https and puts out "Cache-Control: No Cache" headers. These are some ingredients that trigger the "cannot save to cache" bug in lame Internet Explorer 6. After suspecting my own code for a while and changing stuff around to check, I STFW (searched the f* web) and came up with that M$ support page. In case it goes away, here is the info in short:


Workaround for Zope: I added a line to my python script...

REQUEST.response.setHeader('Cache-Control','keepitifyoulike')

this just overrides the header for this one method. It's not perfect, but it works for now.

Posted by betabug at 10:13 | Comments (0) | Trackbacks (1)
25 October 2005

Making COREBlog Comment Moderation Admin Friendlier

Save a step each day
 

Keeping SPAM out of weblog comments is a big priority these days. I set up COREBlog to require comment moderation and to notify me by mail of new comments. So when one of those mails arrive I have to log in and click to get it going. I just made that go faster.

Since I'm not logged into the admin interface all time and since comments sometimes come in on old posts, navigating to the right comment is sometimes a bit of a drag. But the URL that gets me to the comment moderation page in question derives straight from the ID of the commented post, so instead of this line from the COREBlog notification howto...

EntryID  :%s

I now use this...
EntryID / Moderate :
https://www.betabug.ch/zope/ch-athens/%s/manage_comments
...and now I can copy&paste the URL to go straight to moderate the comment. It gets expanded right to the proper URL.

Not that too many comments are comming in, but maybe you (yes you!) have something witty to comment to one of the weblog entries (hint, hint!).


Posted by betabug at 11:20 | Comments (0) | Trackbacks (1)
01 November 2005

Zope Witch Experiences

Rewriting URLs for fun and Apache
 

The witch (a RewriteRule generator for running Zope behind Apache) has been around for more than a month now on my site. Enough time to sum up some of my experiences, which are quite good. Problems could be mostly solved by properly copy and pasting the output into httpd.conf. Overall it is a good service that seems to be silently appreciated...


The witch is now more than a month on my site, it has proven to be found by people. Visitors for the witch come from Google (where the witch is now on the first page for "rewriterule generator"), from the ZopeWiki and from some links on mailing list archives and other pages. An interesting experience for me, especially watching as the witch climbed the Google ladder.

From the logs I can see that a lot of those visitors only look at the page, without trying out the form. Possibly the witch is not what they looked for (since it is Zope specific; a more generic RewriteRule generator is on the first place of the Google results, and rightly so). But a POST request here and there in the logs shows me that the witch is taken to good use too.

One of the reasons for creating the witch were the questions about setting up Apache in front of Zope on irc (#zope on freenode). I can't prove anything statistically, but I have the gut feeling that these questions have dwindled a bit. And even when people ask about RewriteRules, I can refer them to the witch, which answered the questions a couple of times already.

Possible problems

Some problems were encountered with the witch. For a developer there is always a risk of downplaying problems, so I was on my toes whenever I heard of "does not work for me" on IRC. As far as I can tell, all the problems I had been shown on IRC could be solved. Most of the problems could be traced back to not properly copy/pasting the RewriteRules:

Maybe (likely?) I haven't heard from some people who had problems. The witch after all helps just with one little aspect of the Apache/Zope setup, even though it's one of the more obscure aspects. So if you had any trouble or know of someone who had trouble, I would be pleased to hear from you and how you might have solved the problem.

Feedback

One expectation about the witch was not fulfilled. I was a bit afraid that I would be mailbombed with questions about Zope/Apache setup problems. But that kind of feedback has been totally absent. The positive feedback was slightly better, but still only barely visible. All in all providing such a service on my site has been a good experience.

Posted by betabug at 21:48 | Comments (0) | Trackbacks (0)
21 November 2005

Wiedermal Unit Tests, diesmal in Zope

Geht doch alles viel schneller
 

Ich bin ein grosser Fan von Unit Tests. Ich schäme mich fast es zuzugeben, aber ich habe Unit Tests in meinen Zope-Projekten viel zu lange rausgeschoben. Der Grund war wie so oft, dass ich glaubte, dafür keine Zeit zu haben. Letzte Woche habe ich es dann nicht mehr rausgeschoben. Und siehe da, wiedermal entdeckt, dass ich mit Unit Tests eigentlich viel schneller arbeite. Tja...


Abgesehen von irgendwelchen Super-Software-Philosophien, die mich nicht interessieren, mag ich Unit Tests aus folgenden Gründen:

Was mich in Zope noch gebremst hat zum Thema Unit Tests war die Verwirrung wie's denn nun "offiziell" gemacht wird. Schlussendlich habe ich mich an ZopeTestCase (Wiki Dokumentation) gehalten, was bei Zope 2.7 als Extra installiert wird, bei Zope 2.8 als Standard drin ist. Für Zope 3 gibt es dann noch was anderes, aber das ist bei mir noch nicht angesagt.

Ein weiterer Hinweis: Die Methoden mit denen getestet wird (assertEqual(dies, das) usw.) sind in der python Dokumentation aufgelistet unter TestCase Objects.

ZopeTestCase ist doch schon einiges angenehmer als die selbstgestrickte Testumgebung, die ich mal bei einem PC-basierten Programmierjob gemacht habe, um nicht den Verstand zu verlieren.

Posted by betabug at 17:54 | Comments (0) | Trackbacks (0)
24 November 2005

VirtualHost mess

Site was off for a while

Since I set up another virtual host today, I managed to mess up the virtual host setup in my httpd.conf. It took me some time to find out. So if you came here and got some funny error about "page zope not found", I'm sorry :-) Things should be up and running again. If you are interested to know what happened: I forgot to activate the NameVirtualHost directive. And when I had it set up, the wrong VirtualHost was used as default.


Posted by betabug at 17:23 | Comments (0) | Trackbacks (0)
19 December 2005

Resetting RAM Cache Manager on COREBlog entry edits

Just a little bit more friendly tweaking
 

As seen in previous posts (Experiments with RAM cache and RAMcache for COREBlog update), I'm using a RAMCacheManager in Zope to speed up the weblog loading and to ease load on the server. So far the downside has been that after editing a post I had to manually reset the cache. This would even be the case when I would preview a post multiple times before adding it. Not the best solution and definitely an itch that needed scratching...


The solution is to invalidate the RAM cache on edits. That is done in the manage_editEntry method of the Entry class. I'm cacheing the entry_body dtml method, so I have to reset the cache for that one. On the positive side this works and is much easier for me, editing existing posts and previewing behaves now just as if my COREBlog wasn't cached. The downside is that there could be unneeded cache resets, as I always reset. Also the resetting happens for all posts, not just for this entry. Anyway, here is the patch:

--- Entry.py_orig       Mon Dec 19 14:18:54 2005
+++ Entry.py    Mon Dec 19 14:39:18 2005
@@ -267,6 +267,9 @@
         if not title:
             kw['worning_message'] = "Title is required."

+       # invalidate the cache if this entry is cached:
+       self.entry_body.ZCacheable_invalidate()
+
         if REQUEST:
             if sendnow and addedtbs:
                 #send trackback

Posted by betabug at 14:58 | Comments (0) | Trackbacks (0)
Prev  1   [2]   3   4   5   6   7   8   Next