- Development - lists.drupal.org

Re: [development] module_exist() / module_exists()
by Konstantin Käfer 01 Sep '06

01 Sep '06

Well, the bad thing about wrapper functions is that people won't change them if it is not necessary. If we take the wrapper function out after the next release, we will face the same problem. 2006/8/31, John VanDyk <jvandyk(a)iastate.edu>: > From http://drupal.org/node/64279#module-exists : > > "module_exist() is now module_exists() > For consistency with PHP function_exists, file_exists, etc. That's > about all there is to say about that. :)" > > From my local copy of cvs: > > $ cd /cvs/contributions/modules > $ grep -r module_exist\( . | wc -l > 630 > > It would be nice to have a wrapper function in for one release cycle. >

4 3

changes to hook_nodeapi
by Peter Wolanin 01 Sep '06

01 Sep '06

Dear developers, A patch was recently committed: http://drupal.org/node/68418 that moves the insert/update/delete operations out of hook_nodeapi. While I realize this was reviewed by a number of more experienced people, I would still like to voice an objection. After trying to use the API after this patch, I think it was not a good idea. I can't see how it improves programmatic submission of nodes- after trying it last night it seems to make it harder. It was argued that this would make the node update/insert/delete process mroe efficienct since only the registered submit sitems in the form are called rather than hook_nodeapi() for all modules. However, I think an approach that would be similer, but much more consistent with the current API, simpler in terms of updating contrib modules, and essentially the same in terms of reducing the # of fucntion calls would be breaking of hook_nodeapi into a series of hooks like hook_nodeapi_view(), hook_nodeapi_load(), hook_nodeapi_update(). This would probably add much more in terms of efficiency than this patch since there are typically many more load, view, etc. operations than update/insert/delete. -Peter

4 3

re: RE: RE: [development] changes to hook_nodeapi
by Peter Wolanin 31 Aug '06

31 Aug '06

Jeff, it seems to me you are saying that this patch needs a patch to restore the functionality present in 4.7... >From my point of view as a relative newcomer to this, the present API for node handling is simple to grasp the logic of. I think this is a key point that is being overlooked- the barrier for entry of new developers and rention of existing ones. If I call node_save() on a node object, but then my data is not saved, that's not logical to me. The hooks into Forms API are not easy to grasp the logic of, even after spending many hours on this. Even without this patch, any developer who *wants* to use the Forms API and submit hooks can. This patch *forces* us, even when it's not appropriate to the data model (as mentioned in a previous post). -Peter >Date: Thu, 31 Aug 2006 11:20:16 -0500 >From: "Jeff Eaton" <jeff(a)viapositiva.net> >Subject: RE: RE: [development] changes to hook_nodeapi >To: <development(a)drupal.org> >Message-ID: <002501c6cd19$5c208770$6700a8c0@JEATON2DEV> ... >> As of this patch, hook_nodapi no longer gets called, for >> example, with $op='update". > >Well... Yes. That was what the patch did. It changed the system to use >form processing hooks for CRUD interaction. It can definitely be said >that there should be an easier way to 'tie in' to those operations. A >specific helper function rather than form_alter, for example. > >--Jeff

6 5

re: RE: [development] changes to hook_nodeapi
by Peter Wolanin 31 Aug '06

31 Aug '06

My issue isn't that programmatic submission needed to be easier, but rather the API for acting on the creation, etc. of nodes. Just got less consistent and harder to use. As of this patch, hook_nodapi no longer gets called, for example, with $op='update". -Peter >Date: Thu, 31 Aug 2006 10:46:18 -0500 >From: "Jeff Eaton" <jeff(a)viapositiva.net> >Subject: RE: [development] changes to hook_nodeapi >To: <development(a)drupal.org> >Message-ID: <000f01c6cd14$9d436ec0$6700a8c0@JEATON2DEV> >Content-Type: text/plain; charset="us-ascii" > >I haven't had a chance to look at the details of the nodeapi patch in >question, but I will say that programmatic submission of data using >forms just got a bit simpler, as http://drupal.org/node/80470 was >committed. It adds a 'drupal_execute()' function that processes forms >without any of the rendering/ui cruft.

7 9

Re: [development] possible theme?
by Ken Rickard 31 Aug '06

31 Aug '06

