[Zope-dev] Re: ZClassNG proposal makes Archetypes Easy.

[Laurence Rowe]

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 at 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 )
>