18 Things I Wish Were True About Plone

[Alexander Limi]

(This is a duplicate of my post at  
http://limi.net/articles/18-things-i-wish-were-true-about-plone - I'm  
including the full text here, to make it easier to quote selective parts  
if you want to add comments or feedback. Thanks! :)

In the interest of furthering discussion about the future of Plone, here  
are some of my personal opinions on things that I'd like to see applied to  
Plone — both the process and the software.

Let me preface this with the obvious disclaimers for the readers that  
aren't intimately familiar with the Plone community and culture:

     * This is my personal list, and doesn't necessarily reflect what the  
Plone Community wants to do.
     * Even though I work at Google, there's nothing here that constitutes  
knowledge of any secrets about future products. Any mention of Google here  
is as an outsider looking in, as I don't work in the below mentioned focus  
areas — and have no insights into what they are up to next.
     * Some of these are confrontational, some are not — they are all here  
to stimulate discussion, and not to imply failure or dissatisfaction in  
any of the areas. The Plone community is a fantastic community exactly  
because we can have these sorts of discussions out in the open without  
people taking it personally.
     * Make no mistake — we are also a leader in a lot of the areas  
mentioned — I'm just making sure we keep pushing the curve and continue  
delivering the best damn content management system on the planet.

This list is merely a brain dump meant to inspire and provoke discussion  
in the days leading up to the Plone Strategic Planning Summit at the  
Googleplex in February 2008. The discussions there will certainly be a bit  
more high-level than what I talk about below, but this is a good chance  
for you to read about some of the baggage I will bring to the summit — as  
well as add your own views to the discussion so we can make note of them.

With that out of the way, get a cup of your favorite beverage, and let's  
move on to the list! These are in no particular order, but I numbered them  
to make it easier to keep track of how far along you are in the document.

    ________________________



#1: Simple development should be possible entirely through the web  
interface

For those of you familiar with Zope, this point can be summarized as  
“Deliver on the promise of ZClasses”. Yes, I said ZClasses. For those of  
you unfamiliar with Zope, ZClasses is an old — and now frowned-upon — part  
of Zope that allows you to construct content types entirely through a web  
interface. It is what I usually refer to as the “gateway drug” of Zope.  
Most people that got into Zope in the beginning did so especially based on  
what ZClasses were supposed to deliver.

Of course, history shows that this didn't really work out, as there was no  
transition path from clicking around and making your own simple type  
definitions, and then move to more advanced programming later on. With  
Zope 3 and the tools we now have at our disposal, it's time to revisit  
this notion, since we can pull it off without any serious drawbacks this  
time around.

The path to get started with Plone should be:

    1. Install Plone, change options and settings to your liking, add  
simple types for the main business processes you want to mimic — all using  
the web interface.
    2. When you have the need for more advanced types — or just want to  
make sure the setup is repeatable and possible to check in to a code  
repository or a product: click a button → get a filesystem-based product.
    3. Once you are comfortable with the architecture and general approach,  
you can continue doing the rest using a filesystem-based approach to  
development.

I know Martin Aspeli has done a lot of thinking around this, and has a  
proposal based on Zope 3 technologies ready, so I think this is already in  
good hands — but worth exploring and giving feedback on. My major goals to  
ease the approachability of Plone is to be able to solve the following  
common tasks using this solution:

    1. Create simple types — then serialize (and diff) to an FS product
    2. Change setup and configuration — then serialize (and diff) to an FS  
product
    3. Create user properties — then serialize (and diff) to an FS product

Zope is one of the few systems that can do this, and we should exploit it  
for what it's worth. The ultimate step is always filesystem-based  
development, but the goal is to be able to do all the simple things  
without programming — and then be able to dump to file system when you are  
ready to take it to the next level.




#2: Themes should not require Plone-specific knowledge

There are several reasons why there aren't a lot of high-quality themes  
available for Plone. Most of it is a reflection of the fact that Plone is  
a more sophisticated solution that tends to have paying customers and  
businesses as a core audience. Obviously, this isn't conductive to a lot  
of themes in the same way that for example blogging software like  
WordPress — simply because companies and organizations pay a lot of money  
for their designs, and don't want other web sites looking like their site.

The other reason is that it currently requires a lot of CSS knowledge to  
work with Plone to produce a theme that will be maintainable as well as  
being future-proof. Separating the theme layer from the main templates in  
a way that makes it possible to hand a template to a web designer  
independently of Plone is what we have always wanted to do.

This reality is getting closer with the arrival of Deliverance, an  
approach that makes a separate “theme layer” that is independent of Plone,  
and can be worked on without having any knowledge about how Plone works.  
Deliverance is currently being used by several sites, and is maturing  
rapidly due to the great work of Paul Everitt and the OpenPlans Team. I  
believe having Deliverance — or something similar — as part of the Plone  
core would be a sensible and game-changing move, provided it can deliver  
on its promises.

Again, this is something that I believe is in good hands, but needs  
shepherding, cheer-leading and feedback to make sure we make it as simple  
as possible to put your own look on Plone.





#3: Fantastic searching/grouping/batching operations for content should be  
accessible to everyone

The best way to sum this up for those of you who are familiar with Plone  
already would be Collections on steroids. There is a real need to organize  
and group content in Plone in various ways, and the current Collection and  
search implementations in Plone barely scrapes the surface of what we're  
capable of in this area.

     * The first step would be to mimic a slice/dice interface that all  
Plone developers are intimately familiar with: the Trac search. For those  
of you unfamiliar with Trac, it looks a lot like the Smart Folders in Mac  
OS X. The goal would be to offer similar query — and especially grouping —  
abilities in the core Collection type and also the advanced search form.  
This alone would make Plone a fantastic tool for content management.
     * Assigning metadata to items in a collection of content — be it  
permanent or temporary — should be possible for all content. Construct  
your collection of content using the search/grouping interface and then  
apply tags, expiry dates and contributor metadata to it is a necessity. I  
cannot stress this enough.
     * Another related quick fix would be to treat CSV as a first-order  
citizen for export/import of data — especially in Collections and  
users/groups — as well as wherever else data comes in a tabular format.  
CSV is the lingua franca of structured data and data  
manipulation/exchange, and we're not exposing this in Plone at all right  
now. Since Python has great libraries for handling CSV data, it's time we  
start using them.
     * In the same vein, faceted browsing of the search results to make it  
easy to narrow down the result set. This is essentially the same back-end  
with a slightly different UI on top.





#4: Rich media should be a seamless part of the Plone Experience

One of the major growth areas we see in the Ploniverse is the need to  
handle rich media in a graceful and elegant way. Audio and video data in  
particular, but also interactive media like Flash.

This presents a number of challenges on both the front-end and back-end:

     * On the back-end: Seamless and efficient storage of large files (aka.  
“BLOBs”), and performance in serving up these without using too much  
memory or CPU on the server side
     * On the front-end: Easy upload of a large number of files, as well as  
playback and dedicated view modes for audio, video and picture collections.

The back-end part of this equation has received a lot of attention lately,  
with Zope 2.11 shipping with native BLOB support that massively improves  
the memory and storage requirements as well as the performance of serving  
up large files. On the Plone side, Andreas Zeidler has done an amazing job  
and created an implementation that makes this available on the Plone side  
of things, and this work is scheduled to land in Plone 4.0.

On the front-end, projects like Plone4Artists have explored a number of  
different approaches to handling these types of data in Plone, and there  
are several important lessons to learn there.





#5: Unified install experience (no, really!)

