For those who have not been following this thread, here is the proposal. http://wiki.zope.org/zope2/ZClassesNG I will go ahead and change the name. I have a name proposal at the end of this email. Last night I realized that this proposal, will make it really easy for me to create Archetype Classes on Plone. Suddenly Plone development goes from painful to fast and easy, and I can build my new apps on Plone reasonably quickly. Which I need, because I am moving from a single person company to a multi-person company, and the whole approvals cycle is now becoming much more important to me. Just for completeness, I do need to respond to the specific feedback I received.
If there is such an easy translation from ZMI-based ZClass to filesystem product, then why not write the filesystem product in the first place?
There is room in the world for both through-the-web development and file system based development. On his personal home page http://zwiki.org/JimFulton Jim Fulton, the Zope Pope writes: "Make ZWiki subclassable from ZClasses. This will make it a lot easier to experiment and innovate." So I am in good company on the need for through-the-web development. Have you seen how many lines of code it takes on the file system to put up a simple product with 1 instance variable? I am just not as smart as others. I make mistakes. If I can do a simple point and click to create a product, I will make fewer mistakes, and it will be generated faster, and I have more time for other things. There is just too much software which needs to be written.
You're assuming there is an obvious one-to-one mapping between ZClass syntax and non-ZClass products on the filesystem, which may or may not be true. That is a good point. I expect to see several different patterns to emerge, all of which can be supported. Right now I see multiple classes in a single product.
You're relying on code generation, so you'll run into trouble when the two versions (ZODB and filesystem) diverge for whatever reason (someone edited the code, say). Good Point. Better only edit the code in one place or this problem will arise. I will add a read me to the file system, saying DO NOT EDIT THIS CODE ON THE FILE SYSTEM! And a flag, perhaps a file name, DO_NOT_OVERWRITE which will prevent overwrites. Just think, this will be the fastest way to generate a new zope product. That alone makes it useful! I added this comment to the proposal wiki. Thank you very much Martin!
Also, Zope needs a restart to load a new product, which will mess with the workflow. Great Point. I hope this one is fixable. I would think it should be possible for Zope to be able to dynamically unload a Product, or load or reload a product. I wonder why it does not do so now? Is this fixable? Of course once the product is loaded, a refresh.txt option allows it to be changed and rewritten dynamically.
But the bigger picture here is that an awful lot of people are telling you that spending your time on this is a bad idea, that you'll probably find it more difficult than you imagine, and that if you are going to invent new things, your time may be better spent pulling the same direction that most other people are. Well it all depends on how you define better.
By all means, give it a go, but you will probably find it difficult to get help when you are stuck because (a) no-one else seems to care and Well maybe this is not the right mailing list. Let me go see what the archetypes mailing list thinks of all of this. Besides this is pretty easy to do. I have written file-system based products in Zope and Plone.
(b) not many other people seem to even know how this should work. I think the best way to explain how it works is to put up a demo site. If I can improve the written description in any way, let me know. Which part of it do you personally not understand? Clicking to define instance variables? Autogenerating the File System Folder? Aquiring the instance folder at run-time to give the appearance of instance methods?
I do agree with you on one point. It needs a different name. Can I call them LozinskiClasses? I am surprised more people do not ego-name products. Look a new word! Regards Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22 Apr 2007, at 19:28, Christopher Lozinski wrote:
On his personal home page http://zwiki.org/JimFulton Jim Fulton, the Zope Pope writes:
"Make ZWiki subclassable from ZClasses. This will make it a lot easier to experiment and innovate."
I guess I would just laugh if you didn't seem to serious. That page, as it refers to the next release of Zope as 2.2, must have been put up about 5 years ago and not updated since. This is not Jim's "personal home page", but some page he put up eons ago and never looked at again. I'd think he has evolved his opinion since then (heavy sarcasm alert). jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGK54DRAx5nvEhZLIRAnsKAKCT7M21aOL8tpDxYlCwRoF9Z7aFBwCeP+kX JbCuHA7DudkOf+TcKbJRmN4= =KsoB -----END PGP SIGNATURE-----
Christopher Lozinski wrote:
For those who have not been following this thread, here is the proposal. http://wiki.zope.org/zope2/ZClassesNG
Can you please not start a new thread for every turn of this conversation? 8 of the last 9 threads are by you on this exact issue.
Last night I realized that this proposal, will make it really easy for me to create Archetype Classes on Plone. Suddenly Plone development goes from painful to fast and easy, and I can build my new apps on Plone reasonably quickly. Which I need, because I am moving from a single person company to a multi-person company, and the whole approvals cycle is now becoming much more important to me.
Plone development with Archetypes is not painful. Hundreds of developers do it, so it can't be that bad. See http://plone.org/documentation/manual/archetypes-developer-manual http://plone.org/documentation/tutorial/richdocument and especially http://plone.org/documentation/tutorial/archgenxml-getting-started The latter is about generating AT content types from UML diagrams.
Have you seen how many lines of code it takes on the file system to put up a simple product with 1 instance variable? I am just not as smart as others. I make mistakes. If I can do a simple point and click to create a product, I will make fewer mistakes, and it will be generated faster, and I have more time for other things. There is just too much software which needs to be written.
Yeah, I honestly don't find it very hard. But at the risk of repeating this again and again and again. Can you *please* look at Grok? Or ArchGenXML if you want to develop against Plone.
Good Point. Better only edit the code in one place or this problem will arise. I will add a read me to the file system, saying DO NOT EDIT THIS CODE ON THE FILE SYSTEM! And a flag, perhaps a file name, DO_NOT_OVERWRITE which will prevent overwrites. Just think, this will be the fastest way to generate a new zope product.
If you just want something to create boilerplate filesystem code, then look into PasteScript and ZopeSkel. For a Plone perspective, see: http://plone.org/documentation/how-to/use-paster
Also, Zope needs a restart to load a new product, which will mess with the workflow. Great Point. I hope this one is fixable. I would think it should be possible for Zope to be able to dynamically unload a Product, or load or reload a product. I wonder why it does not do so now? Is this fixable? Of course once the product is loaded, a refresh.txt option allows it to be changed and rewritten dynamically.
Again, I doubt people will be willing to perform risky refactoring of Zope internals to support your one dubious use case.
I do agree with you on one point. It needs a different name. Can I call them LozinskiClasses? I am surprised more people do not ego-name products. Look a new word!
Yay. Martin
Martin Aspeli wrote:
Plone development with Archetypes is not painful. Hundreds of developers do it, so it can't be that bad.
Urm, that's not true. Archetypes is the single most painful component to use from Plone... It's also the biggest source of frustration I have with Plone. Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Martin Aspeli wrote:
Plone development with Archetypes is not painful. Hundreds of developers do it, so it can't be that bad.
Urm, that's not true. Archetypes is the single most painful component to use from Plone...
It's also the biggest source of frustration I have with Plone.
Okay. Let me rephrase. Most people don't find it painful, and a huge number of developers are being very productive with Archetypes. I know you hate it Chris, but you are in the minority. In any case, you may be interested to see some experiments we've been doing with using formlib and Zope3-like content types, not using Archetypes. See http://dev.plone.org/plone/browser/plone.app.content/trunk/plone/app/content.... It won't be a full alternative to Archetypes for a while, because AT provides functionality that doesn't (yet) have any equivalent outside AT, but for simple things it may be worth exploring. Martin -- View this message in context: http://www.nabble.com/ZClassNG-proposal--makes-Archetypes-Easy.-tf3627364.ht... Sent from the Zope - Dev mailing list archive at Nabble.com.
--On 23. April 2007 03:57:25 -0700 Martin Aspeli <optilude@gmx.net> wrote:
Chris Withers wrote:
Martin Aspeli wrote:
Plone development with Archetypes is not painful. Hundreds of developers do it, so it can't be that bad.
Urm, that's not true. Archetypes is the single most painful component to use from Plone...
It's also the biggest source of frustration I have with Plone.
Okay. Let me rephrase. Most people don't find it painful, and a huge number of developers are being very productive with Archetypes. I know you hate it Chris, but you are in the minority.
I have to second that. The latest versions of AT are pretty much stable and usable. AT is no longer the PITA framework it was some years ago - as long as you don't look under the hood and as long as you don't try to be tricky. AT works fine if you use it the 'standard' way - however it slaps you when you're trying to be smarter than AT. Using Z3-schemas + formlib is definitely the preferred way to go. We got a basic content-type working for a customer based on z3-schema/formlib within half a day (without having any knowledge in Z3 schemas and formlib). -aj
Andreas Jung-5 wrote:
Okay. Let me rephrase. Most people don't find it painful, and a huge number of developers are being very productive with Archetypes. I know you hate it Chris, but you are in the minority.
I have to second that. The latest versions of AT are pretty much stable and usable. AT is no longer the PITA framework it was some years ago - as long as you don't look under the hood and as long as you don't try to be tricky. AT works fine if you use it the 'standard' way - however it slaps you when you're trying to be smarter than AT.
Using Z3-schemas + formlib is definitely the preferred way to go. We got a basic content-type working for a customer based on z3-schema/formlib within half a day (without having any knowledge in Z3 schemas and formlib).
Eventually, I expect that a Z3 schema/formlib based approach an Archetypes will converge; for the moment, most people will still be way more productive with straight Archetypes in Plone, because things like references, WYSIWYG editors and transformations are not yet as mature outside of Archetypes. For simple things, I've had some success wtih plone.app.content in Plone 3. Martin -- View this message in context: http://www.nabble.com/ZClassNG-proposal--makes-Archetypes-Easy.-tf3627364.ht... Sent from the Zope - Dev mailing list archive at Nabble.com.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote:
Chris Withers wrote:
Martin Aspeli wrote:
Plone development with Archetypes is not painful. Hundreds of developers do it, so it can't be that bad.
AT has the classic "Z-shaped curve" in spades: when it does what you want, it is great, but trying to get it to do something else is painful and frustrating.
Urm, that's not true. Archetypes is the single most painful component to use from Plone...
It's also the biggest source of frustration I have with Plone.
Okay. Let me rephrase. Most people don't find it painful, and a huge number of developers are being very productive with Archetypes. I know you hate it Chris, but you are in the minority.
I don't agree all that often with Chris W, but I find Archetypes an extremely frustrating framework to work with, an normally avoid it even when building out sites with it. It is not exactly a secret that the Archetypes codebase is a mess; its original authors have abandoned it, pretty much. There are some hardy souls who will fix bugs in AT, but nobody has stepped up to the problem of making it play nice with other frameworks, or making it more maintainable. Trying to find a more palatable replacement for AT is a perfectly reasonable goal.
In any case, you may be interested to see some experiments we've been doing with using formlib and Zope3-like content types, not using Archetypes. See http://dev.plone.org/plone/browser/plone.app.content/trunk/plone/app/content.... It won't be a full alternative to Archetypes for a while, because AT provides functionality that doesn't (yet) have any equivalent outside AT, but for simple things it may be worth exploring.
Cool. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLOGO+gerLs4ltQ4RAlN/AKDBCwqd6bBXkK9WhHHnchnHcWwKzwCgrQGe vW/2zWxGU5vIpSqEycY482w= =2jiZ -----END PGP SIGNATURE-----
Tres Seaver wrote:
AT has the classic "Z-shaped curve" in spades: when it does what you want, it is great, but trying to get it to do something else is painful and frustrating.
I don't agree all that often with Chris W, but I find Archetypes an extremely frustrating framework to work with, an normally avoid it even when building out sites with it.
Out of curiosity, what types of things are you trying to do that you find frustrating?
It is not exactly a secret that the Archetypes codebase is a mess; its original authors have abandoned it, pretty much. There are some hardy souls who will fix bugs in AT, but nobody has stepped up to the problem of making it play nice with other frameworks, or making it more maintainable.
Archetypes has actually received more love (where "love" typically means making it use things like Zope 3 style vocabularies and subscription adapters for validation) over the Plone 3 release than in a long time. There are various developers in the Plone community who are capable of maintaining it, myself included, and we have a new overall maintainer in Daniel Nouri.
Trying to find a more palatable replacement for AT is a perfectly reasonable goal.
Definitely. The longer term roadmap for Archetypes mirrors that of Zope itself. Refactor the internals (e.g. transformation engine, reference engine - both of which are ongoing and will probably land in Plone 3.5; starting to use Zope 3 style widgets internally is another favourite pet peeve of mine) to rely on more general components which do not make assumptions about content objects being AT objects. The part of Archetypes that most people see (the schema, the base classes) are actually fairly agnostic and could be viewed as just another spelling of something like a Zope 3 schema + a formlib form. The challenge is that 90% of add-on Plone products probably rely on Archetypes. We're not about to break them. :) That's a testament to AT's success, and we see lots of developers who don't have a very deep grasp on the full Zope stack being very productive with Plone+Archetypes. Sometimes, like you say, they try to use it for things that it's not so well suited for, and for sure it can be difficult to migrate to layers lower down the stack in that case. That's all part of the volution, though - there's a lot of "history" in the AT codebase. :) Cheers, Martin -- View this message in context: http://www.nabble.com/ZClassNG-proposal--makes-Archetypes-Easy.-tf3627364.ht... Sent from the Zope - Dev mailing list archive at Nabble.com.
I actually think TTW schema generation has some validity (so content types can be easily generated by users). Restricted Python (in python scripts) just kind of sucks though for being almost python but a little different. You could keep python code on the filesystem seperate and just write adapters to your TTW content types. (To make this work well would require versioned schemas to allow for changes and migrations - perhaps zope.app.generations can help) For zope 3 based stuff this looks really interesting: http://agendaless.com/Members/tseaver/software/userschema/ But if you are happy with archetypes (it has all the cool widgets) why not look at ATSchemaEditorNG: http://plone.org/products/atseng And if you really want to to code generation then why not just go for archgenxml (as suggested by Martin)? Fixing the reload issue is tricky by the looks of it. There has been quite a lot of discussion on the mailing lists in the past few months, read the archives to find out. refreshng and grok have the latest movement You are likely to see more support if you actually address why none of the other suggestions actually meet your needs. Your current bearing would seem to lead to yet another attempt at dynamic schema generation whilst breaking compatibility with ZClasses. Laurence Christopher Lozinski wrote:
For those who have not been following this thread, here is the proposal. http://wiki.zope.org/zope2/ZClassesNG
I will go ahead and change the name. I have a name proposal at the end of this email. Last night I realized that this proposal, will make it really easy for me to create Archetype Classes on Plone. Suddenly Plone development goes from painful to fast and easy, and I can build my new apps on Plone reasonably quickly. Which I need, because I am moving from a single person company to a multi-person company, and the whole approvals cycle is now becoming much more important to me.
Just for completeness, I do need to respond to the specific feedback I received.
If there is such an easy translation from ZMI-based ZClass to filesystem product, then why not write the filesystem product in the first place?
There is room in the world for both through-the-web development and file system based development.
On his personal home page http://zwiki.org/JimFulton Jim Fulton, the Zope Pope writes:
"Make ZWiki subclassable from ZClasses. This will make it a lot easier to experiment and innovate."
So I am in good company on the need for through-the-web development. Have you seen how many lines of code it takes on the file system to put up a simple product with 1 instance variable? I am just not as smart as others. I make mistakes. If I can do a simple point and click to create a product, I will make fewer mistakes, and it will be generated faster, and I have more time for other things. There is just too much software which needs to be written.
You're assuming there is an obvious one-to-one mapping between ZClass syntax and non-ZClass products on the filesystem, which may or may not be true. That is a good point. I expect to see several different patterns to emerge, all of which can be supported. Right now I see multiple classes in a single product. You're relying on code generation, so you'll run into trouble when the two versions (ZODB and filesystem) diverge for whatever reason (someone edited the code, say). Good Point. Better only edit the code in one place or this problem will arise. I will add a read me to the file system, saying DO NOT EDIT THIS CODE ON THE FILE SYSTEM! And a flag, perhaps a file name, DO_NOT_OVERWRITE which will prevent overwrites. Just think, this will be the fastest way to generate a new zope product. That alone makes it useful! I added this comment to the proposal wiki. Thank you very much Martin!
Also, Zope needs a restart to load a new product, which will mess with the workflow. Great Point. I hope this one is fixable. I would think it should be possible for Zope to be able to dynamically unload a Product, or load or reload a product. I wonder why it does not do so now? Is this fixable? Of course once the product is loaded, a refresh.txt option allows it to be changed and rewritten dynamically. But the bigger picture here is that an awful lot of people are telling you that spending your time on this is a bad idea, that you'll probably find it more difficult than you imagine, and that if you are going to invent new things, your time may be better spent pulling the same direction that most other people are. Well it all depends on how you define better. By all means, give it a go, but you will probably find it difficult to get help when you are stuck because (a) no-one else seems to care and Well maybe this is not the right mailing list. Let me go see what the archetypes mailing list thinks of all of this. Besides this is pretty easy to do. I have written file-system based products in Zope and Plone. (b) not many other people seem to even know how this should work. I think the best way to explain how it works is to put up a demo site. If I can improve the written description in any way, let me know. Which part of it do you personally not understand? Clicking to define instance variables? Autogenerating the File System Folder? Aquiring the instance folder at run-time to give the appearance of instance methods? I do agree with you on one point. It needs a different name. Can I call them LozinskiClasses? I am surprised more people do not ego-name products. Look a new word!
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 )
Laurence Rowe <l@lrowe.co.uk> writes:
I actually think TTW schema generation has some validity (so content types can be easily generated by users). Restricted Python (in python scripts) just kind of sucks though for being almost python but a little different. You could keep python code on the filesystem seperate and just write adapters to your TTW content types. (To make this work well would require versioned schemas to allow for changes and migrations - perhaps zope.app.generations can help)
For zope 3 based stuff this looks really interesting: http://agendaless.com/Members/tseaver/software/userschema/
I've done a bit of work reccently to get PersistentModules working better with interfaces. This allows me to have Zope 3 generated TTW and stored in the ZODB. I'm using this currently and it all seems to be working great. Ross
On 4/24/07, Laurence Rowe <l@lrowe.co.uk> wrote:
I actually think TTW schema generation has some validity (so content types can be easily generated by users).
Totally. What Christopher needs can be done with for example CPS, quite easily, and maybe with Plone as well, if there is a TTW Schema editori for Plone (I have heard rumours :-) ). But that isn't what he thinks he wants, :-) -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64
--On 25. April 2007 07:48:04 +0200 Lennart Regebro <regebro@gmail.com> wrote:
On 4/24/07, Laurence Rowe <l@lrowe.co.uk> wrote:
I actually think TTW schema generation has some validity (so content types can be easily generated by users).
Totally. What Christopher needs can be done with for example CPS, quite easily, and maybe with Plone as well, if there is a TTW Schema editori for Plone (I have heard rumours :-) ).
ATSchemaEditorNG...we used lately SignupSheet (which uses ATSENG) for the upcoming Zope conference in Germany for the call for papers and the registration for the participants...works like a charm.
But that isn't what he thinks he wants, :-)
Famous last words: "ZClassesssssssssssssssssss......" -aj
participants (9)
-
Andreas Jung -
Chris Withers -
Christopher Lozinski -
Jens Vagelpohl -
Laurence Rowe -
Lennart Regebro -
Martin Aspeli -
Ross Patterson -
Tres Seaver