June 2007 - Development - lists.drupal.org

Re: [development] Date Calc and ADODB date library
by Karen Stevenson 25 Jun '07

25 Jun '07

Thanks for the help. For anyone who is interested, I've gone ahead and opened an issue and proposed a patch at http://drupal.org/node/154477. ----- Original Message ---- From: Moshe Weitzman <weitzman(a)tejasa.com> To: development(a)drupal.org Sent: Friday, June 22, 2007 9:50:33 PM Subject: Re: [development] Date Calc and ADODB date library > And my original question -- does anyone know exactly how I should attribute the original authors and licenses in my Drupalized version? we have at times included 3rd party code in core. these packages served us well for a while but we eventually moved on. perhaps you can go back in time and figure out how we attributed them. i would think this could be done similarly. i agree that this functionality in core would be useful. XML-RPC by Ed Dumbill: http://cvs.drupal.org/viewcvs/drupal/drupal/includes/xmlrpcs.inc?rev=1.9.4.… XTEMPLATE theme system http://cvs.drupal.org/viewcvs/drupal/drupal/themes/xtemplate/xtemplate.inc?… PEAR DB: http://cvs.drupal.org/viewcvs/drupal/drupal/includes/database.pear.inc?hide… The file above was a wrapper around PEAR DB. I think we required people to download it themselves if they wanted it. So perhaps not much help to you.

1 0

openWeek/classrooms on IRC
by Bèr Kessels 25 Jun '07

25 Jun '07

Hello, Interesting to hava a look at: https://wiki.ubuntu.com/UbuntuOpenWeek Ubuntu classrooms. In IRC only, so, indeed, limited ni audience, but the model could be interesting for Drupal, not? Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl

2 1

help with deletion API conversions
by Chad Phillips -- Apartment Lines 24 Jun '07

24 Jun '07

the initial deletion API patch included support for node and comment deletions. the rest of core still needs to be converted to use the API. we have a wiki page up listing all the stuff left to convert, along with links to the patches that have already been written: http://groups.drupal.org/node/4721 please help test the current patches if you can, or help with some of the remaining conversions. here's a link to deletion API documentation, which you'll probably want to read before attempting any conversions: http://drupal.org/node/153904 conversions don't take all that long, and i'm usually around in IRC to help if you get stuck. thanks in advance for any help. :) hunmonk

1 0

Re: [development] Deletion API hits core
by Michelle Cox 24 Jun '07

24 Jun '07

This sounds like a transaction... http://en.wikipedia.org/wiki/Database_transaction Michelle On 6/22/2007 10:23:21 PM, Chad Phillips -- Apartment Lines (chad(a)apartmentlines.com) wrote: sorry about that. i really wasn't sure what else to call it. i'm happy to pick a better name if it avoids confusion. :) package == 'logical set of deletions that happen together' as in, when you delete a node, you also delete the associated comments, associated revisions, etc. they happen as a logical unit. the API keeps the logical units together, and presents the logical units to the hooks so that outside modules may have a look.

2 1

Re: [development] Deletion API hits core
by Michelle Cox 23 Jun '07

23 Jun '07

On 6/23/2007 10:08:29 AM, Chad Phillips -- Apartment Lines (chad(a)apartmentlines.com) wrote: > On Jun 23, 2007, at 6:00 AM, Michelle Cox wrote: > > > This sounds like a transaction... http://en.wikipedia. > org/wiki/Database_transaction > > it's like a transaction in that it's all or nothing if a module aborts a > package, but more importantly, it exposes > what's about to happen in regards to a deletion where it matters most -- > to module code that may have something to say about it. i don't > think a transaction solution alone would be as complete, not to mention (i > think) that the majority of installs use MyISAM, where no transactions are > present. I don't know anything about the code... Was just suggesting a name based on the description. :) Michelle

1 0

Re: [development] Deletion API hits core
by Chad Phillips -- Apartment Lines 23 Jun '07

23 Jun '07