Plone already has the best install experience of any content management  
system — it's really the Gold Standard in how easy you can make it to get  
started with such a sophisticated framework across all the major  
platforms. So why do we need to change it? The reason is simple: recent  
progress towards integration and unification with the Python world —  
especially eggs (similar to JAR files for those of you from the Java  
world) — necessitates some improvements here.

The current situaton is also that we have three separate cores of the  
installers, one for each of Windows, Mac OS X and Unix/Linux. The more we  
can share between these implementations, the easier it becomes to release  
software as well as troubleshoot problems regardless of what platform  
people are on.

Steve McMahon and Kamal Gill have done great work done on updating the  
Unified Installer to be egg-based recently, which lays most of the  
groundwork in getting the Windows and Mac OS X installers to use the same  
infrastructure. I want to make sure Windows is not left behind, as this is  
a very common evaluation platform for Plone — even if people end up  
installing it on Linux/Unix-based platforms when it goes into production.

However, I want to take this further, and think about the next steps in  
both initial install experience, upgrade experience, and how to install  
add-on products. Going into great detail on this would necessitate an  
entire document in itself, but I'll list my current brainstorming notes in  
this area. If you have any feedback on this, please help out, these are  
loosely joined ideas that may or may not make sense — or even be realistic:

    1. Install Plone/Zope in a consistent way that is 100% insulated from  
other changes to the system Python and other Plone/Zope instances on the  
system.
    2. Install add-on products without having to do the  
download/unpack/locate directory dance. One way to do this would be to let  
“known good” projects be installed using the web interface, others might  
require server access. “Yes, I have a backup” button when installing.
    3. Ability to ask questions during install — before the add-on product  
gets installed. In a lot of cases, this will influence how the add-on is  
installed and set up.
    4. Ability to ask questions during upgrades: “We changed the default  
policy for X to do Y, but unless you want us to change your default  
setting, we will leave it the way it was.”
    5. Show an indicator on whether we consider it safe to upgrade to the  
next available version X of Plone, based on the dependency information  
listed in the currently installed eggs — ie. if all add-on products say  
they work with the next version of Plone, tell the user this. If not, let  
him know which ones don't have support yet.
    6. Is it possible tocreate a roll-back mechanism to downgrade installs  
in case add-ons screw something up? Yes, you should always have backups,  
but it would still be a great addition that would alleviate a lot of  
nervousness on behalf of the site admin.
    7. An easy way to clone your production instance to a development  
server.
    8. Upgrade Plone/Zope using the web interface with just selecting to do  
so — ask for backup locations, etc.
    9. Make the installer more like a "network installer" — ie. comes with  
the core, and then gets the relevant eggs online. Could even check for  
newer versions when you run it, and ask if you want the newer version  
instead. Minimizes the initial download, and makes it easier to handle  
release files. The role of the installer: set up a sane, insulated  
environment with Python + easy_install that works!
   10. Andy McKay had a great idea of super-simple, standalone ZPT-based  
(not Zope!) application to replace the Plone Controller — making it  
cross-platform. Upgrade options, test running and so on could also be  
added here.





#6: Focus on a culture of systematic benchmarking and performance tuning

Like in Alcoholics Anonymous, the first step to healing is to realize that  
you have a problem. Unoptimized Plone sites tend to be quite slow, and  
while there are numerous ways to make them go faster, they all require  
additional knowledge from the integrator. We can do a lot with a little  
investment here, as earlier optimization efforts has shown. We need to get  
rid of the attitude that “there's not much we can do about performance,  
Plone is a bit slowe since it does so much for you”. Every single time we  
have examined this, there are huge wins to be had on a number of levels.

The complimentary side of this is to establish a nightly testing  
framework, in the same manner we already run automated, comprehensive code  
tests every night. Knowing when something started being slower is just as  
important as speeding up things — especially since we rely on the combined  
stacks of CMF, Zope and Python. A small screw-up can have massive  
consequences for us, and it can be hard to track down what changed. If you  
have a day-to-day log of some central performance statistics, you can  
narrow this down to specific changes — both upstream and in Plone itself.

Some of the things we can do:

    1. Nightly speed benchmarks (we want to know when code was added that  
made things slower)
    2. More analysis on where the CPU time goes — will need Zope gurus  
here, as it's very opaque to analyze at the moment, we tried this with  
Mike Solomon (Python performance guru at YouTube), and it's really hard to  
know what the components are for an outsider — even for our seasoned,  
battle-scarred Plone veterans.
    3. Graph dependencies in an attempt to clean up code and make things  
simpler. The current inheritance trees in Plone + CMF + Zope are quite  
convoluted at times, and there's probably a lot of simplification  
potential here once we see the bigger picture.
    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.

#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 believe this is an important focus area, but since I'm not an SQL guru,  
I'll leave it to others to comment on how this can best fit into the Plone  
experience. I have a related suggestion, though — one that we have been  
kicking around for quite a while at various sprints and workshops, but  
never had time to look into:

I want us to have a simple “Grid” type as one of the core Plone types.  
Looking at the average user, they usually reach for a spreadsheet not when  
they need calculation abilities — but when they need something that looks  
tabular. Week plans, project planning and overviews — all very structural  
data. Of course you can do this in a table in a normal HTML page, but  
that's not how people think.

The Grid type wouldn't even have to have any spreadsheet-like properties  
included — as long as it could deal with text input in tables and do some  
rudimentary operations — like import/export CSV, and possibly feed other  
parts of the system with the data. This would be the perfect back-end for  
things like polls, questionnaires and other similar applications. You  
could then export the data as CSV for specialised handling and  
analysis/graphing, if needed. Of course, using the Chart API from Google  
would be an easy way to provide an optional graphing capability if your  
data is public. But I assume I'm a bit biased in this area.

Whether this would be backed by something like SQLite with the ability to  
scale up to another SQL database as the storage later — or simply be a  
basic type — I'll leave for the people with that kind of experience to  
decide. In any case, a Grid type would fill a real need in the current  
Plone line-up.





#8: Unify similar concepts

Programmers often have a tendency to abstract away things until they are  
almost unrecognizable, to the great frustration of UI designers  
everywhere, of course. Making things too generic makes it hard for people  
to recognize patterns and makes it harder for them to let the tool guide  
them in what they want to do. However, the opposite tendency is also very  
much prevalent, and leads to a lot of redundant implementations, and  
confusion in what add-on products to use.

Building a unified back-end for some central application structures would  
make it easier to maintain an infrastructure that is well-tested,  
performance-audited and maintained. I won't go too far into this, since  
it's way outside my league, but some suggestions for common applications  
that could share APIs and implementations — but have different user  
interfaces to fulfill the specific needs — are:

     * Ratings, comments, forums, mailing lists
     * Blogs, feeds, mail-in support, mail-out support, newsletters

These could even ship with the core, but be deactivated by default. But I  
know I'm pushing it here — and I'm also tackling another element of this  
in a later point — so I'll leave it as an exercise for the reader to help  
identify clusters of similar functionality.





#9: Provide a fantastic page compositing story

At the moment, there are several page compositing add-ons available for  
Plone. None of them make for a fantastic experience in creating pages that  
are composed of other pages, listings and resources — but it's one of the  
most important focus areas for Plone 4.0. If I had my way, the user would  
never have to think about abstract concepts like viewlets, portlets,  
listings and content — the approach would be the same for everything.

