Killer App for ZClasses
Thank you very much for all the advice, and particularly for the list of problems with ZClasses. I had been thinking of jumping in and fixing some of those things. I am not quite sure where to start. What do I work on to benefit ZClasses, while taking care of my immediate business needs? I also must be mindful that I do not represent enough users to get my changes to the Zope core to be accepted and integrated into the product. Last night, I was wondering what should I do? Not only technically, what should I fix first, but also socially how should I proceed? Fortuitously, this morning, my associate Christopher Appell, who has been doing a brilliant job, calls me up and says: I want an application where we, and clients can track invoices. What I heard him say is: I need a very simple app. Just 1 ZClass, an invoice object. Not even subitems on the invoice. I want to create these ZClasses, I want a table of these ZClasses, I want to be able to say which role gets to create these objects, which role gets to see which fields, and which role gets to edit which fields. I would also like a search form with a ZCatalog, and I would like an edit/create form. All I want is to define the fields of the Zclass, and have the rest magically appear. I want the application to be built really quickly. Can you deliver by Monday? I thought, hey, I bet a million people need such a simple web app. Let us make it really easy to implement craigslist or better. Let me go ahead and create a ZClass product, and go ahead and distribute it. Lots of people would use it. Or at least enough to build up a critical mass. And then as some of those people go ahead and stretch the boundaries of the app, they will fix all of the ZClass problems we all know about. They will fix them for their own reasons, which is of course what drives open source. What do you think? Is this an effective way to operate on the social medium which is open source? Of course those who want to deprecate ZClasses will think this is a terrible terrible idea. I am fine with ZClasses being a separate product. I have a much richer deeper long-term vision of where this is going, but the longest road begins with a single step. Regards Chris
--On 18. April 2007 12:32:24 -0700 Christopher Lozinski <lozinski@freerecruiting.com> wrote:
I have a much richer deeper long-term vision of where this is going, but the longest road begins with a single step.
I think you should stop dreaming and face the reality. There is almost nobody interested of the developer community in ZClasses.. I have no idea what your goal is with your ongoing ZClasses postings..you're on siding and there is no way back. -aj
Christopher Lozinski wrote:
I thought, hey, I bet a million people need such a simple web app. Let us make it really easy to implement craigslist or better. Let me go ahead and create a ZClass product, and go ahead and distribute it. Lots of people would use it. Or at least enough to build up a critical mass. And then as some of those people go ahead and stretch the boundaries of the app, they will fix all of the ZClass problems we all know about. They will fix them for their own reasons, which is of course what drives open source.
What do you think? Is this an effective way to operate on the social medium which is open source?
Of course you can do this, no-one will stop you, but if you listen to the voices here who've been around for longer than you have, you may do well to heed their advice and avoid the risk that you'll be wasting your time. The single biggest flaw in people's perception of open source is normally the assumption that users and developers will flock to anything that's being offered up. I'm sure there are existing tools that already do what you describe, that've been tested and thought about by lots of people. I'm also not so sure it's going to be a "killer app" in the same way that Plone arguably is for Zope 2, for example. I've never used ZClasses, they were dead before I joined the world of Zope. No-one I know uses ZClasses. Those who tell me they once did are very happy to be using other things. :) Perhaps you should look at some of the technologies the Zope community has invented to supersede them? Grok may be exactly what you want; take a look at the tutorial on http://grok.zope.org. If you want to put your time in and help the community (great!) then helping to advance the cause of Grok and Zope 3 will probably be a much better investment. Martin
Christopher Lozinski wrote:
I need a very simple app. Just 1 ZClass, an invoice object. Not even subitems on the invoice. I want to create these ZClasses, I want a table of these ZClasses, I want to be able to say which role gets to create these objects, which role gets to see which fields, and which role gets to edit which fields. I would also like a search form with a ZCatalog, and I would like an edit/create form. All I want is to define the fields of the Zclass, and have the rest magically appear. I want the application to be built really quickly. Can you deliver by Monday?
Let me deliver by Thursday:: import grok from zope import schema class InvoiceTracker(grok.Application, grok.Container): """Folderish object (we say 'container' in Zope 3) that contains Invoice objects.""" class Invoice(grok.Model): """A persistent Invoice class, below is a definition of the data fields that an invoice can carry.""" class fields: date = schema.Date(title=u'Date') from = schema.TextLine(title=u'From') about = schema.TextLine(title=u'About') amount = schema.Float(title=u'Amount') status = schema.Choice(title=u'Status', values=['Incoming', 'Paid', 'Rejected']) class AddInvoice(grok.AddForm): """Form that lets us enter invoice data and as a result creates an Invoice object and puts it into the InvoiceTracker container""" grok.context(InvoiceTracker) form_fields = grok.AutoFields(Invoice) @grok.action("Add invoice") def add(self, **data): invoice = Invoice() self.applyData(invoice, **data) self.context[str(data['date']) + '-' + data['from'])] = invoice self.redirect(self.url(invoice)) class EditInvoice(grok.EditForm): """This lets us edit the data contained in an invoice. It is accessible via http://url/to/an/invoice/edit.""" grok.context(Invoice) grok.name('edit') form_fields = grok.AutoFields(Invoice) class DeleteInvoice(grok.View): """View that lets us delete an invoice from the container. You can invoke it via http://url/to/the/invoice/tracker/delete?name=name_of_invoice""" grok.context(InvoiceTracker) grok.name('delete') def update(self, name): del self.context[name] class ListInvoices(grok.View): """View that lists all the invoices within an invoice tracker.""" grok.context(InvoiceTracker) grok.name('index') # Rendering happens in Page Template app_templates/listinvoices.pt. # This needs to be written (the only template in this app, btw). What you got here is a simple CRUD (create read update delete) application. Most web-frameworks have examples on how to create such an application because it's such a common pattern. ZClasses surely was an easy way to create CRUD applications in Zope 2. However, apart from many technical difficulties that are ZClasses, I personally find that through-the-web (TTW) development is actually hurting Zope and the people who use it, rather than help. I've put my thoughts regarding that issue into a blog article recently [1]. One of the main points of that article is that while TTW development is bad, we do need an altenative to lower the bar for newcomers, quick'n'dirty developers, and for ourselves who can't remember every single detail of Zope's big API. Grok [1] is this alternative. The above 60-line application is written in Grok and it should be functional except for one PageTemplate which yet needs to be written. Note I haven't tested the above code at all, there might be typos lurking. Is this so much harder than ZClasses? I believe no (though as one of the original Grok developers, I'm naturally biased). Like other people have pointed out already, there's a Grok tutorial [3] where you can learn this stuff. And a while back, I made a screencast [4] that shows how to develop a simple CRUD application like the above (in the screencasts it's a TodoList) in 15 minutes. It also took me about 15 minutes to write the above. And it's commented. Chris, if you want to keep ZClasses alive on your own, we can't stop you. If you want to rip out Zope's security in the process and simplify everything and what not, well that's crazy, but we can't stop you. But it seems that the community at this point is not interested in any of this. That may seem sad, but given many people's frustration with TTW in general and ZClasses in particular, it's not so surprising. Give Grok a chance. Let us know how it went. I already gave you a head start on that invoice tracking app. :) [1] http://www.z3lab.org/sections/blogs/philipp-weitershausen/2007_03_27_meet-gr... [2] http://grok.zope.org [3] http://grok.zope.org/tutorial.html [4] http://www.archive.org/details/grok_todo_part1 -- http://worldcookery.com -- Professional Zope documentation and training
Philipp von Weitershausen wrote:
Christopher Lozinski wrote:
I need a very simple app. Just 1 ZClass, an invoice object. Not even subitems on the invoice. I want to create these ZClasses, I want a table of these ZClasses, I want to be able to say which role gets to create these objects, which role gets to see which fields, and which role gets to edit which fields. I would also like a search form with a ZCatalog, and I would like an edit/create form. All I want is to define the fields of the Zclass, and have the rest magically appear. I want the application to be built really quickly. Can you deliver by Monday?
I should note that for reasons of brevity, I deliberately omitted two features from the "spec" above: * catalog searching (would be possible with another Page Template for the search results view and ~20 lines of Python code, if even that much) * security declarations (a couple of lines here and there) -- http://worldcookery.com -- Professional Zope documentation and training
Philipp von Weitershausen wrote at 2007-4-19 07:52 +0200:
... ZClasses surely was an easy way to create CRUD applications in Zope 2. However, apart from many technical difficulties that are ZClasses, I personally find that through-the-web (TTW) development is actually hurting Zope and the people who use it, rather than help.
As so often, I have quite different opinions. In your (stripped away) example, I saw lots of magic (e.g. "grok.context", "grok.name", "@grok.action"). "ZClasses", too, have their magic. But, there, the magic is supported by a graphical UI which helps considerably... For me (several years back), Zope's TTW capabilities have been a major reason why I got interested in Zope. Had I then seen the nasty ZCML files so much liked in Zope 3, I would probably have turned away very rapidly.
.... Is this so much harder than ZClasses? I believe no
As someone who used ZClasses intensively, I believe "yes". -- Dieter
--On 25. April 2007 21:51:24 +0200 Dieter Maurer <dieter@handshake.de> wrote:
In your (stripped away) example, I saw lots of magic (e.g. "grok.context", "grok.name", "@grok.action").
But readable and comprehensible magic...but I would not call that magic.
For me (several years back), Zope's TTW capabilities have been a major reason why I got interested in Zope.
Interesting ...
Had I then seen the nasty ZCML files so much liked in Zope 3, I would probably have turned away very rapidly.
ZCML is a pain in the ***...that's why Grok is attractive for writing Z3 apps and attracting more people to Z3.
Is this so much harder than ZClasses? I believe no
As someone who used ZClasses intensively, I believe "yes".
As so often, I disagree and must second Philipp. Andreas
On Wed, 25 Apr 2007 16:13:43 -0400, Andreas Jung <lists@zopyx.com> wrote:
--On 25. April 2007 21:51:24 +0200 Dieter Maurer <dieter@handshake.de> wrote:
In your (stripped away) example, I saw lots of magic (e.g. "grok.context", "grok.name", "@grok.action").
But readable and comprehensible magic...but I would not call that magic.
For me (several years back), Zope's TTW capabilities have been a major reason why I got interested in Zope.
Interesting ...
i too got seduced by the zmi, before i realized it had the grip of an iron maiden.
Had I then seen the nasty ZCML files so much liked in Zope 3, I would probably have turned away very rapidly.
ZCML is a pain in the ***...that's why Grok is attractive for writing Z3 apps and attracting more people to Z3.
amen.. part of the appeal of grok, for me at least, is that its basically a meta-framework for constructing your own domain specific languages.
Is this so much harder than ZClasses? I believe no
As someone who used ZClasses intensively, I believe "yes".
As so often, I disagree and must second Philipp.
i'd agree with andreas but for one thing, restarting the app server for minor code changes is painful.. akin to going from python back to compiled languages. for all their deployment/development best practice faults, zclasses offered quick iteration. -kapil
--On 25. April 2007 16:35:54 -0400 Kapil Thangavelu <hazmat@objectrealms.net> wrote:
As someone who used ZClasses intensively, I believe "yes".
As so often, I disagree and must second Philipp.
i'd agree with andreas but for one thing, restarting the app server for minor code changes is painful.. akin to going from python back to compiled languages. for all their deployment/development best practice faults, zclasses offered quick iteration.
RefreshNG seems to solve the restarting problem. Andreas
Andreas Jung wrote at 2007-4-25 22:13 +0200:
... But readable and comprehensible magic...but I would not call that magic.
If I see at class level a function call "grok.context(something)", this does not look like "comprehensible magic". -- Dieter
On 4/26/07, Dieter Maurer <dieter@handshake.de> wrote:
Andreas Jung wrote at 2007-4-25 22:13 +0200:
... But readable and comprehensible magic...but I would not call that magic.
If I see at class level a function call "grok.context(something)", this does not look like "comprehensible magic".
It sets the grok context to something. Is that really incomprehensible? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64
Lennart Regebro wrote:
On 4/26/07, Dieter Maurer <dieter@handshake.de> wrote:
Andreas Jung wrote at 2007-4-25 22:13 +0200:
... But readable and comprehensible magic...but I would not call that magic.
If I see at class level a function call "grok.context(something)", this does not look like "comprehensible magic".
It sets the grok context to something. Is that really incomprehensible?
From people's comments, here and on the archetypes mailing list, I am pretty convinced that there is support for a through the web editing environment, even from Alexander Limi, expert on human interfaces and co-author of Plone. There was talk about TTW for Zope 3, for Archetypes, but not for Zope 2. I understand that ZClasses are crufty inside. I now understand we can toss out propertysheets becasause Zope 8 allows protection of individual properties. I wish I had time to implement that. Right now I do not even have time to update the upgrade plans for ZClasses. They are on the wiki. I would love to see detailed documentation of Zope Product Classes. Perhaps we could create a cleaner ZClasses that just drives the Zope Product class. I would not even mind a server restart for each new class, evidently that is required for file system classes, but not ZClasses. No wonder ZClasses is strange. It had to be to make it possible to do more than Products can do. Detailed design documentation of Zope 2 Products would perhaps make it clear why ZClasses are implemented the way they are implemented. As for grok contexts, you are arguing about a blade of grass. Look at the forest. I would like to be able to build a complete app, a network of objects persisted on the the ZODB, with a couple of clicks. Then I could add methods on top of that. ZClasses gives me a path in that direction. I have some of my own tools to take me further. Why am I not going with Zope3? It seems like way too much overhead. But most importantly it does not give me the stuff I am really looking for. Sure it does some schema stuff, but that is mostly for 1 object and its user interface, rather than over the whole network of objects. Why are there schemas for the user interfaces, and interfaces for the other interfaces? Lack of symmetry. Zope3 checks that the next object in the network has the right interface. That is too complex for me. I just want to say that a person can have a role hiring manager, a role candidate, a role recruiter, or a role accountant. So Zope 3 does not provide the abstraction that I am looking for. Which leaves me with Zope 2. And I am back to building up my own desired abstractions on Zope 2. My point is not to make this flame war break out again. I just want to make sure there is clear documentation for an alternative point of view. Actually all of the criticism has been very helpful in getting me to better understand the issues. Regards Chris
From people's comments, here and on the archetypes mailing list, I am pretty convinced that there is support for a through the web editing environment, even from Alexander Limi, expert on human interfaces and co-author of Plone.
You have an incredibly annoying tendency to take the words of someone "important", drop their name and qualify their "importance" and then bend their statements to fit your point of view. Alex co-founded Plone, and I'm sure he likes being referred to as an expert on HCI, but he didn't exactly say that the path you're going down has much merit either. What there seems to be support for, is that in a CMS like Plone, administrators may have a need to define schemata (as in - I want these fields with these labels and this validation) for content types, in order to capture domain-specific information. That is, within the high-level UI constructs which Plone affords all content. There does not seem to be very much support for building complex systems, with significant amounts of custom logic TTW. By all means, knock yourself out, but at least try to weigh the arguments that are being presented.
As for grok contexts, you are arguing about a blade of grass. Look at the forest. I would like to be able to build a complete app, a network of objects persisted on the the ZODB, with a couple of clicks.
Grok (or Archetypes in Plone) would allow you to build that in a couple of lines of code, and ArchGenXML (with Archetypes/Plone) in a couple of clicks in ArgoUML.
Why am I not going with Zope3? It seems like way too much overhead. But most importantly it does not give me the stuff I am really looking for. Sure it does some schema stuff, but that is mostly for 1 object and its user interface, rather than over the whole network of objects. Why are there schemas for the user interfaces, and interfaces for the other interfaces? Lack of symmetry. Zope3 checks that the next object in the network has the right interface. That is too complex for me. I just want to say that a person can have a role hiring manager, a role candidate, a role recruiter, or a role accountant. So Zope 3 does not provide the abstraction that I am looking for. Which leaves me with Zope 2. And I am back to building up my own desired abstractions on Zope 2.
I'd contend that you possibly haven't quite understood how these things would work in Zope 3, and if you are going to build your own abstractions anyway, you will probably find it *way* easier to do that on top of Zope 3's primitives than Zope 2's. I've been developing on top of Zope 2 (with Plone) for a long time, and I still find things like product factories and dispatchers and the security model confusing. By contrast, the ones in Zope 3 are better documented and burdened by a lot less legacy. Zope 2 still has a lot going for it, and is evolving and growing and I still love it, but if you're about to set out building some new development tool, and you don't already understand the low level of what you're about to try to plug into, you'll probably find it much easier to start with a copy of Web Component Development with Zope 3 (worldcookery.com) and Zope 3. Martin
Lennart Regebro wrote at 2007-5-3 17:42 +0200:
On 4/26/07, Dieter Maurer <dieter@handshake.de> wrote:
Andreas Jung wrote at 2007-4-25 22:13 +0200:
... But readable and comprehensible magic...but I would not call that magic.
If I see at class level a function call "grok.context(something)", this does not look like "comprehensible magic".
It sets the grok context to something. Is that really incomprehensible?
When it is inside a class definition... -- Dieter
participants (7)
-
Andreas Jung -
Christopher Lozinski -
Dieter Maurer -
Kapil Thangavelu -
Lennart Regebro -
Martin Aspeli -
Philipp von Weitershausen