[Framework-Team] Re: Is this thing on?
whit wrote: hey, if the werewolf wants to be on the framework team I say more the merrier ;) +1 for having Martijn Faassen in the framework team. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: r15422 - in plone.transforms/trunk/plone/transforms: . interfaces tests
Hi Hanno! hannosch wrote: Added: plone.transforms/trunk/plone/transforms/interfaces/transform.py == --- (empty file) +++ plone.transforms/trunk/plone/transforms/interfaces/transform.py Wed Jun 20 21:18:48 2007 @@ -0,0 +1,22 @@ +from zope.interface import Attribute, Interface + + +class ITransform(Interface): +A transformation utility. + + +inputs = Attribute(List of mimetypes this transform accepts + as inputs.) + +output = Attribute(Output mimetype) + + +title = Attribute(The title of the transform.) + +description = Attribute(A description of the transform.) + +def convert(data, **kwargs): + +The convert method takes some data in one of the input formats and +returns it in the output format. + Let me try and get a discussion started around this interface. The 'convert' method doesn't say anything about what 'data' is supposed to be. I think it's a good idea to require 'data' to be a file-like object from the start -- the same should go for the return value. Also, I can't say I like the **kwargs. Would you mind describing what that's for? Generally, I think it's a good idea to make the interface specification as unambiguous as possible. By saying 'some data' and not specifying what the keyword arguments are, I think we run into the danger of coupling clients with the transforms at a lower level than the interface. Thus we lose real pluggability, because there's no exact specification and everyone can have their own interpretation of 'data' and 'kwargs'. Daniel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
Alexander Limi wrote: On Fri, 23 Mar 2007 05:00:45 -0700, Daniel Nouri wrote: Do you want to tell (core) add-on developers to not make use of the niceties of plone.app.controlpanel because their thing is too complex? Uhm, if people can't use zope.formlib anywhere else than in plone.app.controlpanel, then this is a totally different problem. Let me turn it on its head: Do you want developers to expose every single setting in the Plone control panels because it's easier than doing it in other locations? Now, *that's* wrong, if you ask me. :) Frankly, I think that requiring people to learn another way to add TTW configuration makes the contribution story harder. I certainly don't want to be the one adding and maintaining that ZMI / formlib layer. Not sure, maybe it's there already. If you really think that advanced is too much to ask of the users, and that they're still going to go in there to shoot themselves in the foot, let's make a hidden Plone page where all these forbidden configuration options are. I know that the difference between ZMI and Plone configuration has traditionally been: If you need to do more than that, go to the ZMI, even if more by accident than by anything else. I don't see why we should cling to this distinction. Regards, Daniel -- http://danielnouri.org ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
Hi! Alexander Limi wrote: - Archetypes - After we removed JS from checkboxes, they no longer stick (really!). Might have to put that back, even though it sucks - There's something strange going on with enabling comments, it only works on the initial view of the page after saving, possibly related Who removed JS from checkboxes when? - Can the old-style Add-on products support TITLE.txt to match the new style products' ability to have a friendly name? What does this mean? - Preferrably move the Collections (Smart Folder) control panel to a ZMI version, since it is very complex and not something site admins are likely to need I'd suggest an advanced section in the control panel. I don't like the idea of moving this back to the ZMI because it's too complex for the typical user. Do you want to tell (core) add-on developers to not make use of the niceties of plone.app.controlpanel because their thing is too complex? Daniel -- http://danielnouri.org ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)
Hanno Schlichting wrote: Nope. Windows support for zopectl is a lot harder then just some path fiddling. But the real issue with it is not really something that is an argument for ploneout, I just took the time to implement it in it, it could be a separate package as well. The basic problem with it is, that it relies on Unix-specific thread handling for the start/stop/restart/debug/status options, but it calls the internal status command at every start of the script, so on Windows it fails before you can do anything with it. I adjusted the internal status handling, so it doesn't look for the Unix specific stuff but should look if a Windows service of the instance is installed and running. Ideally this could move into Zope itself. I have seen that somebody implemented something alike for instancemanager... I looked at the Zope 2 recipe briefly and thought it only fiddlest with PYTHONPATH in bin/runzope.bat. I don't really understand the other issue with Unix specific threading that you mention. First off, I think ploneenv would need to modify the runzope.bat script so that it calls the activate script before startup. Daniel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)
Hanno Schlichting wrote: Daniel Nouri wrote: Hanno Schlichting wrote: Nope. Windows support for zopectl is a lot harder then just some path fiddling. But the real issue with it is not really something that is an argument for ploneout, I just took the time to implement it in it, it could be a separate package as well. The basic problem with it is, that it relies on Unix-specific thread handling for the start/stop/restart/debug/status options, but it calls the internal status command at every start of the script, so on Windows it fails before you can do anything with it. I adjusted the internal status handling, so it doesn't look for the Unix specific stuff but should look if a Windows service of the instance is installed and running. Ideally this could move into Zope itself. I have seen that somebody implemented something alike for instancemanager... I looked at the Zope 2 recipe briefly and thought it only fiddlest with PYTHONPATH in bin/runzope.bat. I don't really understand the other issue with Unix specific threading that you mention. Lucky you, basically the current state is: zopectl doesn't work on Windows! But I found out that it's not that hard to enhance it in a way so it does work on Windows... all you need to do is to look into the internals of zopectl and zdaemon combined with how configuration files are parsed at Zope startup... and add some platform specific conditional code. Now after a refreshing my memory it fails on socket handling in zdctl.py in zdaemon on the line (sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)) where socket.AF_UNIX is not defined on Windows. Basically the way Zope is started in non-foreground mode on Unix is different from Windows, where you need to install a service which you can start/stop/restart... I see. So that's a bug in Zope 2's Windows compatibility? Is there a tracker issue for this? First off, I think ploneenv would need to modify the runzope.bat script so that it calls the activate script before startup. Wouldn't it be enough to adjust the PYTHONPATH to look into the workingenv directory first? I thought that's the only thing that's really necessary to activate a workingenv? Calling the activate script (on Windows) and including it (on Unix) is the way to activate a workingenv. Internally, activate does more or less what you say, but I never had to worry about that. Daniel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)
ploneenv is a one module Python script that builds heavily on workingenv and setuptools. What it does: - It creates a Zope instance for you. You always provide the ``mkzopeinstance.py`` script that you want to use as an argument. E.g.:: ploneenv ~/myzopeinstance \ --mkzo=~/lib/Zope-2.10/bin/mkzopeinstance.py - It creates a workingenv in the Zope instance for you. - It installs the *Plone egg* by default. However, you could just as well install something else in your new Zope instance. ploneenv is not Plone specific. Please find the complete intro here: http://danielnouri.org/blog/devel/zope/ploneenv-intro.html Part of this project is the Plone egg, which is a way to install Plone doing ``easy_install Plone``. ploneenv is a work in progress, however it works! There is no Windows support yet, though this should be trivial to add. Plus, it spits a lot of useless warnings (trying to compile Python scripts in skins/). I might have to take out the PIL dependency for now because I'll probably retract this: http://dev.plone.org/plone/changeset/12150 Once you guys tell me where to put this on svn.plone.org, I'll move it there. I would suggest svn.plone.org/svn/Plone for the Plone egg, however, some people might find this confusing I guess. For those of you that are confused about this and ploneout: ploneenv is an *alternative* and arguably more light-weight approach to setting up a Plone 3.0 instance. However, both approaches have their pros and cons. Daniel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)
I'm obviously for ploneenv/workingenv. I wouldn't have developed ploneenv
otherwise. So here is my pro-ploneenv reactions.
Martin Aspeli wrote:
First of all, I think this is great. :) The important thing here is that
people can use what they feel comfortable with - at the end of the day,
all the actual software should become eggs that we can share.
However, I'd like to try and clarify what I see as some of the
philosophical differences between ploneout and ploneenv. Hopefully, this
is useful to people.
I honestly don't think it's a fair criticism of zc.buildout-based
solutions that they are more heavyweight or complex (not that Daniel has
said that, but it seems to be a fairly common sentiment). The only hard
things for me when I started to work with zc.buildout to help Hanno
complete ploneout were (a) getting over my initial fear of something new
with a scary name and (b) understanding setuptools and eggs in general.
The whole of zc.buildout + ploneout's specific recipes (more on that
later) is probably a bit bigger than workingenv + ploneenv, but not by
an order of magnitude or anything like that. Most of the code is fairly
trivial plain python.
I believe that the whole of zc.buildout and ploneout is *a lot* bigger
compared to workingenv and ploneenv in lines of code. Unless you mean to
compare the buildout *recipes only* with both workingenv and ploneenv, which
seems unfair. For the reasons of compactness and transparency, I expect
ploneenv to be more maintainable.
Anyway, the main reason I think that workingenv is simpler is because it's
transparent to the user. By user I mean someone who has used distutils
before (i.e. python setup.py install) and someone who wants who has done
Zope instances before and wants to reapply his experience.
ploneenv is easier for developers because it lets them use Zope instances
the way they're used to use them. That is, bin/zopectl works, Products/
works as expected etc. And there is no way that workingenv could decide to
delete any directory, which you might consider a pitfall with ploneout.
Now, I suspect ploneenv and ploneout are not equivalent. ploneenv gives
you a new Zope instance which you can use for your own development or
deployment. ploneout is aimed squarely at core Plone developers, because
it configures all of Plone's eggs as development eggs and does something
similar for its products.
My impression was that ploneout would at some point grow a deployment
configuration.
So, let's instead compare ploneenv with the PasteScript template I've
been making that lets you create a new buildout for your own project.
This uses the same recipes as ploneout in order to create a Zope
instance (and more), but considers Plone as a dependency to be managed
by buildout. Let's also assume that the Plone egg that Daniel mentions
exists, and that it takes care of all the products. For comparison's
sake, let's also say that you want to use an existing Zope (2.10.2)
installation rather than let zc.buldout download, compile and configure
it for you.
BTW, the Plone egg *does* exist[1]. And I'd like to move it to
svn.plone.org :-)
$ paster create -t plone3_buildout myproject zope2_install=~/zope2.10
This creates buildout_test/buildout.cfg after asking a few questions
(about Zope username/password, port, development mode, verbose
security). Here's minimal version (using the fabled Plone egg, and you
get a bit more documentation in comments when you do it for real):
[buildout]
parts = instance
eggs = Plone
[instance]
recipe = z2c.recipe.zope2instance
zope2-location = ~/zope2.10
user = admin:admin
eggs = ${buildout:eggs}
You then run (once):
$ python bootstrap.py
And then (each time you change buildout.cfg):
$ bin/buildout
zc.buildout is basically just a command runner. It makes it easy to pass
stuff around in options between the different sections of
buildout.cfg. These options are used by various recipes (eggs with
commands that buildout finds using entry points). For ploneout, Hanno
and I wrote a couple of recipes, the most important one being
z2c.recipe.zope2instance, which can create and configure a zope 2
instance. To do so, it needs to know where to find Zope, the root user,
and which eggs you want Zope to know about (here referring back to the
global list of eggs in the [buildout] section).
I've been working with buildout before[2], but I still find it hard to use
(not as someone who only executes bin/buildout obviously, but as someone
trying to make a testrunner script, for example).
Because Zope 2 isn't terribly good with eggs, the recipe uses
zc.buildout's fairly sophisticated egg support to tell Zope exactly
which eggs you want it to know about (in this case, that's just the
Plone egg, and all its dependencies, i.e. all of Plone). Hanno also made
use of this recipe to create a wrapper around 'zopectl' that (a) works
on Windows and (b)
[Framework-Team] install-plone.py
Hello there!
I created a script install-plone.py that should help at least get an
idea of how the deployment of Plone 3.0 should look like.
Note that this is work in progress. I hope that people will help me
with figuring out the problems with this, and help me improve it.
You can download it from here:
http://danielnouri.org/svn/scratch/Plone/trunk/install-plone.py
It requires workingenv. Download it:
http://svn.colorstudy.com/home/ianb/workingenv/workingenv.py
If you have workingenv.py in your path, 'install-plone.py' will find
it, otherwise you need to provide the path to the script (try
'install-plone.py --help').
You can then run install-plone.py like so:
python install-plone.py --site-packages \
-f http://danielnouri.org/svn/scratch/Plone/trunk#egg=Plone-dev
-m /PATH/TO/bin/mkzopeinstance.py
/PATH/TO/NEW/INSTANCE
The --site-packages, and -f switch are forwarded to workingenv.py.
Consult 'workingenv.py --help'.
After having run install-plone.py, you should have a new instance in
/PATH/TO/NEW/INSTANCE.
Problems:
- I forked the EXTERNALS.txt from the 3.0 bundle. I didn't dare to
put an '__init__.py' with this into the bundle itself:
'__import__('pkg_resources').declare_namespace(__name__)'. This
should be all that's required though. And it shouldn't harm anyone.
- I haven't thought enough about dependency handling of Products.
Right now as you can see I'm using the 3.0 bundle. This is not what
we want for releases. Maybe we should have a '3.0-release' bundle or
so and create the egg from there.
- No lib/python packages are set up. This should be trivial though
once we have a page that links to all eggs, or once we register all
our packages with the Cheese Shop.
- Currently, the script does not install any zcml slugs in the new
instance. This should be easily fixable once we know which .zcml file
defines all our dependencies zcml-wise. (It's a pain that we have to
define our dependencies twice, though.)
- Zope does not start up due to some import error. ImportError: No
module named ZopeVersionControl.ZopeRepository. I couldn't find this
Product, any pointers welcome!
- I expect some other problems with the Products namespace that we
need to sort out. However, I'm optimistic, as I had the Products
namespace package working when I experimented the first time with
eggifying Plone.
- The script does not activate the workingenv. Eventually, we should
change the Zope skeleton to include 'bin/activate' before doing
anything else. Currently, this means that before you start up Zope,
you have to run 'include bin/activate'.
- The script should run on Windows, though I can't test it.
Cheers
Daniel
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: install-plone.py
I forgot another obvious problem: - Should not depend on the user to have workingenv.py installed. The script should download it if it's not there. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Error starting 3.0 bundle
Martin Aspeli wrote: whit wrote: my opinion is a little elbow grease to get this worked out now rather than later would go a long way. eggs are bit of pain, but we don't need to wait for any zope gods to descend from on high to make things better. I agree in principle, I just can't bring myself to spend lots of time on low-level setup when I really just want to get something done. I still haven't managed to get eggs to work reliably for tests or Zope startup. I also find it a bit difficult to work with workingenv.py - not terrible, but I tend to interact with the same Zope instance in more than one terminal and then I need to keep the active env's in sync. I always have one terminal for testing and one for running Zope in foreground. I also don't switch between environments too often. For me it's bearable to not forget to switch environments. And heaven knows how any of this works on Windows... workingenv has been tested on Windows, AFAIK. Also setuptools. Plus, we have a setuptools-enthusiastic core developer on Windows amongst us. ;-) Daniel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Error starting 3.0 bundle
whit wrote: You could call it temporary in that Zope will hopefully get better at development eggs and therefore render a weaved-together bundle like this obsolete (instead, you'd have a bundle with eggs and then you'd easy_install each one). To be honest, I find the bundle fairly convenient though, just co and ln into lib/python. currently, the only thing that zope does wrong with eggs is zope.testing. if you use --test-path=/path/to/dev/egg, the test-runner will even work with eggs(though this is super annoying). Now that the PYTHONPATH bug is fixed, you could conceivably just put the plone-lib dir on the PYTHONPATH and zope could find it. Personally, I see this as a stop gap to doing the due diligence to get our own egg story sanified(and we should fix zope.testing on the way). so really, this is our problem now, not zope's. This is biting the Zope 3 people *right now*, too. I wonder what Philipp wrote in his the new edition of his book about eggs and tests. I have been bitten by zope.testing too... :-/ also, zope2 itself is just a few minor changes away from being egg installable itself at which point we should be able to deal with everything outside of Products via egg recipes. my opinion is a little elbow grease to get this worked out now rather than later would go a long way. eggs are bit of pain, but we don't need to wait for any zope gods to descend from on high to make things better. I mean... if you could say easy_install Plone3=dev and be ready to work, how cool would that be? Kevin Dangmoor attribute much of TG's success and rapid growth to making the packaging work. rant off/ +1 I really hope I can put some time into this in the following days. Daniel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [AJAX] - Bling vs. KSS round 1
Hi! Martin Aspeli wrote: Hi Daniel From Saturday to Tuesday, I attended 4 days of presentation, discussion and hands-on experience with KSS. First of all, thanks to Godefroid for hosting a very nice sprint and to the whole team for the good time I had! I want to share some experiences with the framework team and bring in some new perspectives for this discussion. This is very, very useful! :) A couple of responses to some finer points. My feeling is that kukit is quite flexible, even if it might have a rough spot here and there. Maybe registering of plugins can become a bit easier still. I also dislike the class value hacks, i.e. kukit-key-value as a class versus kukit:key=value as an attribute. But as Martin points out in this thread, you can just use the second approach if you're not paranoid about (transitional?) HTML compliance. I believe Balazs said IE (surprise) has problems with the XML attribute version, too. :-( Ugh. Balasz, can you verify? - Azax is a Zope 2 and/or 3 library that can talk to kukit. It provides a view base class (AzaxView, which extends BrowserView) that makes it easier to construct kukit commands for sending back to the client, as well as handling things like the registration of appropriate browser resources. Handling registration of browser resources? I haven't seen that in a view. This is a ZCML directive for aggregating multiple stylesheets into a single Z3 browser resource, so ++resource++kukit.js is actually pulling in all kinds of smaller files, kinda like what RR does but at a lower level (and more general). Ah now I know what you mean. The view code is generally very close to Ben's PJS. That's not expressly true, since PJS is about proxies, so if your client side JS can handle (or is extended to handle) method foo() you can use foo() on a PJS proxy straight away. In KSS, you'd probably write a server side named command adapter with new custom behaviour. But it's true that the resultant syntax in most cases is quite easy to read and natural. The output is not JavaScript however, but commands for the client to process. The idea being that an abstraction of JavaScript is easier to test than actual JavaScript code (which will require hacks here and there). Probably. Do we have any tests that test the actual results in the wild? An example is the testReplaceContentRegion function, which does the switching of tabs (edit, view etc.). The result of the call view.replaceContentRegion is a dict, which you can conveniently test for: http://dev.plone.org/collective/browser/ploneazax/PloneAzax/trunk/tests/test_menus.py#L60 Note that defining your own client actions is seldomly needed. There are a few powerful primitives available, like set attribute of node element, or replace childnodes. This is most of what you'll need for your everyday work. That was my feeling too. If people have use cases they think cannot be handled this way, it'd be good to hear about them. Most of the ones I can think of would be solved quite well with this basic functionality plus some abstractions of effects (esp. common Plone-standard effects with different semantic meanings, like a 'highlight' that always looks the same). What about refreshing the breadcrumbs when you change title? Or the navigation portlet? What about changing the state of an object without reload, or copy? Is there a list of what Bling does (when it's fixed)? I'm unsure but I don't think so. As much as I agree that inline editing of the WYSIWYG editor is really nice to have I don't see why it's particularly difficult to implement. Probably because kupu is complicated. The BlingEditor, based on TinyMCE *ought* to be reusable, and I know Ben spent a fair amount of time on it. I realize the rich-text editor seems to be a real priority for you. I'm pretty sure though that the KSS people can implement this. It's a priority mostly because I think it's complex and thus not something to leave to the last minute. I have a gut feeling that if anything is going to uncover major problems, this is it. :) I may be wrong, but I think this is well doable. Using the BlingEditor implementation would certainly be another nice proof of concept of KSS's flexibility. I suggest that we ship KSS with Plone 3.0, but not install it per default. Why? Because the step is too big. There's still lots of work to be done (on the Plone front), to make the templates really ajaxyfiable. Interesting position. I have a feeling we may drift in a direction where that's not a viable option, although I really agree that Plone must work with Azax uninstalled/disabled. What I would say is that we shouldn't rely on template customisations in PloneAzax and ATAzax. This will quickly become a maintenance nightmare. If changes truly are about ids and CSS classes only and are non-intrusive, then that should be fine. I totally agree. The
[Framework-Team] Re: Names, names and we need a decision
Martin Aspeli wrote:
Daniel Nouri wrote:
whit wrote:
Martin Aspeli wrote:
Hi Hanno,
I'm happy to write the plone / plone.app announcement, and I can
write the bit about guidelines for when to use them. However, I'm
not too sure how we do the svn organisation.
- are we recommending people use ZopeSkel?
cautious but enthusiastic non-fwt +1 here? I'm hoping now that topp
has Ian Bicking aboard we may have a chance of getting some expert
cycles to resolve the skeletor/paste/zc.buildout/instancemanager
overlap. but for creating basic stub skeletons ZopeSkel seems like
the simplest starting point though. I need to look at it again
though; would we also need a ploneskel?
ZopeSkel is an easily extensible *collection* of skeletons for Zope
projects (Plone projects included). It has currently two skeletons
for Plone, the plone_core and the plone2_theme (=DIYPloneStyle)
skeleton. Get the latest SVN version
easy_install ZopeSkel==dev
and look at the list of templates
paster create --list-templates
and
paster create --help
Ian looked at it and he had some suggestions (like putting docs like
INSTALL.txt etc. into a top-level doc/ directory instead of in the
package itself). ZopeSkel has a very small and clear goal.
instancemanager and zc.buildout do something completely different, and
skeletor is in between.
Do we have (or could we create) some very
for-new-developers-and-optilude documentation on how exactly people
install this, run this, and then get it into svn in the right way?
We need to be able to point people at that before we can tell them to
use that package structure. I'd rather say use this tool's structure
rather than describe a structure in detail, though!
I'll write a short how to. In the meantime, feel free to give it a try:
1) Install EasyInstall:
http://peak.telecommunity.com/DevCenter/EasyInstall#installing-easy-install
2) Install ZopeSkel: easy_install ZopeSkel==dev
3) In the directory in which you want to create your new project, do:
paster create -t plone_core
This will ask you a few questions, amongst others, what's your namespace
package (- 'plone'), and what's your package name (e.g. 'i18n'). After
that you'll have a directory called ${project}
4) svn import -- ${project} goes into a toplevel directory next to other
projects with the same namespace package, e.g. plone.form and plone.i18n
live in the same directory -- which should be the Plone SVN top level
directory.
5) Realize that it's really easy ;-)
6) Read http://peak.telecommunity.com/DevCenter/setuptools to learn what
setuptools is about. Look at #development-mode in particular.
I need to clean up the templates a bit before the 0.2 release. I also
want to add a tests.py in which you can uncomment and test away. We can
also create a less generic template (like the existing plone2_theme)
that has more files to start with in it. Suggestions, please!
Important note: If you want to use your project as a Zope 2 Product,
you'll have use Rocky's pythonproducts. If you answer the question Do
you want a Zope 2 product with Yes, it'll create the required zcml and
installation instructions for you. Why pythonproducts? Because eggs
and Products/ don't go together.
Cheers
Daniel
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