Like the unified installation area, this is highly complex and could fill  
a document by itself — but I wanted to have a placeholder here, so we can  
discuss the current approaches and where to go in Plone 4.0. Hopefully  
this will be where I get to spend most of my development time for the 4.0  
release.
#10: Content re-use is overrated — people like folderish

This is a personal pet peeve, but since I said I would include some  
confrontational issues for discussion… ;-)

There are absolutely user stories where content re-use is important, but  
those tend to be highly specialized cases, not the common case. Example:  
why isn't an Event folderish? How about a Page? You can always find them  
later, and Plone's built-in Link Integrity will stop you from doing stupid  
things like deleting content that is referenced elsewhere. There might be  
technical reasons why we're not doing this — and if there is, I'd like to  
hear them.

Note: I'm not advocating using File field/widgets, which I agree are an  
abomination in most cases. I want to be able to add resources inside a  
content item, though. The simple reason is: that's how people think, and  
we'll have to build around that notion, at least for the basic  
functionality. Combined with our powerful search capabilities, this is a  
problem I'm confident we can provide an elegant solution for.





#11: Take project workspaces seriously

Plone is an ideal platform for highly collaborative work, and we have been  
improving this story over the years. Organizations like OpenPlans have  
also done a lot of great exploratory work in this area. It's time to bring  
some of that hard-earned knowledge into Plone proper. Using an approach  
similar to what Martin Aspeli has created with his b-org add-on, it should  
be possible to offer simple, compelling and efficient project workspaces  
without adding a lot of complexity or code.





#12: Increase efforts on plone.org

The situation of plone.org is familiar to anyone that runs a successful  
company: Who has time to update and improve the company web site when  
business is doing so well? The same goes for the plone.org web site — most  
of our developers and integrators are busy and happy working on client  
projects. However, without a major facelift for our communal property, we  
aren't doing Plone real justice.

Some things I believe we need to tackle are:

     * Performance tuning — currently, nobody has time to look into tuning  
the setup so it scales better. Currently, it's a bit painful to use as a  
logged-in user because of the delays. This is to be expected with our  
growth, but that doesn't mean we shouldn't fix it.
     * More functionality for community input — we need ratings on  
everything, but especially add-on products.
     * Identify documentation leaders — at the documentation sprint, we put  
in place the framework and social notion of people having responsibility  
and oversight of certain areas of the documentation (e.g. LDAP  
integration). This needs to be put into action, and a consolidation effort  
for the documentation needs to happen as soon as possible.
     * OpenID support everywhere — yes, especially in things like the issue  
tracker. Make it easy for casual observers to comment and interact without  
creating new accounts. Since Yahoo, Google and others are currently adding  
OpenID support to various services, everyone will soon be able to use this.
     * Sell Plone better — The web site needs to sell Plone better, both in  
prose and design. The marketing committee and the Strategic Planning  
Summit are gearing up to address these issues.
     * Make it easy to translate web site content — This is on our more  
long-term radar, LinguaPlone could be used for this already, but it's  
important to have a good workflow and process around this, so translations  
aren't outdated when content changes. Expect it to take a while, but make  
sure you help out in finding the right balance of convenience and  
structure. Plone is successful on an international scale, our web site  
should be too!





#13: Lower the Migration barriers from other systems

If we can make it easier to upgrade from other systems to Plone, our  
adoption will increase. Migration is a complex thing, and can never be  
100% automated, but there are a number of things we can do to make it  
possible for people to receive the Plone goodness even if they started out  
on a different platform:

     * A robust XML export/import strategy — GSXML seems to be the best  
option I have seen so far, but figuring out what to standardize on, and  
have one solution that we recommend will make things much easier.
     * Share migration scripts — even if what you did was a horrible hack  
to get that Sharepoint content into Plone, share it! Over time, people can  
improve and contribute back to these scripts, and people who are  
considering a migration have some hard-won knowledge to start off with.
     * Support common markup formats from other systems — The classic case  
here is people who install MediaWiki, and then discover “you know, having  
a bit more granular security would be nice”. Having optional markup  
modules available so people can stick with what they know will increase  
the chances of them migrating upwards on the food chain.





#14: Realize that web publishing isn't our main arena

Another slightly controversial idea. I'm not saying that we should ignore  
simple web publishing — simply that it's not an area we will ever be a  
dominant player in — and we're not trying to be. A great static deployment  
story will help tremendously here, but there are several factors that will  
always make us more of a fringe player in the brochureware corporate web  
site / blog arena:

     * PHP systems will always win in pure numbers from pure widespread  
hosting availability.
     * Plone is massive overkill for a simple web site.
     * Software-as-a-Service providers like Google and others will also  
take on this area — and win.
     * It's where the volume is, but not where money and talent is. We do  
money and talent better than volume. ;-)

In my opinion, we should focus our efforts in the areas where we are  
already doing really well:

     * Intranet deployments for companies and organizations.
     * Highly collaborative workspaces with sophisticated security  
requirements.
     * Document management.
     * …and numerous other specialized fields.





#15: Let Favorites come back — in a big way

Early versions of Plone had the notion of “Favorites” — a way to bookmark  
content that was useful to you in a particular Plone site. This  
implementation unfortunately was very basic, so it didn't get much use  
among the power users, and it never got much maintenance or improvement.  
Later on, it was dropped, since nobody was willing to maintain it, and it  
really didn't do much anyway.

I'm bringing sexy back — uhm, I mean…Favorites back. There are a number of  
great uses for this feature outside of a simple list of documents, as  
witnessed by many an inflated web startup over the last few years. I'd  
like us to bring back new, improved favorite support in Plone. Some ideas  
for cool things we can do with these:

     * Use Gmail's “Star” concept to make an efficient, simple UI to mark  
content for later retrieval.
     * Dashboard portlets with your favorites.
     * Let the number of "stars" on a document imply things about its  
ranking in search results. As del.icio.us shows, this is a great indicator  
of popularity.
     * Introduce the "follow" concept from Twitter to Plone — “star” users  
like content — and be able to follow their updates and additions in the  
site. Dashboard portlet to list these, with RSS support.
     * The favorite marker can mark content to be available offline via  
plugins like Google Gears
     * …and I'm sure you have other great examples.





#16: Improve desktop integration

Plone is already far ahead of its competitors in this area, thanks to the  
tireless efforts of Enfold Systems on the Windows side of things with  
Enfold Desktop. There's still a lot of challenges here, and some specifics  
I'd like to discuss are:

     * Can we extend this kind of functionality to the OS X and Linux  
desktops?
     * Can we publish guidelines that show how to write your add-ons so  
they are friendly to WebDAV and desktop integration?
     * Can we make the Content Type Registries capable of having local  
configuration mappings, so they do the right thing depending on context —  
and make it easy to set up new mappings?
     * Can we make it easy to batch-apply metadata on upload using some  
sort of URL mapping?
     * Can we build a comprehensive test suite to make sure that our  
assumptions don't break when we do changes in the various underlying  
implementations? Can we make it a given that a shipping Plone release has  
working WebDAV integration on all the major implementations — every time?





#17: "Recommended apps" tier

This is more a pie-in-the-sky discussion item. Looking at other successful  
open source communities, it strikes me that Plone has a lot in common with  
how the KDE project manages their platform. They have a core that is  
useful in itself, but also a lot of add-ons that are more or less  
recommended — and the best-of-breed even ship with KDE itself. Working out  
how we can achieve a similar model with cues taken from the earlier point  
on installation capabilities and upgrade/dependency management would be  
very interesting.

