- Development - lists.drupal.org

Re: [development] PHP 5 > aggregator.module rewrite to XML API?
by Ken Rickard 26 Jun '07

26 Jun '07

All- (I was offline for a week and missed the whole debate.) I'm one of the mentors for Aron Novaak's Summer of Code project, so let me clarify a few issues/goals. 1) Everyone should please comment on his wiki pages ( http://groups.drupal.org/rss-aggregation) 2) The target is a lightweight Aggregator for Drupal core, working in Drupal 5 as a contributed module, with expectations that it will remain contrib for Drupal 6 and become core in Drupal 7. 3) The API element is the fundamental improvement, allowing different sites to enable or disable features and methods as needed. Remember that one of those features (and the reason Robert and I drafted the first API spec) was to allow non-administrative users to safely add feeds. Those users will expect the behavior of iGoogle or MyYahoo, where feeds just work (or gentle errors are given when the user makes a blatant error). 4) From a Google perspective, code review, benchmarking, and design feedback (such as Morbus' comments on the schema) are all acceptable. Inevitably, Aron will be taking code from several existing projects, so feel free to contribute patches, etc. to his project. I don't believe they will violate the terms of his project, and I write the evaluations. What he's trying to do is unite the Aggregators in a way that is useful to the community, so part of his project will be building consensus and coordination of resources. 5) There are some Aggregator core patches waiting for some review love before code freeze, too: http://drupal.org/node/43245 (make blocks optional) http://drupal.org/node/61456 (fix special characters in titles) - Ken Rickard agentrickard

1 0

Deletion API hits core
by Chad Phillips -- Apartment Lines 25 Jun '07

25 Jun '07

well, after three development cycles, i've apparently written something worth committing for Drupal's deletion system... ;) thanks to all the folks who helped it along, esp. chx and steven -- couldn't have done it w/o you! now, on to other matters: upgrade docs are done, and here: http://drupal.org/node/ 114774#deletion-api a complete writeup on the API is here: http://drupal.org/node/153904 hook_delete_pre() and hook_delete_alter() have been added to the developer docs in contrib. the new functions are on api.drupal.org in HEAD. their formatting is a bit crappy, and i'm not sure if that's an api module bug or something i did. at any rate they're usable, and i'll look into getting them prettier in a bit. :) currently, only node and comment deletions use the API in core. we have about 8 days until the code freeze, so i wanted to get opinions on what else in core we might want to try and convert. IMO, the one that should definitely get converted is user deletions, which i'm happy to write. anybody else have thoughts on other important areas that we should focus on before the code freeze??

6 5

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