On Fri, 2007-01-05 at 10:22 -0500, Jim Fulton wrote:
Martijn Faassen wrote:
Just splitting stuff up into little flexible pieces won't attract
people. If our goal is to attract Zope 3 developers we need to make it
easy to get started. We can also say that Zope 3 is componentized and
snip /
As a non-developer observer, I'm +1 with Jim's discussion. Martin,
you're right that developer influx should be the key goal, and that (a)
simpler entry points like Grok and (b) killer apps are the way to get to
that goal.
and I think things like grok are the natural progression from
On Jan 6, 2007, at 7:19 AM, Martijn Faassen wrote:
Jim Fulton wrote:
Martijn Faassen wrote:
[snip]
Just splitting stuff up into little flexible pieces won't attract
people. If our goal is to attract Zope 3 developers we need to
make it easy to get started. We can also say that Zope 3 is
Martin Aspeli wrote:
The general direction that web frameworks are moving in, led by Rails and to
a certain extent Django, Pylons, TurboGears and arguably Plone in some
circumstances, is that getting started must be quick, results must be rapid,
the tools must support agile working practices
Jim Fulton wrote:
Martijn Faassen wrote:
[snip]
Just splitting stuff up into little flexible pieces won't attract
people. If our goal is to attract Zope 3 developers we need to make it
easy to get started. We can also say that Zope 3 is componentized and
flexible and all that, and this will
Martin Aspeli wrote:
Jim Fulton wrote:
I'll make some small comments below, but I want to make a big
comment to start. Zope 2 and Plone are both examples of
extensible applications. In my note, I was trying to make the
point that I think such applications have value. I'd like to
see them
Martijn Faassen wrote:
My hope is that with Grok we can inject some sensibilities into Zope 3
that focus more on getting things done easily and quickly. I think that
the basis built with an attitude of reusable and flexible components is
great to build a powerful getting things done easily
Paul Everitt wrote:
Thus, telling the Zope 3 core team to own and distribute the killer app
is neither realistic nor fair. Move Zope 3 to its natural turf and
collaborate with folks that feel passionate about other turf.
Application != the framework.
A very good point. Perhaps the future
On 1/6/07, Martin Aspeli [EMAIL PROTECTED] wrote:
Hopefully, we'll see something else emerge as well that is conceptually
a combination of the two: End user-oriented and pure Zope 3.
The only issue here is whether Zope 3 itself is useful directly to end
users, or something built on top
Hi Jim Martijn,
For xParrot we have a case in point where the ZMI both helped and
confused us. Because of the way the documentation is 'framed' (where
available) it lead us to believe, initially, that ZOPE was the ZMI.
The first incarnation of xParrot (an XML/XSLT provider) was
intermingled with
Martijn Faassen wrote:
Martin Aspeli wrote:
[snip]
I think your thoughts resonate quite well with my own observations and/or
confusion. I would, however, caution against becoming over-zealous in
breaking things up. Zope 2, CMF and Plone are successful in large part
because people get started
Jim Fulton wrote:
Martin Aspeli wrote:
...
Anyway - I hope these perspectives are useful. I'm certainly not
disagreeing
with what you're saying or with the direction you're pointing out. I
think
we just need be mindful that there were some good things about the past
approaches as well as
Jim Fulton wrote:
[snip]
The current Zope 3 distribution also contains an application that
resembles Zope 2 in many ways. There is an object tree and a Zope
Management Interface. At least up to now, when you install a Zope 3
distribution, you get an application that you can run out of the
Martin Aspeli wrote:
[snip]
I think your thoughts resonate quite well with my own observations and/or
confusion. I would, however, caution against becoming over-zealous in
breaking things up. Zope 2, CMF and Plone are successful in large part
because people get started quickly. If it takes
14 matches
Mail list logo