There are a number of add-ons that deserve tighter integration (mostly in  
a political sense) with Plone — having recommended solutions for certain  
common add-ons helps the platform in general. We already have some  
projects that in some ways behave like this — LinguaPlone comes to mind —  
but having an accepted process and some guidelines around this is  
something we'll need sooner or later.





#18: Stay hungry/foolish

Plone has always been great at encouraging experimentation and wild ideas.  
I want us to continue doing this, and make it clear that we value it — but  
at the same time let people know that experiments aren't necessarily going  
to end up in the core. Do more experimentation and stuff that has “fun” PR  
value — things like iPhone support and social network features are  
relevant contemporary examples.

    ________________________


What's on your list? What are the things you'd like to see Plone focus on?  
Do you have comments or suggestions on any of the above points? Leave a  
comment on the mailing list, or blog about your own list!

Thank you for your attention. It's truly an exciting time in the Plone  
world.

--
Alexander Limi · http://limi.net


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

[Graham Perrin]

Alexander Limi wrote:

What's on your list? What are the things you'd like to see Plone focus on? Do you have comments or suggestions on any of the above points? Leave a comment on the mailing list, or blog about your own list!

Speed-reading #1 to #18 there's nothing with which I disagree. Nice :)

One comment, and one suggestion...


1) Ratings by the community

> More functionality for community input — we need ratings on everything, but especially add-on products.

Agreed, but I would be wary of inviting community rating of add-on products too soon. First, solidify:

a) related works in progress e.g. <http://plone.org/documentation/tutorial/third-party-products>

b) wishes, such as <http://limi.net/articles/18-things-i-wish-were-true-about-plone> #5 point 2

— so that people better understand (or are shielded from) the whole product installation caboodle, and so that misunderstandings don't lead to inappropriate product ratings.

In the meantime: it's great that for most add-ons, there's an issue tracker within the plone.org area. This makes Googling etc. easier.


2) State, sharing, roles, permissions, normal workflows in Plone, plus additional workflows, roles and states for some add-on products

I wish for there to be: an easier, more Plone-ish (less ZMI-ish) route for _newcomers_ to learn/discover:

a) the effect and importance of workflows
b) how state, sharing, permissions, workflow local roles and global roles 'fit' together.

Out of the box: Plone's most up-front expressions are

* State (menu)
* Sharing (tab)

but the workflow-related stuff that novice administrators really need to get their heads around is in ZMI, and in various online articles.

At <http://plone.org/documentation/how-to/new-workflows-in-plone-3>

> The best way to get to know any workflow is to test it with different user profiles, each granted a specific role(s) on the site. When you first install Plone you start by having a single "admin" user profile.

I'm very much in favour of learning by doing/testing/experimenting (and that's a great how-to), but I'm not convinced that testing is an ideal introduction to workflows etc. in Plone.

If you're already familiar with Zope and Plone, then learning through testing may be ideal; but if you're new to Plone, then there may be a great deal of new learning and un-learning to do.

Regards
Graham

[Tannic]

Wow... I couldn't agree more with most of this but #1, #6 and #15 really stand out as amazing thoughts that the Plone community should take seriously.

A lot of it looks exactly (although better stated) what I put in the Plone Survey and hopefully others have as well.

[yvesm]

> #7: Improve the tabular data story
...
>
> I want us to have a simple "Grid" type as one of the core Plone types.


ASPX has had a DataGrid control for a long time.  People working with
relational data in the .NET world use that control all the time.  A
"grid" type would be useful to folks using Plone in scientific
communities.  Once upon a time, I made a product deriving from a
PrimaGIS class to gather water quality data from in situ sensors.  A
"grid" type would have been useful.  

If such a type were made available, it must be easy to order data in
ASC/DESC order on *any* column.  IMO, it would almost be a must to be
able to style table elements as a function of some content value. An
example : I have a table in which I have pH values.  How can I apply a
rule so that values x1 < x < x2 are in a certain
font/color/whatever-style-attribute ?  The rule should be applicable on
the fly (TTW, that means) so that values can be styles according to the
rules of organisation A or B, for example.

> The Grid type wouldn't even have to have any spreadsheet-like
properties  
> included -

At least rudimentary spreadsheet would be welcome.  People looking at
data *always* want to have basic descriptive stats (sums, max, etc.).  I
know there are some JS libraries out there.  I saw one that is being
developed for the XO (OLPC) and I'm sure there are others.  It could be
just selecting values in a column and a "stats portlet" would fill up ?

> ... an easy way to provide an optional graphing capability if your  

I believe that would be a complement to basic spreadsheet capabilities
(Google for my desire to try and hook matplotlib to Plone in the past),
though that is probably less common a requirement than basic descriptive
stats.  Being able to easily spit the data out in CSV format so people
can bring the data to appropriate plotting software could be enough but
a OOTB minimalistic plotting capability would be a potential cool factor
(although it could be come a negative point if it does not work well
...)

Thanx for requesting comments and happy summit :-)

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

[Alexander Limi]

Thanks for your feedback!

On 1/30/08, Moisan Yves <[hidden email]> wrote:

>
>
> Alexander Limi a écrit :
>
> > #7: Improve the tabular data story
> ...
> >
> > I want us to have a simple "Grid" type as one of the core Plone types.
>
> ASPX has had a DataGrid control for a long time.  People working with relational data in the .NET world use that control all the time.  A "grid" type would be useful to folks using Plone in scientific communities.  Once upon a time, I made a product deriving from a PrimaGIS class to gather water quality data from in situ sensors.  A "grid" type would have been useful.
>
> If such a type were made available, it must be easy to order data in ASC/DESC order on *any* column.  IMO, it would almost be a must to be able to style table elements as a function of some content value. An example : I have a table in which I have pH values.  How can I apply a rule so that values x1 < x < x2 are in a certain font/color/whatever-style-attribute ?  The rule should be applicable on the fly (TTW, that means) so that values can be styles according to the rules of organisation A or B, for example.
>
> > The Grid type wouldn't even have to have any spreadsheet-like properties
> > included -
>
> At least rudimentary spreadsheet would be welcome.  People looking at data *always* want to have basic descriptive stats (sums, max, etc.).  I know there are some JS libraries out there.  I saw one that is being developed for the XO (OLPC) and I'm sure there are others.  It could be just selecting values in a column and a "stats portlet" would fill up ?
>
> > ... an easy way to provide an optional graphing capability if your
>
> I believe that would be a complement to basic spreadsheet capabilities (Google for my desire to try and hook matplotlib to Plone in the past), though that is probably less common a requirement than basic descriptive stats.  Being able to easily spit the data out in CSV format so people can bring the data to appropriate plotting software could be enough but a OOTB minimalistic plotting capability would be a potential cool factor (although it could be come a negative point if it does not work well ...)
>
> Thanx for requesting comments and happy summit :-)
>
> Yves
>
>
>

--
Alexander Limi · http://limi.net
-------------------------------------------------------------------------
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]

Moisan Yves wrote:

