Is the taxonomy form #tree-enabled? Pulling it out of its fieldset would cause problems for it if so... --Jeff -----Original Message----- From: Karoly Negyesi [mailto:karoly@negyesi.net] Sent: Thursday, March 23, 2006 3:43 AM To: development@drupal.org Subject: Re: [development] Formapi formalter Ber, Form alter does work for node submission forms. Upload, taxonomy, path and many others use that. Showing code maybe would let us help you by debugging what are you doing wrong... Maybe you want to use module weighting so that you come after taxonomy module? Regards NK

Darrel O'Pry wrote:

yeah that #tree thing affects the data structure not the visual structure, and is very important. Would should probably put something in bold by that #tree thing in the formAPI docs, if it isn't already there.

Just letting people know (in case they don't already) that any of the documentation on drupaldocs.org (including the Forms API reference) can be updated by anyone with CVS access. The stuff is in contrib, in the documentation/developer folder (and in this case documentation/developer/topics/forms_api_reference.html) If it's something simple like adding a clarifying note (as specified above), fixing a typo, etc. please feel free to "Just commit it (tm)" -- if it's more involved, such as an entire re-write of a section or something, then please post an issue under the documentation project (http://drupal.org/project/issues/documentation) so it can get community review. Thanks!

Thanks for hijacking :) I've been struggling without drupaldocs.org. Maybe a redirect or notice would be cool for newbs like me. On a related note, should the docs in CVS/contributions/docs/developer match whats on api.drupal.org? I'm trying to mirror drupaldocs/api.drupal.org following the instructions in the handbook 'Your own drupaldocs site' - http://drupal.org/node/26669 but CVS/contributions/docs/developer doens't seem to be complete. Thanks. On 3/23/06, Jason Flatt <drupal@oadae.net> wrote:

On Thursday 23 March 2006 09:04 am, Angie Byron wrote:

...

