[Zope3-dev] Re: Grok sprint 2 reports
Max M wrote: Martin Aspeli skrev: If you're talking about ArchGenXML, which generates AT code from UML, it's not too bad. The code it generates is pretty clean, and if you decide to abandon code generation, there's a minimum of cruft (mostly a few comment blocks) that you can remove if you wish. Yes. I was unclear. Sorry. I meant AGX. I use it for getting a project skeleton up and running quickly from simple UML. Something similar for Zope3 would be with me. Where the interfaces, classes, zcml and views would be generated from UML. But I will try out Grok, and see how the shoe fits before rambling on. Code generation is dangerous if that code is going to be seen and edited by humans afterwards. This danger is enhanced if that code generation has to happen more than one time for the same code base. A code generator can write repetitive cruft for you. Unfortunately if generated code is expected to be edited by humans, this means you have to live with the cruft. That sucks. This is especially bad if the code generation run happens more than once. If not, you can modify and get rid of the generated cruft, but if the generation run needs to happen again in the future, this is not possible. Code generation is fine if humans never see it - a compiler generates code, for instance. Setting up project infrastructure once with code generation isn't so dangerous. I would still like to examine whether the amount of files that a project needs cannot be reduced further in that case. There is a minor danger in the sense that code generation might make people less likely to remove cruft and just generate it instead. We should be careful that cruft doesn't grow too big, as people will inevitably have to edit it then. Grok only does this simple code generation for project setup: grokproject. The Grok project at present does not do anything else with code generation, and I think we should avoid this in the core project at present. Grok aims to reduce repetition quite aggressively, and it'd be much easier to accept such repetition if we had a code generator. I think that would be wrong, as in the end, for most projects, people will have to work with that Python code. In addition, we of course aim to support fully the use case of development *without* a code generator. While AGX-style code generation is one way to make things easier for people, I'd want such a code generator to produce extremely trivial Grok code. The main reason to use something like AGX should be because: * a UML style UI works better for some people * there's simply a *lot* of models to work with and the UI can help here. Not all complicated development projects have these requirements though. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Max M wrote: Martin Aspeli skrev: Peter Bengtsson wrote: Will the grok effort yield any codegenerating scripts and stuff like the django folks have? If not, I have some ideas that I could maybe contribute with at/for the next sprint even :) Code generation sucks. :) (I know it is late to participate in this thread, but I am reading up on grok.) I used to have the above opinion too. But I have changed my mind. A good framework will get you up and running with as little resistance as possible. But actual real-life projects will often need a lot of files, configuration and settings. So you might start out mean and lean, but after you are done fixing all the little special cases and customizations, you will still have a lot of code. If all that code you end up with anyway is automatically generated, it will have an educational effect on the community. A Code by Numbers effect where you fill in code in the obvious slots. That presumes that the framework is omniscient / presient enough to leave slots in place to allow the customizaitons you want. I *hate* fighing some UID-generateing architecture (wiggling the wires) to get the customer's desired UI. Just see how easy it is to check out other peoples AT based code in Plone. Simply because everyone are acustomed to the structures and conventions. I think you just proved Martin's point: in my experience, maintaining other people's AT-based code is like Napoleon before Moscow: thigh deep in freezing mud. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGKM+2+gerLs4ltQ4RAlqyAJ9/5MlxmBy+nAYJUkmrrtCPt0aHMwCeOr3X T0RmJNDsVnTMl4iARwFtL2E= =Q4CN -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
Rocky Burt wrote:
On Wed, 2007-10-01 at 11:09 -0500, Tres Seaver wrote:
While I am vehemently opposed to code generation per se, one alternative
which I think is important is to generate stuff *at runtime* from
artifacts which are more understandable to business users than Python
code. E.g., they might specify schema in a spreadsheet, an HTML form,
or a UML diagram, which we then use to create a schema interface (my
'userschema' package[1] does this already for the first two).
Not sure which mailing list my questions belong on but for the time
being I'll ask them here (any list subscribers feel free to tell me to
take this discussion offline).
This userschema package looks very cool and it's nice to see all the
cool ways you can produce schema's from user contributed data (ie csv,
html). But I'm curious to know what sort of use cases you have for the
end-result schema's ... simple formlib form generation? content type +
edit form (via formlib) generation?
Obviously generated UI is the main use-case; I have some notions about
making it easier to use schema stuff from within custom UI, but they
aren't fleshed out yet.
I do have a notion of allowing the template which *specifies* the schema
to be used to *render* its fields, but haven't got that part working
yet. Chris McDonough and I have talked about using a meld3-based
approach to that, as well.
(Sorry to follow up to myself, and so late).
While at the BBQ sprint last month, Philipp and I worked on a prototype
for this last idea. Although it isn't cleaned up yet for a release, the
essence of it is to put the 'index' and 'edit' templates (hand-rolled,
of course) into the appropriate subdirectory, and then use a new grok
directive to get the class and all its views wired up. E.g.::
$ cat simple_templates/index.pt
html
body
div tal:content=structure context/body | nothing
BODY
/div
/body
/html
$ cat simple_templates/edit.pt
html
body
form name=simple_edit action=. method=POST
fieldset id=body_fs
legendSimple Body/legend
textarea id=doc_body name=body rows=20 cols=80
tal:attributes=name view/widget/body/name|default
tal:content=view/widgets/body/_getFormValue/textarea
/fieldset
div
input type=submit name=form.submitted value= Save Changes
tal:repeat=action view/actions
tal:attributes=name action/__name__;
value action/label /
/div
/form
/body
/html
$ cat app.py
import grok
import grok_crud
from zope.formlib import form
class SimpleApp(grok.Application, grok.Container):
pass
class Index(grok.View):
grok.context(SimpleApp)
class Simple(grok_crud.Crud):
grok_crud.directory('simple')
With something like meld3, we could even get rid of the hairy TALES
expressions in the tmeplates, making them purely the domain of the designer.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGKNxM+gerLs4ltQ4RAu0AAJ9/l7K9l5TkMLCOAp/rdExACfpItACgxRpq
X4p0vh6t5WKEJPmihBjf3qo=
=CHwU
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
Martin Aspeli skrev: Peter Bengtsson wrote: Will the grok effort yield any codegenerating scripts and stuff like the django folks have? If not, I have some ideas that I could maybe contribute with at/for the next sprint even :) Code generation sucks. :) (I know it is late to participate in this thread, but I am reading up on grok.) I used to have the above opinion too. But I have changed my mind. A good framework will get you up and running with as little resistance as possible. But actual real-life projects will often need a lot of files, configuration and settings. So you might start out mean and lean, but after you are done fixing all the little special cases and customizations, you will still have a lot of code. If all that code you end up with anyway is automatically generated, it will have an educational effect on the community. A Code by Numbers effect where you fill in code in the obvious slots. Just see how easy it is to check out other peoples AT based code in Plone. Simply because everyone are acustomed to the structures and conventions. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
Martin Aspeli skrev: If you're talking about ArchGenXML, which generates AT code from UML, it's not too bad. The code it generates is pretty clean, and if you decide to abandon code generation, there's a minimum of cruft (mostly a few comment blocks) that you can remove if you wish. Yes. I was unclear. Sorry. I meant AGX. I use it for getting a project skeleton up and running quickly from simple UML. Something similar for Zope3 would be with me. Where the interfaces, classes, zcml and views would be generated from UML. But I will try out Grok, and see how the shoe fits before rambling on. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Grok sprint 2 reports
Hi, Am Mittwoch, den 10.01.2007, 00:44 + schrieb Martin Aspeli: Code generation sucks. :) But: - ArchGenXML (hacky though it is) is great for business types because it takes UML (which business analysts understand and customers can be talked through) and produces content types they can CRUD with. Seriously, I've seen people sell big Plone jobs on AGX (kinda scary). - Don't invent a new code generator. Please. :) PasteScript does quite well, and seems to be adopted by others, e.g. Pylons. We already use it to make new egg-like packages for Plone. - You should never, ever *need* code generation. It should be a nice way of getting a common structure for second-order stuff like documentation files and egg metadata (how we use ZopeSkel/paster in Plone), or a way of going from a visual representation to code. Systems that *depend* on generators are always nasty to maintain, upgrade and understand. Tools are just not a replacement for good language design (this is why we see the Java-Rails exodus cliche, and then people realise Rails has tools too, oh well). We've been talking a bit about using Paste to create initial project environments (e.g. bootstrap a buildout that has grok and Zope 3 in it and setup your subversion environment). This is one of the things on our 1.0 list ... Have a look at launchpad.net/grok for more. Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
Martin Aspeli wrote: Peter Bengtsson wrote: Philipp has posted a blog entry with a good example of Grok code: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2007_01_09_you-thought-zope-3-wasn Gorgeous! I especially like that you don't have to manually define the template since it's picked up automatically by name. Will the grok effort yield any codegenerating scripts and stuff like the django folks have? If not, I have some ideas that I could maybe contribute with at/for the next sprint even :) Code generation sucks. :) I agree. I'll highlight what you say below: - You should never, ever *need* code generation. I think the language/library/framework should be powerful enough to write things down quickly without the need for code generation. Code generation where the end result is something that is expected to be read or modified by humans is generally bad, unless it's just about quickly setting up an empty project. We will be looking into this for Grok. But: - ArchGenXML (hacky though it is) is great for business types because it takes UML (which business analysts understand and customers can be talked through) and produces content types they can CRUD with. Seriously, I've seen people sell big Plone jobs on AGX (kinda scary). Yes, and even though I think everything I said above is true, I also think that tools like ArchGenXML can be valuable. I just don't want such a tool to be a way to generate repetitive bad code, as usually I'll be working on the level of the code. If there is to be tools, I want a tool like that that can generate clean non-repetitive code. That is, I don't want a tool to become an excuse to say: oh this code can be repetitive and unwieldy, it's just you use a tool to generate it anyway. - Don't invent a new code generator. Please. :) PasteScript does quite well, and seems to be adopted by others, e.g. Pylons. We already use it to make new egg-like packages for Plone. Agreed. We're looking into PasteScript, I believe. Philipp has been looking into this. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
Philipp von Weitershausen wrote: Martijn Faassen wrote: - Don't invent a new code generator. Please. :) PasteScript does quite well, and seems to be adopted by others, e.g. Pylons. We already use it to make new egg-like packages for Plone. Agreed. We're looking into PasteScript, I believe. Philipp has been looking into this. Yes. These efforts are actually getting somewhere, thanks to Ian's help last night. Cool! Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Martin Aspeli wrote: Peter Bengtsson wrote: Philipp has posted a blog entry with a good example of Grok code: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2007_01_09_you-thought-zope-3-wasn Gorgeous! I especially like that you don't have to manually define the template since it's picked up automatically by name. Will the grok effort yield any codegenerating scripts and stuff like the django folks have? If not, I have some ideas that I could maybe contribute with at/for the next sprint even :) Code generation sucks. :) I agree. I'll highlight what you say below: - You should never, ever *need* code generation. I think the language/library/framework should be powerful enough to write things down quickly without the need for code generation. Code generation where the end result is something that is expected to be read or modified by humans is generally bad, unless it's just about quickly setting up an empty project. We will be looking into this for Grok. While I am vehemently opposed to code generation per se, one alternative which I think is important is to generate stuff *at runtime* from artifacts which are more understandable to business users than Python code. E.g., they might specify schema in a spreadsheet, an HTML form, or a UML diagram, which we then use to create a schema interface (my 'userschema' package[1] does this already for the first two). But: - ArchGenXML (hacky though it is) is great for business types because it takes UML (which business analysts understand and customers can be talked through) and produces content types they can CRUD with. Seriously, I've seen people sell big Plone jobs on AGX (kinda scary). Yes, and even though I think everything I said above is true, I also think that tools like ArchGenXML can be valuable. I just don't want such a tool to be a way to generate repetitive bad code, as usually I'll be working on the level of the code. If there is to be tools, I want a tool like that that can generate clean non-repetitive code. That is, I don't want a tool to become an excuse to say: oh this code can be repetitive and unwieldy, it's just you use a tool to generate it anyway. - Don't invent a new code generator. Please. :) PasteScript does quite well, and seems to be adopted by others, e.g. Pylons. We already use it to make new egg-like packages for Plone. Agreed. We're looking into PasteScript, I believe. Philipp has been looking into this. [1] http://agendaless.com/Members/tseaver/software/userschema Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFpQ+2+gerLs4ltQ4RAl5rAKDQ0C/V/R6d9m3J3mqwoDUMeeOvPwCgyIbo 0WKDfLV8KnVjUxuAaPvvD3o= =auQd -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
On Wed, 2007-10-01 at 11:09 -0500, Tres Seaver wrote: While I am vehemently opposed to code generation per se, one alternative which I think is important is to generate stuff *at runtime* from artifacts which are more understandable to business users than Python code. E.g., they might specify schema in a spreadsheet, an HTML form, or a UML diagram, which we then use to create a schema interface (my 'userschema' package[1] does this already for the first two). Not sure which mailing list my questions belong on but for the time being I'll ask them here (any list subscribers feel free to tell me to take this discussion offline). This userschema package looks very cool and it's nice to see all the cool ways you can produce schema's from user contributed data (ie csv, html). But I'm curious to know what sort of use cases you have for the end-result schema's ... simple formlib form generation? content type + edit form (via formlib) generation? Regards, Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rocky Burt wrote: On Wed, 2007-10-01 at 11:09 -0500, Tres Seaver wrote: While I am vehemently opposed to code generation per se, one alternative which I think is important is to generate stuff *at runtime* from artifacts which are more understandable to business users than Python code. E.g., they might specify schema in a spreadsheet, an HTML form, or a UML diagram, which we then use to create a schema interface (my 'userschema' package[1] does this already for the first two). Not sure which mailing list my questions belong on but for the time being I'll ask them here (any list subscribers feel free to tell me to take this discussion offline). This userschema package looks very cool and it's nice to see all the cool ways you can produce schema's from user contributed data (ie csv, html). But I'm curious to know what sort of use cases you have for the end-result schema's ... simple formlib form generation? content type + edit form (via formlib) generation? Obviously generated UI is the main use-case; I have some notions about making it easier to use schema stuff from within custom UI, but they aren't fleshed out yet. I do have a notion of allowing the template which *specifies* the schema to be used to *render* its fields, but haven't got that part working yet. Chris McDonough and I have talked about using a meld3-based approach to that, as well. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFpR3g+gerLs4ltQ4RAtMPAKDIlX5ulm/Q6UquWTO74XKlZXWCTQCeOjli rIT6hvLSWmK8ZGqNiZfoZZQ= =vyeh -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
Martijn Faassen wrote: Hi there, We had a Grok sprint in Germany over the weekend, and we got two reports about it: Rock on :) What is the current state of the art in terms of Grok examples and documentation? What is the best place to look to find out about the latest development techniques and possiiblities? Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
Martin Aspeli wrote: Martijn Faassen wrote: We had a Grok sprint in Germany over the weekend, and we got two reports about it: Rock on :) What is the current state of the art in terms of Grok examples and documentation? What is the best place to look to find out about the latest development techniques and possiiblities? Currently we suck at examples and documentation. We have some partially out of date design notes in 'doc'. We also have a lot of tests under src/grok/ftests and src/grok/tests which go into many situations, but those are not really good documentation by themselves as we spend a huge amount of time worrying about potential failure situations and doing good error reporting. The best examples right now are still the grokwiki and the grokblog, also to be found in the checkout. They haven't started using the changes of the very latest sprint yet, so no catalog or security yet, but grokblog uses quite a few features nonetheless, including forms. The good news is that documentation is one of our highest priorities now that we're nearing feature completeness. Feedback would of course be very welcome, either on this list or on grok-dev. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
Martin Aspeli wrote: Martijn Faassen wrote: Hi there, We had a Grok sprint in Germany over the weekend, and we got two reports about it: Rock on :) What is the current state of the art in terms of Grok examples and documentation? What is the best place to look to find out about the latest development techniques and possiiblities? Philipp has posted a blog entry with a good example of Grok code: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2007_01_09_you-thought-zope-3-wasn Thanks Philipp! Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
Martijn Faassen wrote: Martin Aspeli wrote: Martijn Faassen wrote: Hi there, We had a Grok sprint in Germany over the weekend, and we got two reports about it: Rock on :) What is the current state of the art in terms of Grok examples and documentation? What is the best place to look to find out about the latest development techniques and possiiblities? Philipp has posted a blog entry with a good example of Grok code: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2007_01_09_you-thought-zope-3-wasn That looks really promising, looking forward to get more impressions from Phillip at the snowsprint. Jürgen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Grok sprint 2 reports
Philipp has posted a blog entry with a good example of Grok code: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2007_01_09_you-thought-zope-3-wasn Gorgeous! I especially like that you don't have to manually define the template since it's picked up automatically by name. Will the grok effort yield any codegenerating scripts and stuff like the django folks have? If not, I have some ideas that I could maybe contribute with at/for the next sprint even :) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
Peter Bengtsson wrote: Philipp has posted a blog entry with a good example of Grok code: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2007_01_09_you-thought-zope-3-wasn Gorgeous! I especially like that you don't have to manually define the template since it's picked up automatically by name. Will the grok effort yield any codegenerating scripts and stuff like the django folks have? If not, I have some ideas that I could maybe contribute with at/for the next sprint even :) Code generation sucks. :) But: - ArchGenXML (hacky though it is) is great for business types because it takes UML (which business analysts understand and customers can be talked through) and produces content types they can CRUD with. Seriously, I've seen people sell big Plone jobs on AGX (kinda scary). - Don't invent a new code generator. Please. :) PasteScript does quite well, and seems to be adopted by others, e.g. Pylons. We already use it to make new egg-like packages for Plone. - You should never, ever *need* code generation. It should be a nice way of getting a common structure for second-order stuff like documentation files and egg metadata (how we use ZopeSkel/paster in Plone), or a way of going from a visual representation to code. Systems that *depend* on generators are always nasty to maintain, upgrade and understand. Tools are just not a replacement for good language design (this is why we see the Java-Rails exodus cliche, and then people realise Rails has tools too, oh well). Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