>
>
>> #7: Improve the tabular data story
> ...
>> I want us to have a simple "Grid" type as one of the core Plone types.
>
>
> ASPX has had a DataGrid control for a long time.  People working with
> relational data in the .NET world use that control all the time.  A
> "grid" type would be useful to folks using Plone in scientific
> communities.  Once upon a time, I made a product deriving from a
> PrimaGIS class to gather water quality data from in situ sensors.  A
> "grid" type would have been useful.  
>
> If such a type were made available, it must be easy to order data in
> ASC/DESC order on *any* column.  IMO, it would almost be a must to be
> able to style table elements as a function of some content value. An
> example : I have a table in which I have pH values.  How can I apply a
> rule so that values x1 < x < x2 are in a certain
> font/color/whatever-style-attribute ?  The rule should be applicable on
> the fly (TTW, that means) so that values can be styles according to the
> rules of organisation A or B, for example.
>
>> The Grid type wouldn't even have to have any spreadsheet-like
> properties  
>> included -
>
> At least rudimentary spreadsheet would be welcome.  People looking at
> data *always* want to have basic descriptive stats (sums, max, etc.).  I
> know there are some JS libraries out there.  I saw one that is being
> developed for the XO (OLPC) and I'm sure there are others.  It could be
> just selecting values in a column and a "stats portlet" would fill up ?

I wander if the ExtJS grid component could be utilized for this? See
http://extjs.com/what-ext-javascript-library-all-about

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

[Christian Scholz-2]

Limi, great post! :-)

I think I mostly agree with those things, here are some remarks.

> #1: Simple development should be possible entirely through the web  
> interface

Indeed we need this as it makes us sorta unique. And of course we
shouldn't do the same mistakes as ZClasses did in which you had to start
all over in learning once you switched from ZClasses to the FS.

The question is of course how to implement it best, as some
import/export with merging/rundtrip or simply a view on the filesystem.

> #6: Focus on a culture of systematic benchmarking and performance tuning
>
> Like in Alcoholics Anonymous, the first step to healing is to realize that  
> you have a problem. Unoptimized Plone sites tend to be quite slow, and  
> while there are numerous ways to make them go faster, they all require  
> additional knowledge from the integrator. We can do a lot with a little  
> investment here, as earlier optimization efforts has shown. We need to get  
> rid of the attitude that “there's not much we can do about performance,  
> Plone is a bit slowe since it does so much for you”. Every single time we  
> have examined this, there are huge wins to be had on a number of levels.

I think one of the main problems is also when adding data to the system.
On reading you can do caching but the other way round that's no option.

>     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.

bullschit and gibberisch indeed looked very neat :-)

> #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).

Another positive thing about SQL is (as long as you don't simply store
pickles in it) that you can access the raw data in simple Python scripts
and do not have to start a whole class hierarchy just to add some values
inside a cronjob.
Downside is of course schema evolution etc.

> #8: Unify similar concepts
>
> Programmers often have a tendency to abstract away things until they are  
> almost unrecognizable, to the great frustration of UI designers  
> everywhere, of course. Making things too generic makes it hard for people  
> to recognize patterns and makes it harder for them to let the tool guide  
> them in what they want to do. However, the opposite tendency is also very  
> much prevalent, and leads to a lot of redundant implementations, and  
> confusion in what add-on products to use.
>
> Building a unified back-end for some central application structures would  
> make it easier to maintain an infrastructure that is well-tested,  
> performance-audited and maintained. I won't go too far into this, since  
> it's way outside my league, but some suggestions for common applications  
> that could share APIs and implementations — but have different user  
> interfaces to fulfill the specific needs — are:
>
>      * Ratings, comments, forums, mailing lists

We already discussed doing trackbacks and comments with the same
mechanism. This of course should also be useful for forums. Not sure
about ratings but maybe this aswell. Depends on how we factor things out
I guess.

>      * Blogs, feeds, mail-in support, mail-out support, newsletters

Here it certainly makes sense to have e.g. email subscriptions available
not only for one type of thing (e.g. a blog) but as a general solution.
I guess events are the key here.

> These could even ship with the core, but be deactivated by default. But I  
> know I'm pushing it here — and I'm also tackling another element of this  
> in a later point — so I'll leave it as an exercise for the reader to help  
> identify clusters of similar functionality.

I think this will get clearer while implementing it if you have this in
mind.

> #9: Provide a fantastic page compositing story
>
> At the moment, there are several page compositing add-ons available for  
> Plone. None of them make for a fantastic experience in creating pages that  
> are composed of other pages, listings and resources — but it's one of the  
> most important focus areas for Plone 4.0. If I had my way, the user would  
> never have to think about abstract concepts like viewlets, portlets,  
> listings and content — the approach would be the same for everything.

I am actually wondering if we need all those types. Most of the times I
guess a user does not really know whether he now wants an event, news or
a page.

> #10: Content re-use is overrated — people like folderish

Actually I am not sure I get this point ;-)

> #11: Take project workspaces seriously
>
> Plone is an ideal platform for highly collaborative work, and we have been  
> improving this story over the years. Organizations like OpenPlans have  
> also done a lot of great exploratory work in this area. It's time to bring  
> some of that hard-earned knowledge into Plone proper. Using an approach  
> similar to what Martin Aspeli has created with his b-org add-on, it should  
> be possible to offer simple, compelling and efficient project workspaces  
> without adding a lot of complexity or code.

This would maybe also enable some social networking features as
described in the other post. Add relations between users, maybe local
groups (friends, family, co-workers) to each user and we'd have a simple
social networking layer (or project workspace layer).
This might also help with the bookmarking stuff as you can search for
bookmarks of your friends etc.

> #12: Increase efforts on plone.org
>
> The situation of plone.org is familiar to anyone that runs a successful  
> company: Who has time to update and improve the company web site when  
> business is doing so well? The same goes for the plone.org web site — most  
> of our developers and integrators are busy and happy working on client  
> projects. However, without a major facelift for our communal property, we  
> aren't doing Plone real justice.

Some ideas I had:

- cleanup the frontpage. It's the landing page and there is no clear
call to action. If you look on other sites you usually see 3 main things
there: Download, Demo/Screenshots, Features. I think the features could
really just be a second page.
- move the links from the top to the bottom (a la flickr sitemap).
People who want to get involved will find them. People who come there
for the first time do not really need them at that stage.
- Move news into a more visible area (maybe make it all one list in one
sidebar).

Just some ideas. Maybe it's also not that clear how people can get
involved in working on plone.org.

>      * OpenID support everywhere — yes, especially in things like the issue  
> tracker. Make it easy for casual observers to comment and interact without  
> creating new accounts. Since Yahoo, Google and others are currently adding  
> OpenID support to various services, everyone will soon be able to use this.

Actally I would like to have a new account but one I can login with
openid. Maybe being able to add multiple openids to one account is also
good. A good story so far has IMHO ma.gnolia.com.
So in fact it would create an account on the fly.

> #15: Let Favorites come back — in a big way
>
...

>
>      * Use Gmail's “Star” concept to make an efficient, simple UI to mark  
> content for later retrieval.
>      * Dashboard portlets with your favorites.
>      * Let the number of "stars" on a document imply things about its  
> ranking in search results. As del.icio.us shows, this is a great indicator  
> of popularity.
>      * Introduce the "follow" concept from Twitter to Plone — “star” users  
> like content — and be able to follow their updates and additions in the  
> site. Dashboard portlet to list these, with RSS support.

One might also think of a search which takes content rated by your
friends with more weight than other content. So in fact we'd need some
sort of relationship between users.

