Re: [Zope-dev] Re: Killer App for ZClasses
Christopher Lozinski wrote at 2007-5-3 09:12 -0700: > ... >I would love to see detailed documentation of Zope Product Classes. While a bit outdated, the Zope Developper Guide is still a major help. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Killer App for ZClasses
Lennart Regebro wrote at 2007-5-3 17:42 +0200: >On 4/26/07, Dieter Maurer <[EMAIL PROTECTED]> 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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Killer App for ZClasses
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Killer App for ZClasses
Lennart Regebro wrote: On 4/26/07, Dieter Maurer <[EMAIL PROTECTED]> 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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Killer App for ZClasses
On 4/26/07, Dieter Maurer <[EMAIL PROTECTED]> 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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Killer App for ZClasses
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Killer App for ZClasses
--On 25. April 2007 16:35:54 -0400 Kapil Thangavelu <[EMAIL PROTECTED]> 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 pgpSJy5ILBwhW.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Killer App for ZClasses
On Wed, 25 Apr 2007 16:13:43 -0400, Andreas Jung <[EMAIL PROTECTED]> wrote: --On 25. April 2007 21:51:24 +0200 Dieter Maurer <[EMAIL PROTECTED]> 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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Killer App for ZClasses
--On 25. April 2007 21:51:24 +0200 Dieter Maurer <[EMAIL PROTECTED]> 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 pgpIcRVnjzMdj.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Killer App for ZClasses
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Killer App for ZClasses
Christopher Lozinski wrote: I do have an accounting application I want to bring up quickly, and this seems to me the fastest way to bring it up, but also to have an upgrade path to the future. We do http://www.last-bastion.net/BastionLedger which is a full double entry general ledger with an entire order management workflow suite with skinnable order/invoice forms. Just download it and install it. Alan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Killer App for ZClasses
On 19 Apr 2007, at 08:25 , Christopher Lozinski wrote: The problem with upgrading ZClasses is that it would break the zope security models, and the Zope Product Model. That depends on what you by "upgrading ZClasses". To make them continue to work, simpler changes will probably suffice. It seems, though, that you want to create this next generation of ZClasses that has a simpler security model, form generation built-in etc. So that would be a rewrite as you've already mentioned. But I don't think it's worth all that work. Writing filessytem code can be just as agile. That's of course just one man's opinion. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Killer App for ZClasses
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Killer App for ZClasses
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-grok-successor
[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
___
Zope-De
[Zope-dev] Re: Killer App for ZClasses
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