> http://www.drupalart.org/drupal48/ > Let's avoid talking about the underlying XHTML/CSS: we'll worry about > that in step #2. Instead, let's talk about the aesthetics, the brand > and the message this theme communicates. On a scale from 1-5 (1 = > "Argh, it hurts my eyes", 3 = "I can live with it", 5 = "Exactly what > we need"), what rating would you give this design (not its XHTML/CSS) > and why? 4, Nice, clean, simple. Two changes: I would left-justify the primary links. I don't undertstand why they are floating off the left margin. Please make primary text _black_ #000000. Why designers insist on grey text is beyond my comprehension (and strains my eyes). - Ken Rickard agentrickard

3 2

Re: possible theme?
by Ken Rickard 31 Aug '06

31 Aug '06

Oops. Forgot to edit the subject line. Mea culpa. >> default body text should be _black_ #000000 vs. >Main text color should stay as it is, otherwise it'll lose the affect. Trae, I'm going to really press on this one. What effect? Readability trumps other interface concerns. That's why Google, Yahoo!, Amazon, (and Drupal.org <http://drupal.org/>, and Buytaert.net<http://buytaert.net/>) all use black-on-white. Even Web 2.0 poster-children like Flickr use black-on-white for primary text. The purpose of body text is to be easy and simple to read. For most people, pure black on pure white is the best contrast, the most common, and the easiest. I've had this fight internally at my company as well, as our designers went through a strong "Let's do everything in 6 shades of gray" phase. Any design that deviates from black-on-white can never get a 5 from me. - Ken Rickard agentrickard And for the record, my personal page: http://ken.therickards.com/ Where 'gray' means 'of lesser importance' than the content you want to read.

2 2

Re: development Digest, Vol 44, Issue 148
by Ken Rickard 31 Aug '06

31 Aug '06

>> default body text should be _black_ #000000 vs. >Main text color should stay as it is, otherwise it'll lose the affect. Trae, I'm going to really press on this one. What effect? Readability trumps other interface concerns. That's why Google, Yahoo!, Amazon, (and Drupal.org, and Buytaert.net) all use black-on-white. Even Web 2.0 poster-children like Flickr use black-on-white for primary text. The purpose of body text is to be easy and simple to read. For most people, pure black on pure white is the best contrast, the most common, and the easiest. I've had this fight internally at my company as well, as our designers went through a strong "Let's do everything in 6 shades of gray" phase. Any design that deviates from black-on-white can never get a 5 from me. - Ken Rickard agentrickard And for the record, my personal page: http://ken.therickards.com/ Where 'gray' means 'of lesser importance' than the content you want to read.

1 0

Theme reduction?
by Chris Johnson 31 Aug '06

31 Aug '06

Jeff Eaton wrote: > At absolute worst... Does anyone have feelings about replacing some of > the old-and-crusty additional themes that we include with Drupal? Even > if folks are absolutely desperately attached to bluemarine, how many > folks are there out there who say, "You'll take away Grey Box when you > pry it from my cold, dead, hands?" I like that idea, actually. I use Grey Box all over the place. But all of those sites are on older releases (e.g. 4.4, 4.5). When I upgrade them to 4.7 or 4.8, I fully expect and want to upgrade the theme,too. So if Box Grey were not available, that would be fine with me. Go ahead and blow a few of the old themes out the airlock! :-)

3 3

Usability core patches
by Ralf Stamm 31 Aug '06

31 Aug '06

Hi, here is a list with usability core patches for discuss: Display help text on sub administration pages http://drupal.org/node/81342 Improves the administration of menu items on the page administer >> site building >> menu >> list http://drupal.org/node/81323 http://drupal.org/node/52226 Allow others than uid=1 to run updates http://drupal.org/node/67234 If you know more patches which improve the usability, please add to this list. Thanks, Ralf

3 2

The menu - does it have to be different on each page?
by Gerhard Killesreiter 31 Aug '06

31 Aug '06

Hi there, In my endeavour to have better caching in Drupal. One of the things we already cache is the menu tree for each user. What we cannot cache is the rendered version of this tree (the navigation block) because it changes on each and every page. I was wondering if we need this. Couldn't we always render the complete menu and only hide the pieces we don't want to show through some CSS/JS? Sure, this would put users of non-CSS browsers maybe at an disadvantage, but is it that bad? If you are not an admin the number of additional items is rather small. One problem that has been pointed out is that we add the "active" class to the current menu item. Would there be a way around this? Caching the whole rendered menu block would have some serious performance implications. Cheers, Gerhard

10 10