>      * The favorite marker can mark content to be available offline via  
> plugins like Google Gears
>      * …and I'm sure you have other great examples.
>
>
>
> #17: "Recommended apps" tier
>
> This is more a pie-in-the-sky discussion item. Looking at other successful  
> open source communities, it strikes me that Plone has a lot in common with  
> how the KDE project manages their platform. They have a core that is  
> useful in itself, but also a lot of add-ons that are more or less  
> recommended — and the best-of-breed even ship with KDE itself. Working out  
> how we can achieve a similar model with cues taken from the earlier point  
> on installation capabilities and upgrade/dependency management would be  
> very interesting.
>
> There are a number of add-ons that deserve tighter integration (mostly in  
> a political sense) with Plone — having recommended solutions for certain  
> common add-ons helps the platform in general. We already have some  
> projects that in some ways behave like this — LinguaPlone comes to mind —  
> but having an accepted process and some guidelines around this is  
> something we'll need sooner or later.

We discussed this a bit during the SnowSprint. We are living in an
attention economy and thus "being part of the core" might mean lots more
than just being one addon among others. Of course not everything can be
in the core though. While we moved in our devel process to some point in
which things aren't added without reason (I hope ;-) ) it might make
sense to give credits to people in other ways such as being a
recommended app.

 From a user perspective this is of course also needed as it's usually a
hard task for user X to find the right add-on for his problem.
Experimenting with all the available tools might be a not so fun project.

Enuff said ;-)

-- Christian


--
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: [phone]                           E-Mail [hidden email]
Fax: [phone]                               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

[Ian Bicking]

Alexander Limi wrote:

#9: Provide a fantastic page compositing story

At the moment, there are several page compositing add-ons available for  
Plone. None of them make for a fantastic experience in creating pages that  
are composed of other pages, listings and resources — but it's one of the  
most important focus areas for Plone 4.0. If I had my way, the user would  
never have to think about abstract concepts like viewlets, portlets,  
listings and content — the approach would be the same for everything.

One technique that might be applicable here is Transclusion, which we have implemented in the Deliverance stack at openplans.  With that you just do include content, and it will fetch /some/other/page and put that in place of the link.  You can select a piece of a page with #id.  By combining content and composition I think this makes things a bit more unified.

  Ian

[Martin Aspeli-2]

Laurence Rowe wrote:

> Moisan Yves wrote:
>>
>>> #7: Improve the tabular data story
>> ...
>>> I want us to have a simple "Grid" type as one of the core Plone types.
>>
>> ASPX has had a DataGrid control for a long time.  People working with
>> relational data in the .NET world use that control all the time.  A
>> "grid" type would be useful to folks using Plone in scientific
>> communities.  Once upon a time, I made a product deriving from a
>> PrimaGIS class to gather water quality data from in situ sensors.  A
>> "grid" type would have been useful.  
>>
>> If such a type were made available, it must be easy to order data in
>> ASC/DESC order on *any* column.  IMO, it would almost be a must to be
>> able to style table elements as a function of some content value. An
>> example : I have a table in which I have pH values.  How can I apply a
>> rule so that values x1 < x < x2 are in a certain
>> font/color/whatever-style-attribute ?  The rule should be applicable on
>> the fly (TTW, that means) so that values can be styles according to the
>> rules of organisation A or B, for example.
>>
>>> The Grid type wouldn't even have to have any spreadsheet-like
>> properties  
>>> included -
>> At least rudimentary spreadsheet would be welcome.  People looking at
>> data *always* want to have basic descriptive stats (sums, max, etc.).  I
>> know there are some JS libraries out there.  I saw one that is being
>> developed for the XO (OLPC) and I'm sure there are others.  It could be
>> just selecting values in a column and a "stats portlet" would fill up ?
>
> I wander if the ExtJS grid component could be utilized for this? See
> http://extjs.com/what-ext-javascript-library-all-about

We should use this component. It's incredibly good. I know - I've used
it. :)

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

[Martin Aspeli-2]

Hi Alex,

Long list. :-)

> #1: Simple development should be possible entirely through the web  
> interface

Yep - we want to do this. I'm working on some infrastructure for this,
which should also support other tools like UML-to-content type without
massive pain. It's tricky, though. ;-)

> The path to get started with Plone should be:
>
>     1. Install Plone, change options and settings to your liking, add  
> simple types for the main business processes you want to mimic — all using  
> the web interface.
>     2. When you have the need for more advanced types — or just want to  
> make sure the setup is repeatable and possible to check in to a code  
> repository or a product: click a button → get a filesystem-based product.
>     3. Once you are comfortable with the architecture and general approach,  
> you can continue doing the rest using a filesystem-based approach to  
> development.

I think this is a good principle, although I envisage a spectrum from
completely code-generated (scaffolding/minimal boilerplate) + GUI/TTW
editing, to declarative syntax (think XML file or declarative-looking
python) to full-on Python, with a few steps in-between. I also think it
should be possible to define basic types without being a programmer that
give programmers the hooks they need to add additional behaviour (mainly
through adapters and event handlers). In the context of Zope 3, that

> #2: Themes should not require Plone-specific knowledge

I think the answer here will be to use Repoze and Deliverance (Repoze
being the natural way to wire Deliverance into our stack). However, we
need lots more people using Deliverance - fixing bugs and testing its
limits. I used it for a project and we ended up ditching it due to
quirks and general lack of support. It's missing some critical mass at
the moment, which is problematic, and the development team behind it is
busy (and generally not Plone focused). We should step up and own more
of this infrastructure directly.

> #3: Fantastic searching/grouping/batching operations for content should be  
> accessible to everyone

Yup. For that to happen, we need to ditch the idea that criteria are AT
content types and rethink the data model and query API. Actually, that's
pretty simple and is something that's already been done elsewhere to an
extent (I believe hurry.query has some syntax for this, for example). We
also need to come up with the UI metaphors for batch editing.
Implementing batch editing is not terribly hard, but the UI is dull so
no-one is doing it.

> #4: Rich media should be a seamless part of the Plone Experience

For this, we need blogs (largely there) and again better front-end UI.
Subtyping (ala the P4A audio and video types) is a nice way of
supporting different UI and metadata extraction for various types of
content.

> #5: Unified install experience (no, really!)

We definitely need to unify the install layouts. I believe zc.buildout
is the platform that enables this, and gives us some flexibility in the
future (we can redefine recipes to deal with new conventions and
requirements).

You mention a lot of other stuff here, some of which is in the
hard-to-impossible category. I think it'll take a strong chamption for
this to happen, since it's an area that developers care less about than
end users (sadly).

> #6: Focus on a culture of systematic benchmarking and performance tuning

Again, this needs a champion with time to invest in coming up with the
right strategies, tools and test suites. There are some radical things
we could do (ditch ZPT?), but which are unlikely to happen in the
foreseeable future.

> #7: Improve the tabular data story

I'd keep "tabular" separate from "SQL connections". sqlalchemy (and
collective.lead and friends) give us a nice and easy way to talk to SQL
databases from custom code. I don't think we need to invent more
framework here, just more documentation and examples. We shouldn't
really be in this game since the sqlalchemy goes do it so well.

> I want us to have a simple “Grid” type as one of the core Plone types.  

Yes. :)

We also talked about a "SQL query viewer" type, where the edit tab lets
you type in a query and the view displays the results in a table.

For UI, the Ext AJAX library has a *kick-ass* grid implementation that
we should use.

I think this is imminently doable in a third-party product. It's not
even all that hard. I'd eschew out-there ideas like depending on
sqlalchemy for now - store it in the ZODB in a list of lists or
something. Someone who needs this should build it, and we could
integrate it at a later stage.

> #8: Unify similar concepts

This point is a bit too vague to be useful to me, except as a guiding
principle: find commonalities and factor them out into re-usable
components. Zope 3 helps a lot here, but it's also quite hard to
generalise a lot of things that on the surface seem similar. The devil
is in the details!

