18 Things I Wish Were True About Plone
|
|
| 1 2 3 4 5 ... 7 |
Tarek Ziade
|
2008/1/31, Laurence Rowe <[hidden email]>:
Yes we were quite impressed at the sprint by the Solr/Lucene solution through Enfold packages. Maybe we could introduce a second catalog in Plone yes, to deal separatly with some indexes like SearchableText, etc, to ease the integration of an alternative indexer. From our benchmarks over 20k documents, a solr search is about 100 times faster (and the ZODB gets lighter) Tarek Laurence ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Tarek Ziadé
|
In reply to this post
by Laurence Rowe
Neat !
I'll check on this
|
||||||||||||||||
Paul Everitt-3
|
In reply to this post
by per9000
Per Erik Strandberg wrote:
> #19 Zero threshold for new Plone-wannabe's > > Trying to get under the skin of Plone is just days or months of work and > *fresh converts* only have a limited amount of patience before they > reconvert into some other church. Plone will die without these fresh > converts. Can we make this, and your points below, #1 on the list? You have expressed very well my leading concern. And it comes back to product vs. platform. The platform people will say: "So what, you get such a big payback on flexibility." At a minimum, I'd like the Plone Summit to take a vote and see if people agree that (19) is true. And then, get a statement on the severity of the problem, if "Plone" says it is true. --Paul > Here are my hints to getting more fresh blood to the Plone Cult: > > #19.1 Hello World in less than an hour > > Can you remember your first Python script? Was it something like this: > print "hell o world" > > If it was then did it take a week to make it happen? Nope. It took five > seconds because you already know five programming languages, you know > html, you know css and you can type in both emacs and vi. Why then > should it take a day (or a week, or more) to make a content type in > Plone the first time you try it? It sure for for me and I'd like to > think that I am, at least on sunny days, pretty bright. > > Making hello world in Plone simpler could be fixed in many ways: > - making the Plone platform simpler > - providing some "fresh plone convert handbook" > - better tools like some emacs plone-plugin or so (just kidding - I > mean: a vi plug-in [:)]-|--< ) > - perhaps something like GROK is the key? > > > #19.2 Minimal but complete tutorials on "all" of the features of Plone > (one at a time) > > I don't know if more documentation/tutorials is the key - but it might > be. The problem I have with most documentation/tutorials is that they > want too much at the same time (or to little). > > Instead of showing content types, tools, skins, views, and zcml *at > once* I'd vote for a set of tutorials that does a new content type, > another that does view templates and so on. Some other tutorials are > like "just do this - it's simple" but you are unable to follow it and > there are no downloads. > > I even did some tutorials myself ( > http://pererikstrandberg.se/blog/index.cgi?page=PloneCms ) I don't know > their quality, but "they work for me". What I aimed for was: > - minimalism: many plone plugins have more than 100 files, really few > have less than 10 files. My tutorial has four files. > - downloadability: No one wants to read a tutorial unless they have > to. If a simple download is enough then that's what I do. Then I look at > the code, then I might read the tutorial. > > > #19.3 If someone "just wants to do python" then let them > > Now they have to do a lot more. > > > #19.4 Complete/Simple/Working documentation > > As I said: I don't know if more documentation is the key. I'd vote for > less but "better" documentation. What better is I am afraid I do not know. > > > > > > /Per > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Paul Everitt-3
|
In reply to this post
by per9000
Per Erik Strandberg wrote:
> #19.1 Hello World in less than an hour > > Can you remember your first Python script? Was it something like this: > print "hell o world" > > If it was then did it take a week to make it happen? Nope. It took five > seconds because you already know five programming languages, you know > html, you know css and you can type in both emacs and vi. Why then > should it take a day (or a week, or more) to make a content type in > Plone the first time you try it? It sure for for me and I'd like to I think "you" in that sentence is the key word. Who is "you"? a) I think one historical lesson from ZClasses was that it pulled in people that weren't Python people. Moreover, people that didn't intend to become Python programmers. Was that true, and if so, should it be true for Plone? b) I do my work as PM on large Plone projects. I spend a lot of time trying to bootstrap a species called "customer developers". In my opinion, many things customers want to avoid going to the vendor for, they don't want become Python framework developers to do it. Moreover, they aren't always "trusted" enough to have full access to the Plone server, add code, and restart. Trust first, and self-desired skillset second, define an under-appreciated "you"...IMO. --Paul ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Alan Runyan-3
|
In reply to this post
by Martin Aspeli-2
> Having proper add-forms for content is hugely important too, by the way.
> portal_factory should die a silent death. Unfortunately, that's hard in > CMF/AT land. FATE has a solution for this problem, IIRC. Really what should happen is we start an planned orderly transition away from AT. -- Alan Runyan Enfold Systems, Inc. http://www.enfoldsystems.com/ phone: +1.713.942.2377x111 fax: +1.832.201.8856 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Rudá Porto Filgueiras
|
In reply to this post
by Tarek Ziade
On Jan 31, 2008 8:55 AM, Tarek Ziade <[hidden email]> wrote:
> > > 2008/1/31, Laurence Rowe <[hidden email]>: > > > > > > > #20: Reduce our reliance on ZCatalog for navigation *and* searching > > > > > > Or rather, separate the two so that searching can be separated out to a > > > different tool, e.g. Xapian. Work was done on this at the Snow Sprint. > > > > I think we should aim higher - from my brief look at solr it should be > > possible to offload navigation as well as searching. This would be a > > huge win in large deployments. > > Yes we were quite impressed at the sprint by the Solr/Lucene solution > through > Enfold packages. Maybe we could introduce a second catalog in Plone yes, to > deal > separatly with some indexes like SearchableText, etc, to ease the > integration of an alternative indexer. From our benchmarks over 20k > documents, a solr search is about 100 times faster (and the ZODB gets > lighter) > > Tarek Today, one improvement to the ZCatalog slowness is put it in your own ZODB file and tunning the size of ZODB cache objects in RAM to higher number. And because ZCatalog objects are tiny, Zope will not eat all your RAM and search will be 100 times fast too. But this solution will be ever limited in some big database, because you need to put all ZCatalog objects in RAM. :-( -- Rudá Porto Filgueiras Weimar Consultoria http://python-blog.blogspot.com Hospedagem Plone, Zope e Python? http://www.pytown.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Alan Runyan-3
|
In reply to this post
by Alan Runyan-3
> Really what should happen is we start an planned orderly transition
> away from AT. I need to be more specific. This could leave people confused. I believe we should evaluate the goals of Archetypes and see how we can do it with existing frameworks. Also we should get feedback about CPSSchema. The success and failure. We have a lot more experience nowadays. My gut feeling is that Archetypes provides a significant amount of convenience that is unparalleled. And Plone made this convenience attractive and usable by humans. People believe that "defining Archetype models" is Plone. So when we think about Plone - we should think less about technology and more about the experience of customization and approach to solving content management problems. Not technology. Experience is what has made Plone rival Vignette (and why some customers have moved from Vignette to Plone!) and other 'big iron' CMSs. I will post my list in the next few days. I'm going down to NOLA for Mardi Gras. Here is one of my list items that should come as no surprise to people who have been around in the Plone community. - I do not believe Plone is a general purpose web platform. I believe anyone who desires "sematic web search engine front end" are not our customers. Our deployments are between 5-500 end users managing content is our sweet spot. These users are doing CMS activities. Mainly editing, workflowing content and assigning tasks to each others. Luckily we have been doing CMS for quite a long time. And have loads of experience. So I believe its really a matter of what we, the Plone developers want to bring the platform in the coming years. /me turns up Professor Longhair and drives off into the horizon alan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
yvesm
|
In reply to this post
by Alexander Limi
> I wander if the ExtJS grid component could be utilized for this? See
> http://extjs.com/what-ext-javascript-library-all-about > Laurence Looking at the 11 min demo video clip at http://extjs.com/what-ext-javascript-library-all-about, it looks great indeed. The "grid control" has support for ordering on any column, but also really gives the impression of a "desktop" table in that column widths can be adjusted on the fly, hidden/shown, etc. Lines or cells can also be styled according to rules that can depend on data, so that would take care of my need to have e.g. low pH values in red. I did that with a very ugly mix of ZPT and CSS before and I don't want to do it again. One thing that's missing (at least in the video) is ability to style elements on the fly, that is use a window to specify thresholds and have the value background cells or font color change. That would be very useful e.g. for people to look at what different regulatory bodies define as thresholds. I think this ability to style on the fly applies to fields other than data crunching so IMO this would be a general purpose core behaviour for a new "grid" type. ExtJS may also prove a bit disruptive. The section on "tree control" looks like a direct contender to the navigation in Plone and the next section on batching too ... Not sure I want to go that deep in JS land, but then again. Yves ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Martin Aspeli-2
|
ExtJs is very modular. It also works nicely with jQuery which is likely to be part of Plone 3.1. We can pick the bits we want and use them on their own. Martin |
||||||||||||||||
Christian Scholz-2
|
In reply to this post
by Laurence Rowe
Hi!
Laurence Rowe wrote: > Take a look at collective.tin, it's getting fairly feature complete now. > Basically it lets you build zope3 content types for plone that are > stored in a folder whose content is a database table. I will finish the > tutorial at some point, but am in need of good example. Godefroid mentioned it and I had a look at collective.rope at the Snow Sprint. Does tin also provide folderish content? I will definitely have a look at it. Does it make any different in performance? -- Christian > > Laurence > > Tarek Ziade wrote: >> >> 2008/1/30, Christian Scholz <[hidden email] >> <mailto:[hidden email]>>: >> >> > #7: Improve the tabular data story >> > >> > Right now, Plone is a great choice for content-centric >> applications, and >> > it also have the possibility to integrate with more structured, >> relational >> > data via the SQL database adapters. However, most of these >> solutions are >> > old — and while they work, Python has acquired a number of great SQL >> > integration tools in the meantime, SQLAlchemy being the weapon of >> choice >> > for most relational-thinking Pythonistas. >> >> I wonder if having an SQL story from the ground would also help >> performance. We recently moved one project which was more DB like from >> Plone/Zope to Django as we had to import lots of data on a regular basis >> and Zope was rather slow in doing that (it was an older Zope/Plone >> though which means a) Catalog might be faster these days but b) more >> stuff is happening in AT today). >> >> I am not sure what Godefroid experienced with collective.rope (an SQL >> adapter for Zope content) regarding performance but I think he mentioned >> that it's somewhat faster. Lovely Systems also told us that one of the >> mistakes from the beginning was to rely on the ZODB (also think of >> reindexing the Data.fs etc.) esp. with lots of data. >> So having at least the option to run over SQL would IMHO be a big win. >> (also politically for some clients who do not like the unknown). >> >> >> +1 >> >> for some applications, it is just impossible to use a plain Plone. For >> example >> a btree where people can add some content continuously will fail to work >> properly with very few users (conflicts, then failures). It is *so* easy >> to put Plone on its knees with Apache AB... :( >> I need to try RelStorage to see if it's more scalable on this (anyone >> knows?) >> (The good thing about this is that the Plone community is very advanced >> in caching matters ;) ) >> >> SQLAlchemy brings ways to work on this but the problem is that right >> now, for most cases, you will have to write your application in two >> different flavors depending on the storage you use >> Either mappings through an orm, either POZOs (Plain Old Zope Objects) >> >> ZODB is a great thing, but imho let's build a working group on this >> topic, driven by people of the Plone community, to see if we can come up >> with something more scalable. >> >> Tres Seaver and Stéfane Fermigier tried some years ago to bind Zope to >> the Java (JSR 170) content repository tool (JackRabbit - >> http://jackrabbit.apache.org/) at some sprint but people did not care >> too much back then iirc. >> >> I would be in favor of investigating in this, maybe at Python level >> first, no Zope, to write a PEP similar to the DB Api, to have a *plone >> content repository standard* then write some implementation. It could be >> a very light thing at first, focusing on content repository matters, and >> based on SQLAlchemy or Storm. >> >> That's a big work indeed... >> >> >> ++ >> Tarek > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- Christian Scholz video blog: http://comlounge.tv COM.lounge blog: http://mrtopf.de/blog Luetticher Strasse 10 Skype: HerrTopf 52064 Aachen Homepage: http://comlounge.net Tel: +49 241 400 730 0 E-Mail [hidden email] Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T connect with me: http://mrtopf.de/connect ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Christian Schneider-10
|
In reply to this post
by Alexander Limi
Hey List!
First of all I'm not a core developer and I have not been able to keep up with the whole thread on Limi's post, so some of the things I will mention might have been mentioned before, but I think that posting my opinion on Plone's future now is better than moaning when it's too late ;o) I'm usually not a conservative person, I love new things, gadgets and ideas. But the excitement that admittedly swept over me when I was reading Limi's post was severely quenched by the nagging feeling that Plone might (once again as it seems to me) be shooting for the stars (at least when it gets to some of the points in the post) without a solid base to start from. 3.0 introduced lots of cool new features, but some weren't really fully developd and others still aren't fully developed in 3.0.5 today. I know this is normal with software and open source projects in particular, but I really think the Plone community should think about a much needed consolidation phase before aiming for new features. I know that 4.0 isn't around the corner and that there'll be a 3.1 in between, but I also know that thinking up new features and developing ideas is way more fun than looking back and working over stuff that's already "finished". So this is really just an encouragement to everyone who plans to bring up the "dull conservative" topics at the planning summit in March. To make my point clearer I did a bit of a brain dump to bring up some topics that have caused me or Plonistas I know mild to severe headaches: 1. Handling of image scales: The way image scales are handled is just plain nerve wrecking. Having to subclass from a type, just to get one or two additional image sizes into Plone is way off. I know there's hacks to get around this, but they are just... well hacks. 2. Internationalization... LinguaPlone feels a bit like a deprived step child that's only fostered when the situation gets unbearable. Apparently half a year ago a new way of dealing with multilingual content was started (intriguingly called plone.app.multilingual), but I haven't heard of that one in a while and the svn log suggests it's already gone the way of the dodo (Note: If this is not the case and plone.app.multilingual is actually alive and kicking, see #12 and #15). 3. Staging of folders: Folders can be staged, but the behaviour when checking out a folder is capricious to say the least. The whole tree below the checked out folder gets copied, but the originals are not locked, so changes in the baseline will get overwritten once the folder gets checked in. This is especially painful when the folder is at the top of the structure. 4. References are another step child candidate that doesn't really feel like it should be used a lot because nobody likes it and the promise of plone.relations is very tempting although it's not quite ready yet (or is it? See #12 and #15). 5. Staging-integration into workflows: I think it should be (easily) possible to tell a workflow transition to trigger checkins/checkout. I know that some people get very religious when it gets to the separation of workflows, versioning and staging, but I find it hard to sell Iterate as it works out of the box. 6. Another inconsistency in Plone 3 is that one can use Iterate (shipped with Plone 3) to check out stuff to one's home folder, but you can also use CMFPlacefulWorkflows (also ships with Plone 3) to apply a special workflow to a folder structure. Checking out an object to the home folder removes the object from the workflow, so the checkout can not go through the workflow assigned to it's parent folder. 7. The effective-/expiration-dates are highly confusing and it's difficult to get the point across when explaining it to clients because objects don't only go through a workflow, they can be published AND expired at the same time. I guess coupling the effective-/expiration-dates to the workflow is difficult because Zope doesn't seem to have timed events, but I wonder if that is so difficult to implement in zope 3's event system. 8. The keywords/category system would be super-useful if it were actually.. well useful. Not being able to really manage the available categories and lack of tree-like structures stunt their potential (especially in combination with collections) severely (there's experts on these subjects that show up on lists every once in a while and there's several add-on products, but I think this functionality belongs in the core). These were the conceptual glitches I have struggled with, I also had to fight with some bugs in Plone 3. 9. The bugs that plagued the collection system, that were then fixed partially and then finally really fixed in 3.0.5 were annoying to say the least, however there's still a problem in 3.0.5 that got reported a couple of months back: 10. Removing non-multiValued-references in a ATReferenceBrowserWidget is impossible because the "remove" button is missing. There's a fix in the tracker (#6950) but it seems like it didn't get any attention (see #13). 11. Redundancy of products... 10 different products supposed to do one thing, none of which is really making a good job just plain sucks. This is not supposed to get a ranty quality, but it's a good change over to the next section :o) -> Community: I think that some of the problems mentioned above are due to the lack of organisation in the community. The following points are worth noting and I have heard of (or come up myself with) ideas for solutions that I would really like to get some attention: 12. Collaborative workspaces: I think some sort of official Plonista collaboration space should be available (something like OpenPlans?) where ideas are discussed and developed and where people with similar ideas can get together and work out ONE good product instead of 10 half-baked ones. I know nothing is going to replace mailing lists, but I think that while mailing lists are a good medium to discuss and maybe develop ideas to some degree, they don't really serve as a persistent vessel for the condensate of the discussion that gets updated when things change or are expanded. 13. Best idea I've heard of: Quality check team that establishes and runs a set of tests before EVERY release and also writes functional tests successively to substitute need for human testing (although a certain amount of tests run by humans must never be abandoned in my opinion). 14. Quality team might also cover add-on products and make sure that products that don't fulfil a set of minimal requirements (e.g. documentation, dependencies, good explanation of what it does on the products page, active tracker...) do NOT get published on plone.org. The amount of frustration hours and hours of product testing only to find out that none actually does what it's supposed to properly far outweighs the "awe" inspired by the plethora of products on plone.org. 15. News completely under-used: I don't have time to nor feel like reading through the huge amount of gibberish on planet.plone.org or the sometimes very dry ramblings on the lists just to find one interesting subject that gives me an update on some package or add-on product. However, I'd love to know if and what's going on with Plone so why not use the News section on plone.org for development-related news or maybe even create a different news section for development related stuff? So that's my Euro's worth to the subject (it took a while to write, so 50 cents would be an understatement and I prefer stable currencies ;o), I hope somebody reads this despite the fact that I'm basically a nobody in the community. Oh and I hope nobody is offended in any way, if anything sounded too harsh please forgive me, it's for the good of Plone ;o) Greets from Switzerland, Christian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Martin Aspeli-2
|
Hi Christian,
I think your list is important, but I think it's an orthogonal discussion to that of trying to reconceptualise some of the aspects of Plone that have become outdated or that need a fresh pair of eyes. I don't think we'll be discussing these types of points directly in SF next week, though I think we *should* discuss processes around quality and stability that we want to foster. Don't take this the wrong way, but I'd rather this discussion didn't degenerate into a list of "my pet peeves" at any and all levels of complexity and scope. Everyone has their own things they wish were different. Alex's list aims rather higher though, looking at the things that - in his experience - we could do better to reach a bigger audience. I'll try to reply to your points in turn, however. > 1. Handling of image scales: The way image scales are handled is just > plain nerve wrecking. Having to subclass from a type, just to get one > or two additional image sizes into Plone is way off. I know there's > hacks to get around this, but they are just... well hacks. This is due to the way Archetypes and ATContentTypes work. You could fix it now with archetypes.schemaextender, but externalising this configuration state would be a useful enhancement. Still, I don't think this is so serious an issue that we should be losing sleep over it. Most people seem happy with the existing scales or know how to create their own. > 2. Internationalization... LinguaPlone feels a bit like a deprived > step child that's only fostered when the situation gets unbearable. > Apparently half a year ago a new way of dealing with multilingual > content was started (intriguingly called plone.app.multilingual), but > I haven't heard of that one in a while and the svn log suggests it's > already gone the way of the dodo (Note: If this is not the case and > plone.app.multilingual is actually alive and kicking, see #12 and #15). Last time I checked, LinguaPlone worked fine. I think you're being a bit hyperbolic here. Yes, experimentation has been started with alternatives based on technologies that didn't exist when LP was created, but they lack a strong drive - probably because LP suffices and works well for most people. > 3. Staging of folders: Folders can be staged, but the behaviour when > checking out a folder is capricious to say the least. The whole tree > below the checked out folder gets copied, but the originals are not > locked, so changes in the baseline will get overwritten once the > folder gets checked in. This is especially painful when the folder is > at the top of the structure. Okay, so there's a bug/missing feature here. I don't even know how staging of folders should work conceptually, and I'd be inclined to just turn it off as a feature we don't support, but if you want to propose an alternative, please do so on this list (in a new thread). > 4. References are another step child candidate that doesn't really > feel like it should be used a lot because nobody likes it and the > promise of plone.relations is very tempting although it's not quite > ready yet (or is it? See #12 and #15). AT references work just fine for AT objects (read: virtually all content at this stage). Yes, we have newer, better generalised technologies in the pipeline, but that doesn't mean you should fret about the tools that are available right now, and which work. > 5. Staging-integration into workflows: I think it should be (easily) > possible to tell a workflow transition to trigger checkins/checkout. > I know that some people get very religious when it gets to the > separation of workflows, versioning and staging, but I find it hard > to sell Iterate as it works out of the box. I think this would be a good idea, though I struggle to think of the specifics of how it should work, conceptually. Again, if you have thoughts please let them be known! > 6. Another inconsistency in Plone 3 is that one can use Iterate > (shipped with Plone 3) to check out stuff to one's home folder, but > you can also use CMFPlacefulWorkflows (also ships with Plone 3) to > apply a special workflow to a folder structure. Checking out an > object to the home folder removes the object from the workflow, so > the checkout can not go through the workflow assigned to it's parent > folder. Yes, you're able to produce site structures that just don't work conceptually. I don't think we can ever work around all possibilities here. You can, however, tell iterate to use a different working directory (so long as the user can add content items there). We should have a UI for that. > 7. The effective-/expiration-dates are highly confusing and it's > difficult to get the point across when explaining it to clients > because objects don't only go through a workflow, they can be > published AND expired at the same time. I guess coupling the > effective-/expiration-dates to the workflow is difficult because Zope > doesn't seem to have timed events, but I wonder if that is so > difficult to implement in zope 3's event system. I don't understand this point. Workflow and content effective/expiration dates are orthogonal concepts. Maybe we need better documentation. > 8. The keywords/category system would be super-useful if it were > actually.. well useful. Not being able to really manage the available > categories and lack of tree-like structures stunt their potential > (especially in combination with collections) severely (there's > experts on these subjects that show up on lists every once in a while > and there's several add-on products, but I think this functionality > belongs in the core). Yep. This is by far the best entry in your list so far. :) I'd really like to see keywords revolutionised and made much more useful, but again people disagree on exactly how to do it and we seem to be lacking a champion to really take this to the next level. I suspect the metadata/tagging/annotation story will come up at the summit next week. > 9. The bugs that plagued the collection system, that were then fixed > partially and then finally really fixed in 3.0.5 were annoying to say > the least, however there's still a problem in 3.0.5 that got reported > a couple of months back: Mkay, bugs. Bugs happen. It's unfortunate, but it's true of any software. I'd like us to talk about how to improve our test coverage and manual testing, though. > 10. Removing non-multiValued-references in a ATReferenceBrowserWidget > is impossible because the "remove" button is missing. There's a fix > in the tracker (#6950) but it seems like it didn't get any attention > (see #13). Simple bug, I'm guessing. > 11. Redundancy of products... 10 different products supposed to do > one thing, none of which is really making a good job just plain > sucks. This is not supposed to get a ranty quality, but it's a good > change over to the next section :o) This is such an old topic it's getting rather boring. I think we need to live with some redundancy and quality discrepancy because (a) we are not a dictatorship and let people do what they want and (b) not all programmers are created equal and (c) not all programmers have infinite time to dedicate to products that they are not being paid for anymore. Solutions include product ratings/reviews on plone.org, "mercenary" teams to review products and suggest improvements, and some way of blessing products as semi-official "recommended" extensions. All of that's been discussed ad infinitum and then left incomplete due to lack of time and other resources. > -> Community: I think that some of the problems mentioned above are > due to the lack of organisation in the community. The following > points are worth noting and I have heard of (or come up myself with) > ideas for solutions that I would really like to get some attention: > > 12. Collaborative workspaces: I think some sort of official Plonista > collaboration space should be available (something like OpenPlans?) > where ideas are discussed and developed and where people with similar > ideas can get together and work out ONE good product instead of 10 > half-baked ones. I know nothing is going to replace mailing lists, > but I think that while mailing lists are a good medium to discuss and > maybe develop ideas to some degree, they don't really serve as a > persistent vessel for the condensate of the discussion that gets > updated when things change or are expanded. We have OpenPlans for this, and I think it works well. The problem is not the availability of tools and technologies, it's in the nature of how these projects come about, in the nature of the people who instigate them and in the fact that co-ordination and collaboration on one single product when there are three people with slightly divergent needs is hard and time-consuming. What you're really talking about here is to foster mini-projects that centre around the development of products with specific purposes. Projects require some leadership and a lot of hard work, as well as a dedicated and available volunteer base. Find us those groups and we'll give you all the tools you need. :) > 13. Best idea I've heard of: Quality check team that establishes and > runs a set of tests before EVERY release and also writes functional > tests successively to substitute need for human testing (although a > certain amount of tests run by humans must never be abandoned in my > opinion). Yep. Purely a question of non-existent manpower. We tried to whip up some support for this idea the last time we had a whinge-fest over an embarrassing bug that crept into a release. How many people stepped up and volunteered? That's right, you guessed it. > 14. Quality team might also cover add-on products and make sure that > products that don't fulfil a set of minimal requirements (e.g. > documentation, dependencies, good explanation of what it does on the > products page, active tracker...) do NOT get published on plone.org. > The amount of frustration hours and hours of product testing only to > find out that none actually does what it's supposed to properly far > outweighs the "awe" inspired by the plethora of products on plone.org. Yep. Better metadata and self-rating systems are on the horizon for plone.org pending manpower (in fact, George Lee and Alex Clark have almost completed this, but plone.org needs love). We don't want to be draconian or require detailed reviews before things are made available on plone.org because it'd be an off-putting bottleneck and probably stifle innovation. We *do* want to clearly highlight the products that tick the right boxes. > 15. News completely under-used: I don't have time to nor feel like > reading through the huge amount of gibberish on planet.plone.org or > the sometimes very dry ramblings on the lists just to find one > interesting subject that gives me an update on some package or add-on > product. However, I'd love to know if and what's going on with Plone > so why not use the News section on plone.org for development-related > news or maybe even create a different news section for development > related stuff? Good idea! I find planet.plone.org a very useful resource for keeping up with community trends (and most of it's not gibberish - that's a pretty denigrating choice of words). It may not be for everyone, though. Some projects have weekly (or monthly) newsletters where someone "in the know" compiles a list of what's been going on. I don't have time to do that, though, do you? :-) > So that's my Euro's worth to the subject (it took a while to write, > so 50 cents would be an understatement and I prefer stable > currencies ;o), I hope somebody reads this despite the fact that I'm > basically a nobody in the community. You are absolutely not a nobody in the community! You're a valued member who took the time to give us useful, constructive feedback. Don't take my cynicism the wrong way, we know about most of these issues and have rough solutions. The problem is always to find the money or time to do them, but that doesn't mean we shouldn't try. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Daniel Nouri
|
In reply to this post
by Martin Aspeli-2
Martin Aspeli <[hidden email]> writes: >> Zopeskel has the ability to provide a plone application developer the >> whole story for developing/extending any kind of component for a plone >> site - from the site package itself through to simple adapter >> customizations for say a portlet. Part of what I find attractive about >> this approach is that the architecture of the plone framework is >> largely undocumented in a palatable form. Creating customizations or >> new components is largely a process of following the plone 3 story >> back through all the core packages and piecing together the logic from >> an existing example and hoping that the example you have chosen is >> itself using good practice. The output of zopeskel I have found >> invaluable in both creating what would be considered the best code >> layout for a particular problem and also contains a lot of useful >> documentation. Strictly speaking, there's no guarantee that there isn't tons of cult-cargo code in ZopeSkel. I'd expect the templates to be of varying quality. One shouldn't underestimate the value of understanding and writing your own code. With generated code you'll have results quickly, but in the long run it's gonna take you a lot longer than usually to customize the code to fit your needs. Because, typically, you don't understand it. When you need to write otherwise generated code yourself, you're hardly in a better position. You don't want this code! You want as little code as possible in your own software. When we make ZopeSkel code templates, I think we should realize that we're doing them a lot because of *shortcomings* in API we generate the code for. These pieces of code that we generate -- they shouldn't be maintained across a hundred separate Plone products that use the templates. They should be made into functions of Plone itself, and maintained once! I think 'z3c.jbot' is a step into a good direction. I'll ignore the discussion about its implementation for a minute; I think it's hardly problematic anyway. jbot gives you a way to customize template code in views and viewlets by merely putting *one* file into one directory. Imagine how much (possibly generated) code you can avoid with this. And the code that *is* there even makes sense to Joe Developer (it's his own!). My point is: Code generation is too often treating the symptoms. Where applicable, we should go in and fix the API. > Yup - and this is a very good point. We need to bring the *useful* > extension points to the front. For example, we should have introspection > tools (TTW or otherwise) that make it easy to discover where something > (a template, viewlet, portlet or form action) comes from and what the > stub of code would be to customise it. DocFinderTab on steroids. :) I like to think that doc(test)s and tight APIs beat tools like DocFinderTab and ArchGenXML hands down. For every developer audience. Daniel ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Matt Halstead-3
|
In reply to this post
by Alexander Limi
Alexander Limi wrote: > 4. I want a random content population mechanism! To do proper automated > benchmarks, you need a realistic body of content to test it with. Luckily, > Tarek Ziade and others at the Snow Sprint 2008 already started work on > this. > As embarrassing as the code may be, I decided to upload to pypi a very lightweight component I developed for helping out with generating large amounts of zope content in a controllable way for testing. I also use it in a few importVarious setup steps around the place to generate an initial structure for a site. It is XML based with attribute hooks for calling python or loading data from files. It also has a post process hook for each node created so you can push a fresh node around a bit more. http://pypi.python.org/pypi/ely.contentgenerator ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Matt Halstead-3
|
In reply to this post
by Daniel Nouri
On Feb 1, 12:45 pm, Daniel Nouri <[hidden email]> wrote: > Martin Aspeli <[hidden email]> writes: > >> Zopeskel has the ability to provide a plone application developer the > >> whole story for developing/extending any kind of component for a plone > >> site - from the site package itself through to simple adapter > >> customizations for say a portlet. Part of what I find attractive about > >> this approach is that the architecture of the plone framework is > >> largely undocumented in a palatable form. Creating customizations or > >> new components is largely a process of following the plone 3 story > >> back through all the core packages and piecing together the logic from > >> an existing example and hoping that the example you have chosen is > >> itself using good practice. The output of zopeskel I have found > >> invaluable in both creating what would be considered the best code > >> layout for a particular problem and also contains a lot of useful > >> documentation. > > Strictly speaking, there's no guarantee that there isn't tons of > cult-cargo code in ZopeSkel. I'd expect the templates to be of varying > quality. > > One shouldn't underestimate the value of understanding and writing your > own code. With generated code you'll have results quickly, but in the > long run it's gonna take you a lot longer than usually to customize the > code to fit your needs. Because, typically, you don't understand it. > I would say it leads by example, and does not - by definition of being a skeleton - generate the details in the code you need to write. I am coming from plone as a framework point of view - not simple customizations that require simple template overrides or a couple of extra fields here and there. > When you need to write otherwise generated code yourself, you're hardly > in a better position. You don't want this code! You want as little > code as possible in your own software. > > When we make ZopeSkel code templates, I think we should realize that > we're doing them a lot because of *shortcomings* in API we generate the > code for. These pieces of code that we generate -- they shouldn't be > maintained across a hundred separate Plone products that use the > templates. They should be made into functions of Plone itself, and > maintained once! Most of what I see in zopeskel is the production of boiler plate zope 3 configuration and stub code, and buildout and setuptools configurations. What's of most interest is the layout and the points of entry that are recommended for adding function to your application. To reduce the volume of what a zopeskel recipe produces, I would have thought grok would have been the natural choice. I'm not arguing against what you say about various APIs, just pointing out that I'm not intending for zopeskel to be supplying large amounts of actual functional code that would be better hidden somewhere behind an API. > > I think 'z3c.jbot' is a step into a good direction. I'll ignore the > discussion about its implementation for a minute; I think it's hardly > problematic anyway. jbot gives you a way to customize template code in > views and viewlets by merely putting *one* file into one directory. > Imagine how much (possibly generated) code you can avoid with this. And > the code that *is* there even makes sense to Joe Developer (it's his > own!). > > My point is: Code generation is too often treating the symptoms. Where > applicable, we should go in and fix the API. > > > Yup - and this is a very good point. We need to bring the *useful* > > extension points to the front. For example, we should have introspection > > tools (TTW or otherwise) that make it easy to discover where something > > (a template, viewlet, portlet or form action) comes from and what the > > stub of code would be to customise it. DocFinderTab on steroids. :) > > I like to think that doc(test)s and tight APIs beat tools like > DocFinderTab and ArchGenXML hands down. For every developer audience. > > Daniel > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008.http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Plone-developers mailing list > [hidden email]://lists.sourceforge.net/lists/listinfo/plone-developers ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Alexander Limi
|
In reply to this post
by Paul Everitt-3
Just as a clarification here, it is #0 on my list of priorities — we have an entire third of the Planning Summit that has the "Approachable Plone" as its theme, which is why I didn't call it out as a separate point. It spans a number of my points, it is is exactly what my #1 point is talking about, giving people an entry point to start their customization. #2, Deliverance is another. #5, Unified install experience is another. Et cetera. My list left out a lot of notable things that I could have included — the 18 points were trimmed down from an original list of 30-40 points, and I have another 70-80 for later. And, what I leave out is as important as what I include. ;) There are a number of things that I'd like to discuss, but later. I think the major thing I missed was the static deployment scenario, which I think is hugely important both for the high end and the low end. — Alexander |
||||
|
Martin Aspeli-2
|
In reply to this post
by Daniel Nouri
Daniel Nouri wrote:
> My point is: Code generation is too often treating the symptoms. Where > applicable, we should go in and fix the API. This is a great point. I think *skeleton* (starting-point) code generation is a very important tool, because no matter what you do you can't have *zero* boilerplate (or rather, if you did, there'd be 100% magic that was hard to understand later). By having a way to generate "current best practice" for people we make it easier for them to get started and easier for us to push a consistent story (if the best practice changes, we re-release ZopeSkel). However, I think there should be about 10-20 lines of code in total being generated, with no illusion of round-tripping/re-generation. How does that fit with something like ArchGenXML, which *does* depend on round-tripping/re-generation? I think AGX should just spit out a file that reflects the choices the user made, and the framework should be able to read this file and use it to configure itself. That way, there's only one code generation step (get the boilerplate) and from then on you're just saving your settings in a configuration file. This is a bit like Glade, if you've used that. There should possibly also be a step that allows you to generate the code from the configuration state as a run-once get-out clause if you decide you'd really rather be a Python programmer after all. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Stephan Richter-2
|
In reply to this post
by Matt Halstead-3
On Thursday 31 January 2008, Matt Halstead wrote:
> Alexander Limi wrote: > > 4. I want a random content population mechanism! To do proper > > automated benchmarks, you need a realistic body of content to test it > > with. Luckily, Tarek Ziade and others at the Snow Sprint 2008 already > > started work on this. > > As embarrassing as the code may be, I decided to upload to pypi a very > lightweight component I developed for helping out with generating > large amounts of zope content in a controllable way for testing. I > also use it in a few importVarious setup steps around the place to > generate an initial structure for a site. It is XML based with > attribute hooks for calling python or loading data from files. It also > has a post process hook for each node created so you can push a fresh > node around a bit more. > > http://pypi.python.org/pypi/ely.contentgenerator We have developed extensive sample data generation techniques in Zope 3 and I have been using it for several years already. See: * z3c.sampledata: http://svn.zope.org/z3c.sampledata/ * z3c.datagenerator: http://svn.zope.org/z3c.datagenerator/ While z3c.sampledata is the basic mechanism to generate sample data within any kind of object, usually a root folder, z3c.datagenerator contains a lot of helper functions for generating names, addresses, phone numbers, E-mail addresses, domain names, etc. The packages are designed in a way that the same data is generated, if you specify the same random seed. Also, we have created test layers that do not use empty databases, but start with a database populated with sample data. This makes functional tests faster and more usable. If you want more information, let me know. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Christian Schneider-10
|
In reply to this post
by Martin Aspeli-2
Hey Martin,
thanks for replying, it's good to know someone influential got the message, even though you might have gotten it slightly wrong. In the introduction I was trying to express that the bugs and lack of features were just examples and "justifications" to why I propose/encourage the things at the end of my mail. Naturally I brought up things that I or other I know ran into, but the examples were just a selection of symptoms to what in my opinion ails Plone development. I'm sorry if what I said came across the wrong way (and sorry for the "gibberish", I really just like the word ;o) So I'll cut through your replies to the bugs/features (or lack thereof) and comment on the later points that were the ones I really think should be discussed at the summit: Martin Aspeli wrote: >> 12. Collaborative workspaces: I think some sort of official Plonista >> collaboration space should be available (something like OpenPlans?) >> where ideas are discussed and developed and where people with similar >> ideas can get together and work out ONE good product instead of 10 >> half-baked ones. I know nothing is going to replace mailing lists, >> but I think that while mailing lists are a good medium to discuss and >> maybe develop ideas to some degree, they don't really serve as a >> persistent vessel for the condensate of the discussion that gets >> updated when things change or are expanded. > > We have OpenPlans for this, and I think it works well. The problem is > not the availability of tools and technologies, it's in the nature of > how these projects come about, in the nature of the people who instigate > them and in the fact that co-ordination and collaboration on one single > product when there are three people with slightly divergent needs is > hard and time-consuming. OpenPlans is a cool site to collaborate, my point is that there's no mentioning of it anywhere in the products section or any other resources specifically aimed at product developers. I guess a paragraph like "If you start a new product make sure you look for similar projects and think about joining that project instead of creating a new one. You can find many projects on OpenPlans at www..." in a prominent space of the products section and in some of the Developers docs might actually be enough. Encouraging using the "Project page" for OpenPlans links might help as well. >> 13. Best idea I've heard of: Quality check team that establishes and >> runs a set of tests before EVERY release and also writes functional >> tests successively to substitute need for human testing (although a >> certain amount of tests run by humans must never be abandoned in my >> opinion). > > Yep. Purely a question of non-existent manpower. We tried to whip up > some support for this idea the last time we had a whinge-fest over an > embarrassing bug that crept into a release. How many people stepped up > and volunteered? That's right, you guessed it. Actually I didn't know that... so I guess you have your first volunteer now. I'll think about it and will try to start an OpenPlans project for this and if it's OK I'll try to get some support on the lists and in the chat once I have a rough draft for testing requirements. >> 14. Quality team might also cover add-on products and make sure that >> products that don't fulfil a set of minimal requirements (e.g. >> documentation, dependencies, good explanation of what it does on the >> products page, active tracker...) do NOT get published on plone.org. >> The amount of frustration hours and hours of product testing only to >> find out that none actually does what it's supposed to properly far >> outweighs the "awe" inspired by the plethora of products on plone.org. > > Yep. Better metadata and self-rating systems are on the horizon for > plone.org pending manpower (in fact, George Lee and Alex Clark have > almost completed this, but plone.org needs love). We don't want to be > draconian or require detailed reviews before things are made available > on plone.org because it'd be an off-putting bottleneck and probably > stifle innovation. We *do* want to clearly highlight the products that > tick the right boxes. Ok I guess that's more diplomatic than my approach, can't wait to see it implemented! >> 15. News completely under-used: I don't have time to nor feel like >> reading through the huge amount of gibberish on planet.plone.org or >> the sometimes very dry ramblings on the lists just to find one >> interesting subject that gives me an update on some package or add-on >> product. However, I'd love to know if and what's going on with Plone >> so why not use the News section on plone.org for development-related >> news or maybe even create a different news section for development >> related stuff? > > Good idea! I find planet.plone.org a very useful resource for keeping up > with community trends (and most of it's not gibberish - that's a pretty > denigrating choice of words). It may not be for everyone, though. Some > projects have weekly (or monthly) newsletters where someone "in the > know" compiles a list of what's been going on. I don't have time to do > that, though, do you? :-) I'm not sure I'm "in the know", but if we could get some of the really "in the know" people to agree to get in contact with me (or not be annoyed if I bug them via mail/chat) I'll be up for that one as well. I love compiling info like that actually, I'm just not sure if my writing skills are worthy of an official news section. Let me know what you think and thanks again for replying. Oh and don't worry about the cynicism, I guess you just reap what you sow ("gibberish" ;o). Cheers, Christian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Laurence Rowe
|
In reply to this post
by Christian Scholz-2
I've not looked closely at collective.rope, but from what I can tell it
is AT based. With tin you have a single root folder which is linked to a table. The content objects in this folder are read from the database rows. These content objects may themselves be folderish, containing objects in another table linked by a foreign key. There is support for versioning and workflow in the database for these obejcts, and some support for deletion (by setting a deleted flag on the row) and the ability to poll the database for new content and index it into the plone catalogue. If you get stuck, give me a shout. I would imagine performance would be fairly similar as they both use sqlalchemy underneath. Though as tin uses zope schemas, formlib seem a little quicker to generate than AT based ones. Laurence Christian Scholz wrote: > Hi! > > Laurence Rowe wrote: >> Take a look at collective.tin, it's getting fairly feature complete now. >> Basically it lets you build zope3 content types for plone that are >> stored in a folder whose content is a database table. I will finish the >> tutorial at some point, but am in need of good example. > > Godefroid mentioned it and I had a look at collective.rope at the Snow > Sprint. Does tin also provide folderish content? > I will definitely have a look at it. > > Does it make any different in performance? > > -- Christian > > > >> Laurence >> >> Tarek Ziade wrote: >>> 2008/1/30, Christian Scholz <[hidden email] >>> <mailto:[hidden email]>>: >>> >>> > #7: Improve the tabular data story >>> > >>> > Right now, Plone is a great choice for content-centric >>> applications, and >>> > it also have the possibility to integrate with more structured, >>> relational >>> > data via the SQL database adapters. However, most of these >>> solutions are >>> > old — and while they work, Python has acquired a number of great SQL >>> > integration tools in the meantime, SQLAlchemy being the weapon of >>> choice >>> > for most relational-thinking Pythonistas. >>> >>> I wonder if having an SQL story from the ground would also help >>> performance. We recently moved one project which was more DB like from >>> Plone/Zope to Django as we had to import lots of data on a regular basis >>> and Zope was rather slow in doing that (it was an older Zope/Plone >>> though which means a) Catalog might be faster these days but b) more >>> stuff is happening in AT today). >>> >>> I am not sure what Godefroid experienced with collective.rope (an SQL >>> adapter for Zope content) regarding performance but I think he mentioned >>> that it's somewhat faster. Lovely Systems also told us that one of the >>> mistakes from the beginning was to rely on the ZODB (also think of >>> reindexing the Data.fs etc.) esp. with lots of data. >>> So having at least the option to run over SQL would IMHO be a big win. >>> (also politically for some clients who do not like the unknown). >>> >>> >>> +1 >>> >>> for some applications, it is just impossible to use a plain Plone. For >>> example >>> a btree where people can add some content continuously will fail to work >>> properly with very few users (conflicts, then failures). It is *so* easy >>> to put Plone on its knees with Apache AB... :( >>> I need to try RelStorage to see if it's more scalable on this (anyone >>> knows?) >>> (The good thing about this is that the Plone community is very advanced >>> in caching matters ;) ) >>> >>> SQLAlchemy brings ways to work on this but the problem is that right >>> now, for most cases, you will have to write your application in two >>> different flavors depending on the storage you use >>> Either mappings through an orm, either POZOs (Plain Old Zope Objects) >>> >>> ZODB is a great thing, but imho let's build a working group on this >>> topic, driven by people of the Plone community, to see if we can come up >>> with something more scalable. >>> >>> Tres Seaver and Stéfane Fermigier tried some years ago to bind Zope to >>> the Java (JSR 170) content repository tool (JackRabbit - >>> http://jackrabbit.apache.org/) at some sprint but people did not care >>> too much back then iirc. >>> >>> I would be in favor of investigating in this, maybe at Python level >>> first, no Zope, to write a PEP similar to the DB Api, to have a *plone >>> content repository standard* then write some implementation. It could be >>> a very light thing at first, focusing on content repository matters, and >>> based on SQLAlchemy or Storm. >>> >>> That's a big work indeed... >>> >>> >>> ++ >>> Tarek >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
