At DrupalCon, a few of us had talked about how handy it would be to have a module that automatically generated "scaffolding" for modules, both to help new developers as well as to speed up the process of creating custom modules for Drupal veterans. As a result of a major bout of insomnia, I am pleased to announce that Module Builder Module 1.0 has been committed to CVS, and even pretty much works! ;) You can check it out at: http://cvs.drupal.org/viewcvs/drupal/contributions/modules/module_builder/ WARNING: This module was a lot of 3am++ code and regular expressions, which as we all know is a deadly combination, so please be kind. ;) There's obviously a lot more that can be done with this than what's there now, but I figured I would post this anyway so people can see how it works so far. Jeff Robbins also created a wireframe (which I tried to use as inspiration to the extent that I could) of how he envisions this working in later revisions, which you can see in my sandbox here (warning: PDF): http://cvs.drupal.org/viewcvs/*checkout*/drupal/contributions/sandbox/webchi... Anyway, enjoy! -Angie
Angie Byron wrote:
As a result of a major bout of insomnia, I am pleased to announce that Module Builder Module 1.0 has been committed to CVS, and even pretty much works! ;)
Cool.
WARNING: This module was a lot of 3am++ code and regular expressions, which as we all know is a deadly combination, so please be kind. ;)
I could only find this minor issue: $form['module_short_description'] = array( vs. '%description' => $edit['module_description'], Combined with Jeff's ideas this could turn out to be a really useful tool. Med venlig hilsen / Kind regards, Morten Wulff -- Self Injury Information and Support: http://www.psyke.org/ "I did not, you see, want to kill myself. Not at that time, anyway. But I wanted to know that if need be, if the desperation got so terribly bad, I could inflict harm on my body. And I could." - Elizabeth Wurtzel
Angie Byron wrote:
At DrupalCon, a few of us had talked about how handy it would be to have a module that automatically generated "scaffolding" for modules, both to help new developers as well as to speed up the process of creating custom modules for Drupal veterans.
As a result of a major bout of insomnia, I am pleased to announce that Module Builder Module 1.0 has been committed to CVS, and even pretty much works! ;) You can check it out at:
Anyway, enjoy!
-Angie
Yay! I hope to get a chance to try it out later this week. ..chris
Pity. I announced on all the MLs, several times that I was working on this. Our code differs rather a lot, so I think we will have two in a few weeks :) the use and methods of mine are shaped after RoR. http://drupal.org/project/sympal_scripts http://drupal.org/node/47364 Ber On Tue, February 21, 2006 14:26, Angie Byron wrote:
At DrupalCon, a few of us had talked about how handy it would be to have a module that automatically generated "scaffolding" for modules, both to help new developers as well as to speed up the process of creating custom modules for Drupal veterans.
As a result of a major bout of insomnia, I am pleased to announce that Module Builder Module 1.0 has been committed to CVS, and even pretty much works! ;) You can check it out at:
http://cvs.drupal.org/viewcvs/drupal/contributions/modules/module_builder/
WARNING: This module was a lot of 3am++ code and regular expressions, which as we all know is a deadly combination, so please be kind. ;)
There's obviously a lot more that can be done with this than what's there now, but I figured I would post this anyway so people can see how it works so far.
Jeff Robbins also created a wireframe (which I tried to use as inspiration to the extent that I could) of how he envisions this working in later revisions, which you can see in my sandbox here (warning: PDF):
http://cvs.drupal.org/viewcvs/*checkout*/drupal/contributions/sandbox/webchi...
Anyway, enjoy!
-Angie
--
On 2/21/06, Ber Kessels <ber@webschuur.com> wrote:
Pity. I announced on all the MLs, several times that I was working on this. Our code differs rather a lot, so I think we will have two in a few weeks :) the use and methods of mine are shaped after RoR.
I read your descriptions of sympal on ML and your blog and didn't see the module scaffolding as a feature of it - I think it was easy to miss. Also, I don't see the pity about duplication of efforts on this. AFAIK, Drupal Module generation is a relatively new idea and having multiple implementations of new ideas can be a good thing. I look forward to testing/using both of these. Regards, Greg
On Tue, 2006-02-21 at 12:55 -0700, Greg Knaddison wrote:
On 2/21/06, Ber Kessels <ber@webschuur.com> wrote:
Pity. I announced on all the MLs, several times that I was working on this. Our code differs rather a lot, so I think we will have two in a few weeks :) the use and methods of mine are shaped after RoR.
I read your descriptions of sympal on ML and your blog and didn't see the module scaffolding as a feature of it - I think it was easy to miss.
Also, I don't see the pity about duplication of efforts on this. AFAIK, Drupal Module generation is a relatively new idea and having multiple implementations of new ideas can be a good thing.
I look forward to testing/using both of these.
Regards, Greg
While I think there is some merit to building a module skeleton generator. I've found over time it is just quicker to write a module ground-up than to go through wizards to create a module skeleton.(You mileage may vary...) To me a more useful end, and I'm not sure if you're thinking in this direction, is using the module skeleton generator as a basis for a real module builder that can convert CCK content types and VIEWS to first class modules, and provide data migration routines. I think cck and views are god sends, but I don't think they are ideal for sites that hope to get hit hard and heavy, where more normalized table structures, and less code abstraction can make a big difference. The again the time and memory used for 20 custom modules(loading and compiling included) may be more than that used by 1 cck module with 20 content type definitions and associated views. .darrel.
I think cck and views are god sends, but I don't think they are ideal for sites that hope to get hit hard and heavy, where more normalized table structures, and less code abstraction can make a big difference.
Time to market, cost of development, cost of maintenance (custom module vs. community maintained views/cck) are also factors besides sheer performance.
On Tue, 2006-02-21 at 22:21 +0100, Karoly Negyesi wrote:
I think cck and views are god sends, but I don't think they are ideal for sites that hope to get hit hard and heavy, where more normalized table structures, and less code abstraction can make a big difference.
Time to market, cost of development, cost of maintenance (custom module vs. community maintained views/cck) are also factors besides sheer performance.
I just want to have my cake and ice cream... I'd like to take advantage of all the RAD stuff provided by CCK & Views, set up my site and content types, and views.... Down the road we start getting bigger... We start getting 200-300K hits an hour... I hit the convert to module button, and have a module that provides the behavior of my defined views and content types, with less abstraction, hopefull less time in code as a result... Down the road we want to add a new attribute to content type z, so we revert the site to a CCK/Views site... (definitions should still be stored, just need to back port all my data.) I update my content definitions and views, recompile my module and voila.. Its a strange fantasy I know... .darrel.
That's the dream. Write it. Don't forget the part where the Optimize button changes the database schema to the most performant for your use case.
On Tue, 2006-02-21 at 22:21 +0100, Karoly Negyesi wrote:
I think cck and views are god sends, but I don't think they are ideal for sites that hope to get hit hard and heavy, where more normalized table structures, and less code abstraction can make a big difference.
Time to market, cost of development, cost of maintenance (custom module vs. community maintained views/cck) are also factors besides sheer performance.
I just want to have my cake and ice cream...
I'd like to take advantage of all the RAD stuff provided by CCK & Views, set up my site and content types, and views.... Down the road we start getting bigger... We start getting 200-300K hits an hour... I hit the convert to module button, and have a module that provides the behavior of my defined views and content types, with less abstraction, hopefull less time in code as a result...
Down the road we want to add a new attribute to content type z, so we revert the site to a CCK/Views site... (definitions should still be stored, just need to back port all my data.) I update my content definitions and views, recompile my module and voila..
Its a strange fantasy I know...
.darrel.
On Tue, 2006-02-21 at 15:35 -0600, John VanDyk wrote:
That's the dream. Write it.
Don't forget the part where the Optimize button changes the database schema to the most performant for your use case.
We'll need to do some user path tracking to help the ml algorithms determine the optimum schema for the sites traffic patterns. ;).. Yeah I have been thinking of that... The idea started as flexinode2node.... I thought I'd committed a partial to CVS at some point, but yeah it does have a mysql schema generator. Its not that intelligent and pretty brute force... .darrel.
Op dinsdag 21 februari 2006 22:35, schreef John VanDyk:
Don't forget the part where the Optimize button changes the database schema to the most performant for your use case.
If it were not a [button] but a commandline script: optimise_database.php It can be finished by tomorrow. Its on my todolist, way down, but definately on. :) -- [ Bèr Kessels | Drupal services www.webschuur.com ]
While I think there is some merit to building a module skeleton generator. I've found over time it is just quicker to write a module ground-up than to go through wizards to create a module skeleton.(You mileage may vary...)
which module skeleton generator did you use that such that it is slower than writing from scratch?
On Tue, 2006-02-21 at 16:36 -0500, Moshe Weitzman wrote:
While I think there is some merit to building a module skeleton generator. I've found over time it is just quicker to write a module ground-up than to go through wizards to create a module skeleton.(You mileage may vary...)
which module skeleton generator did you use that such that it is slower than writing from scratch?
Not necessarily module generators for drupal, but various code generators. Whether it was something as simple as phpCodeGenie just to spit out some data objects, or more complete UML suites, or code I've written to automate plugin generation for other front controllers I've written.. I've never really found 'skeleton' generation very useful. but that is me your mileage may very...
Darrel O'Pry wrote:
I think cck and views are god sends, but I don't think they are ideal for sites that hope to get hit hard and heavy, where more normalized table structures, and less code abstraction can make a big difference.
The again the time and memory used for 20 custom modules(loading and compiling included) may be more than that used by 1 cck module with 20 content type definitions and associated views.
Please be aware that both CCK and Views attempt to aggressively cache their data. Meaning that reading a CCK node is a single load from cache. Views, likewise, tries to cache the actual query used. (it's not always possible, queries with arguments simply aren't cacheable). But the query builder is actually remarkably more efficient than I had given it credit for -- the query builder took only slightly more time off of a page than it took to build the user login form when I was profiling it.
Views, likewise, tries to cache the actual query used. (it's not always possible, queries with arguments simply aren't cacheable). But the query builder is actually remarkably more efficient than I had given it credit for -- the query builder took only slightly more time off of a page than it took to build the user login form when I was profiling it.
Earl - have a look at prepared statements and mysqli. could be a nice speed improvement for those who use that DB layer. Skips the query plan step.
Op dinsdag 21 februari 2006 22:08, schreef Darrel O'Pry:
I think cck and views are god sends, but I don't think they are ideal for sites that hope to get hit hard and heavy, where more normalized table structures, and less code abstraction can make a big difference.
All my scripts are build from Ruby on Rails ideas: "scripts/generate Coffee" builds me all the (working!) code to start extending/customising my coffee website in RoR. Play with it once, you will be impressed! Part of my scripting plans are to hook into the themes: adding a node: "generate.php example.com node" MyType will make sites/example.com/modules/MyType/MyType.module sites/example.com/themes/example_com_custom/node-MyType.tpl.php But, because it is all RoR inspired, the next step is to (ab)use the views export (and most certainly cck if it gets extraction features) to "extract_views.php example.com" should add code to sites/example.com/modules/custom_views/example_com_custom_views.module [*] example_com is dealt with nicer, in reality, I have partly built a smart-namer that makes nicer names out of the domain, renaming it into example or of example.org already exists "examplec" etc. -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Ber Kessels wrote:
Pity. I announced on all the MLs, several times that I was working on this. Our code differs rather a lot, so I think we will have two in a few weeks :)
Sorry. The idea came up at lunch @ DrupalCon with a few people and I talked to maybe a dozen or so others too and never got the idea that someone else was working on something like this. :\ I think it's okay though... as you say in the project description: "It is certainly not meant for Joe Weblog, for it requires one to run PHP commands on the server." Mine is kind of geared more toward that "Joe Weblog," in that ideally it's a simple interface that makes it easy for newbie developers to create custom modules (and learn something about how Drupal works in the process), and yet it also has the ability to provide a nice short-cut for people who already know what they're doing. As you can (hopefully) see from the template file, my focus is on finding best practices on hook implementation and defining 'smart' skeleton code while at the same time also inline-documenting what else is possible. It's intended to be a teaching tool as much as a development tool. So I do think there is room for both, and I assure you that no offense was intended. :) Btw, another round of bug fixes just went in. Will probably not be able to look at this again now before the weekend, though. Thanks everyone for the feedback! -Angie
Op dinsdag 21 februari 2006 22:20, schreef Angie Byron:
So I do think there is room for both, and I assure you that no offense was intended. :)
oh, no offence taken! I was a bit surprised, that even with all the noise i made around these scripts, stuff is still dulpicated.
Btw, another round of bug fixes just went in. Will probably not be able to look at this again now before the weekend, though. Thanks everyone for the feedback!
I like your implementation. I am now investigating how to re-use part of your cde without forking :). I have also skinned down my implementation, to the last working one, so that i can at least commit it :) However, my implmentations are not for "Joe Weblog", no. But without any effort, you can use it very well, still. Since it is all aimed at being tools. We, for example, have this tied into dischosting, a provisioning system. OUr dischosting system calls all the commands and thus provides a nice interface for all this. Far future plans are to turn dischosting slowly into drupal modules. -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
On Tue, 2006-02-21 at 08:26 -0500, Angie Byron wrote:
At DrupalCon, a few of us had talked about how handy it would be to have a module that automatically generated "scaffolding" for modules, both to help new developers as well as to speed up the process of creating custom modules for Drupal veterans.
Great work Angie!! The integration of DrupalDocs into this will hopefully encourage contrib developers to really use/understand the Drupal API - and also document their own modules! Under 'Module root name:' the help text might want to add that for modules that might get added to drupal.org it is good to reserve the namespace at http://drupal.org/node/add/project_project (nothing worse than writing a big module then finding the name is taken!). Also maybe point out that modules can (I think) conflict with themes with the same name. I'll try and hack out a 'module type' js/ajax autoselector when I find some spare time :) On Wed, 2006-02-22 at 10:42 +0100, Bèr Kessels wrote:
However, my implmentations are not for "Joe Weblog", no. But without any effort, you can use it very well, still. Since it is all aimed at being tools. We, for example, have this tied into dischosting, a provisioning system. OUr dischosting system calls all the commands and thus provides a nice interface for all this. Far future plans are to turn dischosting slowly into drupal modules.
Ber: I have been thinking along the same lines. For these kinds of toolkit modules/scripts (i.e. aimed at developers and/or site admins) it would be great to work out a system where a tool (e.g. generating a skeleton module) could easily share the same guts between a standard drupal front end and a snappy sympal scripts command line front end. Maybe this is possible already, but if you have any suggestions as to how this could be wired together that would be great. Thanks! - Owen
On Tuesday 21 February 2006 07:26, Angie Byron wrote:
At DrupalCon, a few of us had talked about how handy it would be to have a module that automatically generated "scaffolding" for modules, both to help new developers as well as to speed up the process of creating custom modules for Drupal veterans.
As a result of a major bout of insomnia, I am pleased to announce that Module Builder Module 1.0 has been committed to CVS, and even pretty much works! ;) You can check it out at:
OK, I've not actually looked at it yet, so I can't comment on how good/late-night the code is, but my knee-jerk reaction is that I don't like code generation in the first place. If the code is sufficiently boilerplate that it can be auto-generated, then it's sufficiently boilerplate that it should be written as a single routine and called with paramters. That's the logic behind functions and variables. :-) As a for-instance: hook_load(), hook_insert(), and hook_update() are horribly redundant. All three do the same thing in almost any node. They select/insert/delete fields from a table, using almost the same code. Sometimes there will be an extra table to manipulate, but there's still almost always a basic node++ table. And the fields have to be specified in all of them. Ick! The solution, however, isn't to have something that auto-generates those functions. It's to let the module define the table and fields once and then let node.module handle the basic S-I-D. Save those hooks for stuff that's actually interesting, and reduce the amount of code, too. I'm thinking something like: nodename_fields() { return array('nodenametable' => array('field1', 'field2', 'field3')); } That would also allow node_load() to return an "empty node" of the correct type, which would help with E_ALL compliance. (Yes, this is something I've been thinking about for some time, but have been holding back on actually trying to implement because I didn't want to introduce a change of that size when we've been "almost ready to get 4.7 out the door" since, uh, November. Hi, Ber! <g> I actually did something very similar to this at work, so I know it can be done.) So yeah, code generation in general gets a -1 for me in favor of more powerful and generalized polymorphic code. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Larry Garfield wrote:
OK, I've not actually looked at it yet, so I can't comment on how good/late-night the code is, but my knee-jerk reaction is that I don't like code generation in the first place.
As a for-instance:
hook_load(), hook_insert(), and hook_update() are horribly redundant. All three do the same thing in almost any node. They select/insert/delete fields from a table, using almost the same code. Sometimes there will be an extra table to manipulate, but there's still almost always a basic node++ table. And the fields have to be specified in all of them. Ick!
So yeah, code generation in general gets a -1 for me in favor of more powerful and generalized polymorphic code.
Well, I'm all about generalized, abstracted, objectified database access -- and I'm writing such a class library for my employer right now. However, I'm still very pleased with Angie's module. It's a great tool for sketching a new module so that one doesn't forget to code the hooks it needs. And it is similarly instructional, teaching programmers about how to develop Drupal modules. Moreover, to hack the quote from Donald Rumsfeld, the US secretary of defense: one codes to the core hooks one has at the moment, not to what one would like to have. Sure, go ahead and develop a "more powerful and generalized polymorphic code" for the core hooks, and get them committed to core, so that module generation is less valuable. In the meantime, this module is a great tool. If you don't like it, don't use it. :-) ..chrisxj
Larry Garfield wrote:
On Tuesday 21 February 2006 07:26, Angie Byron wrote:
At DrupalCon, a few of us had talked about how handy it would be to have a module that automatically generated "scaffolding" for modules, both to help new developers as well as to speed up the process of creating custom modules for Drupal veterans.
As a result of a major bout of insomnia, I am pleased to announce that Module Builder Module 1.0 has been committed to CVS, and even pretty much works! ;) You can check it out at:
OK, I've not actually looked at it yet, so I can't comment on how good/late-night the code is, but my knee-jerk reaction is that I don't like code generation in the first place. If the code is sufficiently boilerplate that it can be auto-generated, then it's sufficiently boilerplate that it should be written as a single routine and called with paramters. That's the logic behind functions and variables. :-)
As a for-instance:
hook_load(), hook_insert(), and hook_update() are horribly redundant. All three do the same thing in almost any node. They select/insert/delete fields from a table, using almost the same code. Sometimes there will be an extra table to manipulate, but there's still almost always a basic node++ table. And the fields have to be specified in all of them. Ick!
The solution, however, isn't to have something that auto-generates those functions. It's to let the module define the table and fields once and then let node.module handle the basic S-I-D. Save those hooks for stuff that's actually interesting, and reduce the amount of code, too.
I'm thinking something like:
nodename_fields() { return array('nodenametable' => array('field1', 'field2', 'field3')); }
That would also allow node_load() to return an "empty node" of the correct type, which would help with E_ALL compliance.
(Yes, this is something I've been thinking about for some time, but have been holding back on actually trying to implement because I didn't want to introduce a change of that size when we've been "almost ready to get 4.7 out the door" since, uh, November. Hi, Ber! <g> I actually did something very similar to this at work, so I know it can be done.)
So yeah, code generation in general gets a -1 for me in favor of more powerful and generalized polymorphic code.
This is the most idiotic post I have read on this list so far. It starts with "I've not actually looked at it yet"... Well, if you haven't looked at it, why do you comment on it ? Do we care if you like code generation or not ? Do we care if you like "powerful and generalized polymorphic code" ? That's not the topic I think. This module is about building a module skeleton to make developers job easier. How do you think PHP extensions are written ? People use ext_skel or pecl CodeGen and it saves them a lot of time and makes it more fun to hack something fast. That's one thing that largely contributed to PHP success. I am personally very thankful to the people who wrote Module_builder and will start to use it straight away even if it's not "powerful and generalized polymorphic code" :p -- Bertrand Mansion http://www.mamasam.com - creative internet solutions http://golgote.freeflux.net - blog
On Wednesday 22 February 2006 02:30, Bertrand Mansion wrote:
OK, I've not actually looked at it yet, so I can't comment on how good/late-night the code is, but my knee-jerk reaction is that I don't like code generation in the first place. If the code is sufficiently boilerplate that it can be auto-generated, then it's sufficiently boilerplate that it should be written as a single routine and called with paramters. That's the logic behind functions and variables. :-)
*snip*
So yeah, code generation in general gets a -1 for me in favor of more powerful and generalized polymorphic code.
This is the most idiotic post I have read on this list so far. It starts with "I've not actually looked at it yet"... Well, if you haven't looked at it, why do you comment on it ? Do we care if you like code generation or not ? Do we care if you like "powerful and generalized polymorphic code" ? That's not the topic I think. This module is about building a module skeleton to make developers job easier.
Well good morning to you, too. I was commenting specifically on the concept of code generation, rather than this specific code generator. I stated as such up-front. I view it as a bandaid. A better long-term solution is to make the code more general so that you don't need a code generator in the first place. If you disagree, try giving a reason instead of being insulting.
How do you think PHP extensions are written ? People use ext_skel or pecl CodeGen and it saves them a lot of time and makes it more fun to hack something fast. That's one thing that largely contributed to PHP success.
Having never written a PECL extension, I really couldn't say.
I am personally very thankful to the people who wrote Module_builder and will start to use it straight away even if it's not "powerful and generalized polymorphic code" :p
Great. You do that. I'll wait until HEAD unfreezes and then see if I can dig up the time to make it (or portions of it) unnecessary, or others are welcome to do so as well. I really don't see where you need to get nasty about it. I wasn't saying Angie et al did anything wrong, just that I don't think it's a good long-term approach. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
So yeah, code generation in general gets a -1 for me in favor of more powerful and generalized polymorphic code.
This is the most idiotic post I have read on this list so far. It starts with "I've not actually looked at it yet"... Well, if you haven't looked at it, why do you comment on it ? Do we care if you like code generation or not ? Do we care if you like "powerful and generalized polymorphic code" ? That's not the topic I think. This module is about building a module skeleton to make developers job easier.
Well good morning to you, too.
I was commenting specifically on the concept of code generation, rather than this specific code generator. I stated as such up-front. I view it as a bandaid. A better long-term solution is to make the code more general so that you don't need a code generator in the first place.
Well, I cheered loudly when I read Bertrand's post. I think the core issue is that your personal opinion of code generators and how they are inferior to "powerful and generalized polymorphic code" is off topic for this thread. Angie is announcing a cool module and it is annoying to have cold water thrown upon it. i also think you are wrong about the insert/update/load hooks because modules do different things in each. You might change your mind once you start implementing your ideas in a few core and contrib modules.
Larry Garfield wrote:
I am personally very thankful to the people who wrote Module_builder and will start to use it straight away even if it's not "powerful and generalized polymorphic code" :p
Great. You do that. I'll wait until HEAD unfreezes and then see if I can dig up the time to make it (or portions of it) unnecessary, or others are welcome to do so as well.
I really don't see where you need to get nasty about it. I wasn't saying Angie et al did anything wrong, just that I don't think it's a good long-term approach.
Sorry, I might have overreacted to your negative unrelated post about a positive initiative :) But if you are planning to do something positive as well, it's perfect. With code, it's always easier to talk about something than to actually do something... Your idea seems good but doesn't look easy to implement and would mean a major change in Drupal spaghetti code. I don't see how it could fit without rewriting major portions of code both in core and in modules. And in the end, you might as well end up with limited functionality and an implementation that requires hacks to let you do what you want. If it's working, don't fix it :) Anyway, good luck. -- Bertrand Mansion http://www.mamasam.com - creative internet solutions http://golgote.freeflux.net - blog
Larry Garfield wrote:
On Tuesday 21 February 2006 07:26, Angie Byron wrote:
As a result of a major bout of insomnia, I am pleased to announce that Module Builder Module 1.0 has been committed to CVS, and even pretty much works! ;) You can check it out at:
As a for-instance:
hook_load(), hook_insert(), and hook_update() are horribly redundant.
"I am the world" logic. A module builder module scaffolds. That *you* don't want to then amend hook_load &c to also do other things does not mean the functions are redundant :) jh
Op woensdag 22 februari 2006 05:40, schreef Larry Garfield:
So yeah, code generation in general gets a -1 for me in favor of more powerful and generalized polymorphic code.
What about them co-existing? Look at Ruby on Rails. Part of its success is the code generation (aka agile web development) the other part is DRY (do not repeat yourself). The way you state it, RoR could not exist :) We can generate code that is used as *scaffold*, used to have certain files made, directories set, data inserted, and yes, some default functions prefilled. we can do that, on top of less repetition in our modules (oh, how i would love to see any node type get "view %type", "create %type" permissions by default). I see your point in this repetition thing, but its a separate issue from code generation. Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
participants (15)
-
Angie Byron -
Ber Kessels -
Bertrand Mansion -
Bèr Kessels
-
Chris Johnson -
Darrel O'Pry -
Earl Miles -
Greg Knaddison -
John Handelaar -
John VanDyk -
Karoly Negyesi -
Larry Garfield -
Morten Wulff -
Moshe Weitzman -
Owen Barton