> #9: Provide a fantastic page compositing story

Yes, please! This stuff's hard to get right. I'm hoping Malthe's
plone.composition (?) work will come to fruition with some nudging.

I think the hardest part is to come up with a UI that works. If it's
general enough, we can wrap it around existing components (portlets,
viewlets) and more targetted page-composition (as opposed so
site-layout-composition) components.

> #10: Content re-use is overrated — people like folderish

Are you talking about a general "attachments" functionality here? I
think if you made Page act and work much like a Folder, people would be
confused. Logically, they are separate entities, but in Word you can
embed a movie and so you should be able to (via a kupu but also in a
more direct way) add additional binary or text data to various content
types.

Once again, the UI's hard. RichDocument mainly solves this for images
and attachments to pages, but has a suboptimal UI to do it. This
functionality could also be generalised (quite easily) to work on any
type simply by enabling a switch somewhere (portal_types -> Page ->
enable attachments, anyone?)

> #11: Take project workspaces seriously

I think borg.project could do this, maybe with some UI tweaks. I'd like
some opinions on whether it covers all use cases, but it's pretty simple
and extensible.

There are alternatives (Teamspace being the most obvious one), though in
my biased opinion, borg.project is simpler, more of a product and less
of a framework, and more modern.

> #12: Increase efforts on plone.org

This (and documentation review and maintenance) is a big problem - of
manpower and organisation, not a technical one. I used to want to tackle
this, but I simply don't have time to do it properly (and I've done it
badly in the past because of this). I worry that this is a problem of
having to wait for the right person to come along and step up. Wichert
does a great job on the infrastructure side, but can't do everything. On
the documentation side, we have a Documentation Team with all the
goodwill in the world, that unfortunately isn't entirely functional due
to lack of time or expertise or both.

> #13: Lower the Migration barriers from other systems

And *to* other systems. Plone should not be a dead-end for your data.

Again, the import/export story isn't terribly complex and there are
various semi-complete solutions (gsxml, xmlforrest, entransit). This
requires a champion, though.

> #14: Realize that web publishing isn't our main arena

I am not convinced that we are that big a contender in the pure
documentation management space either, but we probably should be.

I really want a Big Green Button in Plone. Click it, and you have a
static copy of your Plone site. Tick an option or two, and you get a PHP
(yeah, you heard me) version that gives you flat content + search. Maybe
PHP + MySQL even, and a simplified skin (that can be themed
independently). That goes on your $5/mo web hosting when you want to use
Plone to *manage content* but ultimately just want to publish it.

We already have solutions here (CMFDeployment, Entransit), but this area
needs a champion who makes it work. It doesn't have to cover every
possible use case, just the most basic ones - it wont' be used by
everyone. Bonus points for a flexible architecture that allows people to
plug in some "transformers" for content or whatever to customise the
outputs.

> #15: Let Favorites come back — in a big way

Having Favourites as a content type (in a magic, semi-hidden folder in
your now-off-by-default user folder) was a problem. Personal starring of
content should be easy to implement (a viewlet, a container for the
ratings, some search functionality, a portlet). It'd be a nice sprint
task, and could be done completely outside the core to begin with.

> #16: Improve desktop integration

I fear this will be hard until a lot more people are using the
DAV/desktop functionality and demanding that it works. We should
definitely try, though. It's a killer feature that sells very well.

> #17: "Recommended apps" tier

I think step 1 here is to sort out plone.org so that we can capture
meatdata like product popularity and "known good" configurations more
easily. Then this should be easier. Like you said, it's 90%

> #18: Stay hungry/foolish

Some of the stuff we put into Plone 3 (viewlets, portlets, more adapters
and events, the ISchema stuff in Archetypes that made
archetypes.schemaextender possible) was aimed at making it possible to
make things that acted as if they were part of core Plone without
actually shipping with the core. We need to take advantage of that more,
and get products reviewed and used in a real-world setting more often
before considering them for inclusion in the core.

> What's on your list?

#19: Revive the Contextual Help efforts

We started this, and need to re-start it - having contextual help (e.g.
in a portlet) available depending on where you are in Plone and what
you're doing.

#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.

#21: Content subscription

It should be possible to subscribe to any content and be notified when
it changes, either in-Plone or via email. This is easy to do and can be
done in a third-party product without touching the core.

#22: Unify the customisation story

Customising Zope 3-like things and CMF layer-like things is different.
The TTW story for Zope 3 browser components is not perfect either. TTW,
this should all be managed via an improved portal_view_customizations
tool, with a better UI, hiding the behind-the-scenes differences. For
filesystem customisation, I'm not sure how easy it'd be to
differentiate, though I hope more stuff migrates to Zope 3 and I hope
something like z3c.jbot makes it easier to customise without having to
look up and replicate ZCML statements.

#23: Take WSGI seriously

One word: Repoze. We need to drive this at the Zope 2 level so that Zope
2 becomes eggs and WSGI and pipelines. If you haven't seen the
reposze.org demos, please do so now.

This will help our integration with other Python web platforms and will
help us push some stuff out of Plone (themeing with Deliverance, say).

Otherwise, I generally agree with everything you said above.

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

[Matt Halstead-3]

On Jan 31, 12:06 am, "Alexander Limi" <[hidden email]> wrote:

>
> #1: Simple development should be possible entirely through the web  
> interface
>

I note you say 'Simple', but I don't know whether I am in the minority
or majority of people who implement plone sites/applications, but my
experience is that plone is a framework for building an application,
rather than an application that is extended and skinned a little out
of the box. Is it the goal of Plone to have an installable application
that really does only need a little tweaking to be useful in most
intended contexts?

In the current scenario of zope 3, the adapter story - or aspect
oriented programming - is the big stick for extending or creating new
behaviour. How does this relate to the zclass idiom? How would someone
program aspects TTW? How would you set up and run test frameworks for
these TTW components?

Is the extension of your story a full-blown TTW plone IDE?

Creating some custom extensions to an existing content type, or
creating new ones based on existing ones would generally require
schema extension, some specific adapter code (both for the schema
extension and for providing useful browser views of the extended
content type), maybe some new catalog indexes, and probably some theme
specific customizations for rendering.

This feels like zopeskel territory to me and the focus should be
getting that story as replete as possible and then perhaps, if really
needed, exposing the knobs of this through various mechanisms.
Archgenxml is one way this is been done, and I'm not too sure there
needs to be another TTW as part of a plone application? Something like
Archgenxml works hard to make the return trip possible(i.e. not
squashing custom code if the UML model is updated), but you're not
suggesting that possibility here. Considering the best way to develop
and deploy a site is using buildout, you'd be wanting to export your
TTW customization on the first tick of a checkbox in some form just so
you could run code tests and deploy your first example.

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.



-------------------------------------------------------------------------
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 Ziade]

2008/1/30, Christian Scholz <[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/
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Ricardo Newbery-2]

On Jan 30, 2008, at 3:06 AM, Alexander Limi wrote:

> #6: Focus on a culture of systematic benchmarking and performance  
> tuning
>
> Like in Alcoholics Anonymous, the first step to healing is to  
> realize that
> you have a problem. Unoptimized Plone sites tend to be quite slow, and
> while there are numerous ways to make them go faster, they all require
> additional knowledge from the integrator. We can do a lot with a  
> little
> investment here, as earlier optimization efforts has shown. We need  
> to get
> rid of the attitude that “there's not much we can do about  
> performance,
> Plone is a bit slowe since it does so much for you”. Every single  
> time we
> have examined this, there are huge wins to be had on a number of  
> levels.
>

