Hi Michael,
This is great - thanks a lot!
Michael Hierweck wrote:
Hi Martin,
Martin Aspeli wrote:
- Areas where there's insufficient/poor documentation, but once you
learn how to do something, it's clear how to proceed.
* How Plone make use of underlying technologies
Agree - we should document this better.
* How to extend member profiles
Agree - we probably need better technology for this. membrane/remember
is good for one problem domain, but isn't really appropriate IMHO for
simple "I just want to add some fields". Chapter 13 in my book does
cover this, but it'd be nice to have automated forms and better control
over the schema. I believe Kapil's ore.member does this, by the way.
* How to scale related to a large amount of content (still not clear for
me)
To a certain extent, scalability to huge deployments (hundreds of
gigabytes or thousands of logged-in users) will always require some
careful design and trade-offs. I think if you understand CacheFu,
Varnish and ZEO, you're pretty well covered until you reach those sizes,
though. ZODB blob support (which will come "for free" with the next
version of ZODB) is another important step, but shouldn't have much
impact on users.
(Your Plone 3 book has improved to situation and in the meantime there
is much additional documentation about Plone 3 online. Documentation is
often some steps beyond the technologie. In general it's much better
than some years ago.)
I'm glad to hear that.
- Areas where there appears to be more than one approach, and it's not
clear which one to choose
* Persistence:
Archetypes vs. plone.app.content vs. Devilstick vs. collective.tin
I'd say, "use Archetypes".
Like Wichert say, we can't *not* do the R&D and discuss how the future
may look, but that doesn't mean you should think that what has worked
for the last several years is suddenly dead.
plone.app.content works now, but I'd only recommend it for lightweight
objects that are less about full-blown content and more about capturing
some data. There's nothing p.a.c can do right now that Archetypes can't
(and plenty that AT can do that p.a.c can't), but if you are working on
something and you feel that AT is getting in your way, it may be worth a
look.
To me, p.a.c today is a building block for bigger and better things that
are still in the R&D phase.
* Standalone Forms:
AT Widgets "Hack" vs. zope.formlib vs. z3c.form
formlib is tried and tested and works well. Hacking AT widgets is
probably more pain that it's worth. z3c.form has a lot of promise, and
is in many ways an incremental evolution of formlib (at least for the
use cases where formlib is appropriate).
* Skinning
Zope 2 vs. Zope 3 technologies
Yes - this is probably the top of my list to unify (and also very hard).
(Main problems: you need to know all approaches to decide. Knowlegde is
approch specific to a higly grade. Knowledge is sometimes
outdating/superceeding fast. You never know which approaches a future
proof, especially related to non core (= collective) components => high
risk.)
- Areas where Plone doesn't appear to have a good way to do something
Different widget/schema technologies for add/edit forms and standalone
forms, escpecially atapi.Schema vs. zope.schema.
Yes. I think the standard way will be that a schema is an interface with
zope.schema fields and that longer term, atapi.Schema will be a shim
around this, but that's very tentative and speculative at this point.
Archetypes make it hard to separate between interfaces and
implementation. Classes based on Archetypes are always complex and don't
fit in a world of "orchestrating small pieces of software". Complex base
and mix-in classes make debugging/profiling hard.
Spot on. This is pretty much the reason why most efforts to improve this
aspect of Plone assume that we will design a cleaner solution based on
simpler components and then retrofit them into AT at a future stage
(which is of course the same approach that the Zope 2 -> Zope 3
evolution is taking)
Performance, especially related to indexing. (ZEO helps scaling towards
large amounts of page impressions/vistors. Improve handling of huge
amounts of content objects.)
See above. Note that there are a few efforts ongoing currently about
making things like Xapian and Lucene easier to work with for indexing
huge sites.
Suggestions:
* Documentation/Tutorials should not only say what they are doing, but
also why they are doing it this way. (Many do.) Documentation marked as
outdatet should tell what aspects are outdated. (Often this is related
to small pieces only, e.g. defining s.th. in now done using GS.)
Managing the body of documentation is a huge problem, for the simple
reason that it requires more manpower than we have able volunteers.
* Keep the official roadmap up to date and let the people use this to
decide which technologies are future proof and which are not.
Yes, we should be a bit better at this.
* Try include performance related improvements into the core
(QueueCatalog, collective.indexing) as every site out there should
benefit from performance.
Agreed.
* Keep in mind, reusing technologies where sensibly possible,
is developer friendly, e.g. zope.schema + z3c.form might be used on
ZODB, RDBMS content and standalone forms. The persistence layers for
RDBMS and ZODB should be too different.
I assume you mean "shouldn't be too different". I think everyone agrees
with this approach.
Cheers,
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