On Jun 23, 2007, at 6:00 AM, Michelle Coxg wrote: > This sounds like a transaction... http://en.wikipedia.org/wiki/ > Database_transaction it's like a transaction in that it's all or nothing if a module aborts a package, but more importantly, it exposes what's about to happen in regards to a deletion where it matters most -- to module code that may have something to say about it. i don't think a transaction solution alone would be as complete, not to mention (i think) that the majority of installs use MyISAM, where no transactions are present.

1 0

Drupal FTP
by Aaron Winborn 23 Jun '07

23 Jun '07

3 2

Re: [development] Deletion API hits core
by Chad Phillips -- Apartment Lines 23 Jun '07

23 Jun '07

On Jun 22, 2007, at 8:50 PM, Rob Thorne wrote: > I've just gone through the handbook pages you did on the API. They > describe the API well, but I don't think I grok the "user > experience" that the API implements. Am I right in assuming that > the implementation generates a standard UI for deleting a "package" > along with the various hooks it implements for letting other code > respond to the deletion? there really is no user experience -- or, rather, it's whatever the dev wants it to be. the API exposes the deletion cycle to modules, and allows them to do a few things with it. from a user's perspective, the differences would be: 1. extra info on a confirm screen b/c a module injected it. 2. a user warning b/c a package deletion was aborted by a module. 3. maybe an extra user message here and there. > Also, I found the explanation of the "package" concept a bit > abstract. A real-world-ish example might help. sorry about that. i really wasn't sure what else to call it. i'm happy to pick a better name if it avoids confusion. :) package == 'logical set of deletions that happen together' as in, when you delete a node, you also delete the associated comments, associated revisions, etc. they happen as a logical unit. the API keeps the logical units together, and presents the logical units to the hooks so that outside modules may have a look.

1 0

Re: [development] development Digest, Vol 54, Issue 94
by Chad Phillips -- Apartment Lines 23 Jun '07

23 Jun '07

On Jun 22, 2007, at 8:50 PM, Yves Chedemois <yched.drupal(a)free.fr> wrote: > Does handling content type deletion make sense ? i think it might, because of the dependence of nodes on node types -- possibly some modules may have information to add or need to cancel a type deletion altogether. i wonder how hard content types would be -- i haven't ever looked at that code... hunmonk

1 0

Re: [development] Date Calc and ADODB date library
by Karen Stevenson 23 Jun '07

23 Jun '07

<snip> What's worrying me more is two things: - do we really want to maintain two fork off PEAR, as you mention yourself - this means a lot of code to be parsed that won't really be used afterwards in most cases. selective loading, as in php5's _autoload mechanism, would obviate the second point, but only works out of the box with PHP5 (which would fit nicely with the GoPHP5 thread)... and with classes, not pure functions. </snip> First of all, both of these are VERY stable modules that are rarely updated, so keeping up with them is not like trying to fork something complicated (like TinyMCE, for instance). The ADODB date library has not been changed in years. The PEAR Date Calc library has had a more recent update, but the change was mostly just re-arranging the code and adding a couple new functions. The PEAR Date Calc library from several years ago still works fine. Anyway, I really don't think maintaining them would be a big problem. There are advantages to Drupalizing them instead of including them as-is -- PEAR Date Calc comes with a lot of PEAR baggage that is not even needed and half of the ADODB date library is documentation or test code that I would either remove or put into a separate files. Also I've already run into problems with the ADODB date library when more than one module uses it and the same functions get declared from different included files. We need one central, shared location for these kinds of things. Parsing possibly unneeded code is an issue, but we can find a solution for that. My practice has been to try to find ways to include files only when needed and I would certainly be in favor of that in this instance. We can do it lots of ways -- break the includes down between often and rarely used functions; create a basic include file that only contains wrapper functions that include_once() the necessary file then call the function only when it is needed; break out less common code into optional modules; etc etc. Again, if we Drupalize the code we can make changes like that. Anyway, the basic question is whether this is something that makes sense for core. If not, I won't push it any further, if so, I'll propose a patch. I definitely plan to include it as a part of Date API if it's not in core, so I'm going to do the work either way (and I plan to add it to the 5x branch of Date API either way). And my original question -- does anyone know exactly how I should attribute the original authors and licenses in my Drupalized version? Karen

4 3