Related to this.  I recently did some testing that demonstrated how  
much extra work Plone seems to be doing on content creation,  
especially when portal_factory is involved.  This is probably not  
news to folks here but for a single AT content creation action, I  
counted a total of 39 calls to ZCatalog's cataloging methods  
(catalog_object and uncatalog_object) and a total of 648 calls to  
RoleManager permission change methods (manage_role,  
manage_acquiredPermissions, manage_permissions, and  
manage_changePermisions).  When not using portal_factory these counts  
decreased considerably to "just" 18 cataloging calls and no  
permission changes.

I have no idea how this impacts performance but is there maybe be  
some room for improvement here?

Ric




-------------------------------------------------------------------------
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 Matt,

>> #1: Simple development should be possible entirely through the web  
>> interface
>>
>
> I note you say 'Simple', but I don't know whether I am in the minority
> or majority of people who implement plone sites/applications, but my
> experience is that plone is a framework for building an application,
> rather than an application that is extended and skinned a little out
> of the box. Is it the goal of Plone to have an installable application
> that really does only need a little tweaking to be useful in most
> intended contexts?

I don't think you can support every use case. We'll continue to support
the "near-infinite-customisability" idiom that people now employ when
they use Plone as a platform/framework. However, we'd like to make some
common tasks (create a new type with some fields and configure it) be a
GUI task rather than a programming task, with some smooth(ish)
transition path to when you *do* want to do programming.

> In the current scenario of zope 3, the adapter story - or aspect
> oriented programming - is the big stick for extending or creating new
> behaviour. How does this relate to the zclass idiom? How would someone
> program aspects TTW? How would you set up and run test frameworks for
> these TTW components?

Be patient - we may have some demos in not too long

> Is the extension of your story a full-blown TTW plone IDE?

I doubt we'll ever get there, but a few more tools aimed at integrators
and "light developers" would be nice.

> This feels like zopeskel territory to me and the focus should be
> getting that story as replete as possible and then perhaps, if really
> needed, exposing the knobs of this through various mechanisms.
> Archgenxml is one way this is been done, and I'm not too sure there
> needs to be another TTW as part of a plone application? Something like
> Archgenxml works hard to make the return trip possible(i.e. not
> squashing custom code if the UML model is updated), but you're not
> suggesting that possibility here. Considering the best way to develop
> and deploy a site is using buildout, you'd be wanting to export your
> TTW customization on the first tick of a checkbox in some form just so
> you could run code tests and deploy your first example.

We're looking at solutions complementary to and based on these
technologies, not orthogonal ones. However, if you're a "business user"
with no Python experience, creating a simle new content type in Plone
right now ("I just want a form, really, and some way of storing the
results") is too hard. ArchGenXML is a step in the right direction.
Unfortunately, it's a bit crummy on the inside and it has to do a lot of
acrobatics because the framework it outputs to (Archetypes) wasn't
really designed for this kind of thing in the first place. I'd like
ArchGenXML to be maybe 100 lines of code and an XSLT stylesheet. :)

> 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.

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. :)

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

[Martin Aspeli-2]

Ricardo Newbery wrote:

> On Jan 30, 2008, at 3:06 AM, Alexander Limi wrote:
>
>> #6: Focus on a culture of systematic benchmarking and performance  
>> tuning
>>
>> Like in Alcoholics Anonymous, the first step to healing is to  
>> realize that
>> you have a problem. Unoptimized Plone sites tend to be quite slow, and
>> while there are numerous ways to make them go faster, they all require
>> additional knowledge from the integrator. We can do a lot with a  
>> little
>> investment here, as earlier optimization efforts has shown. We need  
>> to get
>> rid of the attitude that “there's not much we can do about  
>> performance,
>> Plone is a bit slowe since it does so much for you”. Every single  
>> time we
>> have examined this, there are huge wins to be had on a number of  
>> levels.
>>
>
>
>
> Related to this.  I recently did some testing that demonstrated how  
> much extra work Plone seems to be doing on content creation,  
> especially when portal_factory is involved.  This is probably not  
> news to folks here but for a single AT content creation action, I  
> counted a total of 39 calls to ZCatalog's cataloging methods  
> (catalog_object and uncatalog_object) and a total of 648 calls to  
> RoleManager permission change methods (manage_role,  
> manage_acquiredPermissions, manage_permissions, and  
> manage_changePermisions).  When not using portal_factory these counts  
> decreased considerably to "just" 18 cataloging calls and no  
> permission changes.
>
> I have no idea how this impacts performance but is there maybe be  
> some room for improvement here?

Tons!

It got better in Plone 3, though - I'm surprised if those numbers are
from Plone 3? Well, not *that* surprised maybe. ;-)

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.

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

[per9000]

Alexander Limi wrote:
 > [...]
 > #12: Increase efforts on plone.org

Indeed, a slow (and like earlier this week "the parrot is not dead -
it's resting"-slow) plone.org-site is really bad PR.

 > [...]
 > What's on your list?
 > [...]

As a recent (half a year or so) Plone convert I'd say that #1-#18 are
sugar but think you forget the coffee:


#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.

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/
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Ricardo Newbery-2]

On Jan 30, 2008, at 11:54 PM, Martin Aspeli wrote:

> Ricardo Newbery wrote:
>> Related to this.  I recently did some testing that demonstrated how
>> much extra work Plone seems to be doing on content creation,
>> especially when portal_factory is involved.  This is probably not
>> news to folks here but for a single AT content creation action, I
>> counted a total of 39 calls to ZCatalog's cataloging methods
>> (catalog_object and uncatalog_object) and a total of 648 calls to
>> RoleManager permission change methods (manage_role,
>> manage_acquiredPermissions, manage_permissions, and
>> manage_changePermisions).  When not using portal_factory these counts
>> decreased considerably to "just" 18 cataloging calls and no
>> permission changes.
>>
>> I have no idea how this impacts performance but is there maybe be
>> some room for improvement here?
>
> Tons!
>
> It got better in Plone 3, though - I'm surprised if those numbers are
> from Plone 3? Well, not *that* surprised maybe. ;-)

It was on Plone 3.0.3  :-p

Ric



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

[Wichert Akkerman]

Previously Martin Aspeli wrote:
> 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.

We need to refactor the content type creation for CMF trunk anyway, what
we're doing at the moment has already been deprecated.

Wichert.

--
Wichert Akkerman <[hidden email]>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

-------------------------------------------------------------------------
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]

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.

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/
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Laurence Rowe]

Martin Aspeli wrote:

>> #14: Realize that web publishing isn't our main arena
>
> I am not convinced that we are that big a contender in the pure
> documentation management space either, but we probably should be.
>
> I really want a Big Green Button in Plone. Click it, and you have a
> static copy of your Plone site. Tick an option or two, and you get a PHP
> (yeah, you heard me) version that gives you flat content + search. Maybe
> PHP + MySQL even, and a simplified skin (that can be themed
> independently). That goes on your $5/mo web hosting when you want to use
> Plone to *manage content* but ultimately just want to publish it.
>
> We already have solutions here (CMFDeployment, Entransit), but this area
> needs a champion who makes it work. It doesn't have to cover every
> possible use case, just the most basic ones - it wont' be used by
> everyone. Bonus points for a flexible architecture that allows people to
> plug in some "transformers" for content or whatever to customise the
> outputs.

This would be really cool, and make plone useful to many, many more people.

> #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.

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