Just letting people know (in case they don't already) that any of the documentation on drupaldocs.org (including the Forms API reference) can be updated by anyone with CVS access. The stuff is in contrib, in the

Hijacking the thread...

Has the move from http://drupaldocs.org/ to http://api.drupal.org/ been completed, or is there still something else that needs to be done?

-- Jason Flatt http://www.oadae.net/ Father of Six: http://www.flattfamily.com/ (Joseph, 13; Cramer, 11; Travis, 9; Angela; Harry, 5; and William, 12:04 am, 12-29-2005) Linux User: http://www.sourcemage.org/ Drupal Fanatic: http://drupal.org/

-- Proud member of the KEXP cubicle army. http://www.cubiclearmy.com

On Thu, 2006-03-23 at 13:46 -0800, Jason Flatt wrote:

On Thursday 23 March 2006 09:04 am, Angie Byron wrote:

...

Just letting people know (in case they don't already) that any of the documentation on drupaldocs.org (including the Forms API reference) can be updated by anyone with CVS access. The stuff is in contrib, in the

Hijacking the thread...

Has the move from http://drupaldocs.org/ to http://api.drupal.org/ been completed, or is there still something else that needs to be done?

Wildcards don't work, and the search block are missing on api.drupal.org.

Hello, Will drupaldocs.org move to api.drupal.org? If yes, can anyone publish the 4.5.x API docs in api.drupal.org? ;) fabiano Karthik escreveu:

On 24/03/06, Jason Flatt <drupal@oadae.net> wrote:

...

Hijacking the thread...

Let's not. What's the difficulty in opening a new thread?

-K

Op donderdag 23 maart 2006 22:46, schreef Jason Flatt:

Hijacking the thread...

Thank you. :( Was it *really* that hard to start a new thread. It saves you what? ten keystrokes? -- [ Bèr Kessels | Drupal services www.webschuur.com ] Hoe het naviatie blok te verbergen: http://help.sympal.nl/hoe_het_naviatie_blok_te_verbergen

Hi robert, I am really interested in this patch, and think we should continue this discussion over the the thread. However, a quick note here: in #32 you talk about a rerolled patch, but there is no patch attached. Do you still havea local copy that you can attach? If you have no time, maybe you can still mail it to me, ill try to get it updated to HEAD, then. Bèr Op dinsdag 28 maart 2006 19:10, schreef Robert Douglass:

Ber, you've run into the same problem I had when I introduced this issue: http://drupal.org/node/30993

The problem is, you don't want the taxonomy tree at all. It is very expensive to build and very difficult to use after. What you want is to build your own widget, and this patch lets you do it. It probably doesn't apply cleanly anymore, but you can see what the main idea is just by reading the patch.

I won't argue that the patch in the issue is a good solution. A larger restructuring needs to happen before taxonomy can be used in truly creative ways.

-Robert

-- [ Bèr Kessels | Drupal services www.webschuur.com ] Hoe het naviatie blok te verbergen: http://help.sympal.nl/hoe_het_naviatie_blok_te_verbergen

Hi Mark, The category module (http://drupal.org/node/39683) has been in development for some time now, and is already being used on live sites by some users. I would strongly suggest that you take a look at category, before going off and writing a 'Taxonomy2' module. You may find that the category module already has many of the improvements that you're looking for. The category module's API is not much different to that of taxonomy, and could certainly use some improvement. Please contact me if you're interested in helping out with this, and have a look at http://category.greenash.net.au/howtohelp. Cheers, Jaza. On 3/29/06, Mark Fredrickson <mfredrickson@ppmns.org> wrote:

Hello,

Before I begin, please view all these comments in the context of "Let's get 4.7 out first, then...."

I think Robert's and Ber's frustrations are symptoms of a larger problem with taxonomy: it is not designed to be used programmatically, by modules.

Taxonomy works very well for classifying nodes via the node form, but it does not have an API that modules can access to achieve similar results. There has been some work to have modules "own" vocabularies, but taxonomy does not honor this ownership. If a module wishes to control and display a vocabulary differently than the default taxonomy.module way, it must go to a lot of work - either complicated form_alters or custom patching of the taxonomy code (I'm not ashamed to say that I've done it!).

I think it is time for Taxonomy2. I would like to form a working group to assess the current short comings of taxonomy, sketch out a design of a replacement system, and provide a DEP for the larger community to consider , modify, and (I would hope) implement.

The benefits of this work will be a common system that many modules can use to mark nodes (organic groups and workflow, for example, both must keep their own data structures to duplicate what taxonomy does).

I have been coding for Drupal for roughly 6 months now, and while I am happy to volunteer my limited time, I would appreciate the assistance of more experienced individuals.

Please contact me off-list if you would like to help. I will follow up with the devel list as appropriate.

Cheers, -Mark Fredrickson

On Wed, 2006-03-29 at 14:38 +0200, Bèr Kessels wrote:

Jeremy,

sloightly off topic, but did you already try some CCK integration? What I mean is: a "taxonomy" field/widget alike thing for CCK.

So that I can, lets say, add a select widget for "Moods" in an arbitrary location in the CCK forms.

If not, have you got any idea how hard this will be to develop?

Bèr

It shouldn't be too hard... Its not as well documented as could be, and the split between hook_widget and hook_field is a little confusing, but over all not a difficult thing to deal with. I'll try to document some of it today when I do some enhancements to imagefield. .darrel.

Are there more schema changes coming to cck? Is there a place to look figure out where its headed? On Wed, 2006-03-29 at 08:56 -0500, Jonathan Chaffer wrote:

On Mar 29, 2006, at 8:39 AM, Darrel O'Pry wrote:

...

On Wed, 2006-03-29 at 14:38 +0200, Bèr Kessels wrote:

...

sloightly off topic, but did you already try some CCK integration? What I mean is: a "taxonomy" field/widget alike thing for CCK.

So that I can, lets say, add a select widget for "Moods" in an arbitrary location in the CCK forms.

It shouldn't be too hard... Its not as well documented as could be, and the split between hook_widget and hook_field is a little confusing, but over all not a difficult thing to deal with. I'll try to document some of it today when I do some enhancements to imagefield.

I've got some documentation in progress here, but I put it on hold to focus on the schema migration. Once things settle again I'll revise it and commit it to the bundle. It's in the form of an api.module hook file.

On 29 Mar 2006, at 11:02 PM, Jeff Eaton wrote:

Far better, IMO, to explore a more robust relationships system that *encompasses* taxonomy-style metadata and book-style relationships (as well as other stuff). There are a couple of projects along these lines already. If there's talk of revisiting something as fundamental as taxonomy, make the project worth the effort.

Welcome to the 'we need a generalised relationship API' club. We're going to start putting together a newsletter. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

On 3/30/06, Jeff Eaton <jeff@viapositiva.net> wrote:

I have to confess that I've been following Category's development, and while I can attest to the developer's dedication, I don't think it's a good idea. At its core, it's a hack that merges book and taxonomy functionality without re-assessing the underling architecture. It makes sense as a contrib module for sites that really need it, but I think moving core in that direction would be a mistake.

Far better, IMO, to explore a more robust relationships system that *encompasses* taxonomy-style metadata and book-style relationships (as well as other stuff). There are a couple of projects along these lines already. If there's talk of revisiting something as fundamental as taxonomy, make the project worth the effort.

--Jeff

I know what you're saying, Jeff, and believe me it's something I've thought about more than a few times over the past year. But at the end of the day, developing an "all-encompassing" relationships system is a very ambitious task, and one that will take much more development effort than I've put into the category module. The biggest problem will be backwards-compatibility. If we redesign Drupal's categorising / structuring / relationship system from the ground up, how hard will it be to bridge the gap between this new system and the old book/taxonomy system? My guess is that it will be pretty hard. Category, on the other hand, has achieved full backwards-compatibility (through the wrapper system, and through category_legacy) quite easily, because its API is simply a merged and modified version of the API that book and taxonomy use. Category is a more powerful system than book and taxonomy, and yet its new storage schema maps easily to the old schemas, and its new API maps easily to the old APIs. The price of this backwards-compatibility is that, yes (I admit), many of the problems with the old APIs and data structures still exist, and haven't really been solved. But then again, many of the benefits of the old APIs (such as years of testing and refinement) are also being carried through to the category system. It would be awesome if we had a "perfect" new relationships system, and if that fresh new system was able to achieve full backwards-compatibility with taxonomy and book (and various other things, such as comment and possibly user). But that is a task that I don't feel capable of taking on: if other people feel that they're up to it, that's great. If we are ever to replace the book and taxonomy modules in core with something more powerful, then there absolutely MUST be an upgrade path. If a new relationships API isn't able to achieve that, then it's simply not practical. Sorry to sound so negative about it, but building such an upgrade path is a task for which I personally don't see the light at the end of the tunnel. Jaza.

On 3/29/06, Bèr Kessels <ber@webschuur.com> wrote:

Jeremy,

sloightly off topic, but did you already try some CCK integration? What I mean is: a "taxonomy" field/widget alike thing for CCK.

So that I can, lets say, add a select widget for "Moods" in an arbitrary location in the CCK forms.

I haven't looked into CCK very much as yet, but as far as I can see, a widget specifically for the category module probably won't be necessary. When the "taxonomy" widget becomes available for CCK (or is it already..?), this widget should work fine with the category module, through the taxonomy wrapper system (bundled with category). If things like the taxonomy 'advanced search' integration, the forum integration, and the assigned node tags all work with category through the taxonomy wrapper, surely the CCK taxonomy field will as well. :-) Jaza.