Today, the SoC program official ends. I'm glad that I was able to make the first release of my project today. Last week has been an intensive week of testing (thanks to all my tester) and the weekend has even been more intensive with bug fixing and today I finally had time to write some documentation. So I think, most things are done.
Overall, I'm satisfied with my results. When I read my initial proposal or when I see my first UI design again, I can say, the results are very close to what I've planed. All features I have proposed are implemented in some way or even more.
To sum up, the most important features available in the Taxonomy Manager:
Of course, there are many more details I could talk about, but, if you want to know more about it, you can read through the readme file for more information. Or simple try out my demo site or, even better, download and install it from the project page :)
Thanks to all my mentors (Nicholas Thompson, Konstantin Käfer, Ruben Canlas Jr.) and many more people from the drupal community for testing, answering my questions, providing me with ideas and many more things :)
After SoC ends, this project will be maintained, ported and further developed.Taxonomy
We are getting closer to the official end of SoC, so it's time now to stop implementing new features and to to do a lot of testing and to fix bugs, so that I'm hopefully able to release a first version of the Taxonomy Manager by end of SoC.
Last week I finally added a search bar to the interface. This search bar contains a autocomplete field, which at first allows you to directly select a term for editing. Second, it's also possible to filter out root level terms by typing in some string (non-existing term). This is especially for long and flat vocabularies very useful. A filter, which affects children terms would have much more complexity and would take too much time to implement at the moment.
If you are interested in trying out the Taxonomy Manager or if you would like to help testing, there is of course a dev snapshot available at my project page.Taxonomy
The last 2 weeks I spent a lot of time in adding paging mechanism to the tree structure, in separating the tree structure as a own form element type and in adding of a form for editing data from a specific term.
In detail:Paging Mechanism
As discussed in my last reports, performance has been a big issue to me. The first thing I added was the AHAH reload of nested children terms (they get loaded when the parent term gets expanded). But this doesn't help me with flat vocabularies or if someone is having a parent term with many child terms (which is in my opinion very rare).
In case of flat vocabularies, I added the standard drupal pager with a page size of 50 terms. This works well and prevents from loading too much in one step.
But this works only for root level terms. In case someone is having longer children list, I added a different paging mechanism. Again only the first 50 terms get loaded. If there exists more siblings, then there appears a link for loading the next 50 terms through AHAH.
Last week I separated the tree structure as a own form element type. This had two reasons. First I'm generating trees in different places (e.g. in the general form, in a callback for reloading nested children through AHAH,..) and so I wanted to have a general and simple structure with some available settings. Secondly this offers the possibility for using it in different ways / modules.Form for editing term data
Last week I started in designing the form for editing term properties, like the term name, description, synonyms...
This form gets dynamically loaded when a term in the tree structure gets selected. So, on the left side there is the tree structure and on the right side we have the form for editing data from a specific term.
The form does look a bit different from the one that the taxonomy module offers. First it includes a textfield for editing the term name and a textarea for the description (like in the taxonomy module). Second it contains listings of all parents, children, related to terms and synonyms with a delete operation (this does delete the relation, not the term itself, except synonyms (because they are no terms..)). The appearance of this forms should certainly depend on the vocabulary settings.
Additional, for every listing, there is a autocomplete for adding a new kind of relation (hierarchical, related to) or synonym. These autocomplete boxes allow you to easy add existing terms or to directly insert a new terms with a certain relation.
The changing of parents / children or adding of new terms can have a strong impact on the tree structure, so that the whole tree will have to be reloaded.
Concerning the parents / children listing, you may see, that editing of hierarchical relations is not a new functionality in the Taxonomy Manager. All this can already be done in the tree structure with moving / adding / deleting operations. But I think I gives some additional overview, e.g. it can help to see that one term has multiple parents (which may not be seen in the tree structure at a glance, because other parents can be collapsed).
I've attached a screenshot of the current status, because it says more than my explanations ;)Upcoming work:
Before I forget, if you are interested in trying out the current implementation (it's still heavily in development), there is a dev snapshot available on my project page.Taxonomy
Again a short summary, what has been done the last week and what I've planed to do this week.Progress last week: Rework of weight management for terms
As announced in my last report, I did a total rework for the weight management for reordering terms. Initially, I planned to have weight select forms included in the tree structure. Soon, we saw, that this is not very nice.
Additional all terms got an mouse-over effect, so that small up and down arrows appear next to the terms.
For hierarchical vocabularies I planed to do a AJAX reload of nested child form elements. This part has been implemented this week.
This method works fine but still has one disadvantage, that it in one point doesn't work properly with Drupals Form API. The Form API only returns values of form elements, that are initially created on page generation. All values of form elements, which are generated afterwards and added to HTML, aren't available in the submit function in the $form_values variable, which is recommend to use for reading the submitted data. Instead I'm using $_POST for getting all checked terms. This is quite not very nice, but at the moment, I don't know a better solution.
With this mechanism, performance problems for hierarchical vocabularies disappear, this still leaves the question for non-hierarchical vocabularies, on which I'm working the upcoming week.
As mentioned above, a splitting of loading all form elements for longer non-hierarchical vocabularies needs to be done. I like to implement a simple pager for non-hierarchical vocabularies with a page size around 200 terms.Form for editing term properties
At the moment only the editing of a whole vocabulary tree, such reordering, deleting, moving, adding... is possible. The possibility of editing term properties, like descriptions, synonyms,.. is still missing.
This form with term specific data will be placed on the right side of the tree structure and appears whenever a term in the tree is clicked.
This week I got some feedback for the first parts of the taxonomy manager. People provided me with additional ideas, that's always great. Again I thought about some points, like how to manage term weights or how to do merging.Weight Management:
Concerning the managing of term weights, I initially planed to place weight form fields (selects) on the right side for each term. This allows you the mass editing of weights, but has some disadvantages, because the weight forms are too far away from the term itself and it's hard to get the right weight field for the right term.
One idea was to implement an drag and drop feature instead, what might be the best for reordering and changing of weights, but I think this would take too much time to implement and there are still more important things to do.
Another idea was to add up and down arrows. This is in my opinion a very nice way of changing the weights and simpler (as drag and drop) to implement. I plan to add two buttons with up and down (or four with additional „to top“ and „to bottom“) and every term, that is selected, gets reordered (by swapping of weights with the predecessor/successor or by in-/decreasing the weight). The updating should be done with AJAX, so that a total reload of the whole page isn't necessary.
First I want to explain what merging actually does.
The aim of merging terms is to put terms with the same meaning together, e.g. it often happens that people write abbreviations and others not for the same word into the autocomplete field. For example we have tags like „Summer of Code“, „SoC“ and „GSoC“, which all have the same meaning (they are synonyms), but are saved as different terms. So what merging does, is to build one main term, where all other terms, with the same meaning are added as synonyms and afterwards deleted.Term - Node relations are automatically updated, optionally it's possible to choose for hierarchical vocabularies to add children, parents and/or relations of merging terms to the main term.
Benjamin (Community Managed Taxonomies) pointed out, that this may have unwanted side effects, because links to merged terms no longer exists. We still have to find a solution. There were some suggestions from the community to set up an additional table, where we store, what has been merged.
Concerning the merging it might be helpful of setting up a separated merging API, because both, Benjamin and I will use it.Performance:
The aim of the Taxonomy Manager is to make it easier to work with vocabularies, especially bigger vocabularies. At the moment, I build the whole taxonomy tree form and do the rendering of the form array when the page gets loaded. This works fine for smaller and middle sized taxonomies (up to 500 terms), but with an increasing number of terms, it gets very very slow and the browser may hang up. That's of course not very fine, because there are vocabularies much more bigger, especially folksonomies (this are vocabularies with no hierarchies) tend to get huge.
Concerning hierarchical vocabularies, I plan to load only the first level terms for the first page load and to reload the nested children terms through AHAH when they are needed (when a parent term gets expanded).
For folksonomies it might be good to load just some parts from beginning (e.g. 200 terms) and to implement a kind of pager or a alphabetic index.
Major points for upcoming week:
Here again the demo site :)Taxonomy
After finishing my exams last week, I finally had much more time to work on my project this week as the last time.
So I started with coding. The first task was to write a simple jQuery script for a dynamic tree view (collapsible parents) for a vocabulary.
After that I integrated the script into my module and set up a form page to display a hierarchical tree. The form includes checkboxes and weight forms for every term. A theme functions transforms the form with terms into the list structure I need for the dynamic tree view. Concerning the browser compatibility, I still have to do some testing. In future a own taxonomy tree element type might be useful, because others maybe interested in a basic tree-form too.
Additional the page contains and an extra fieldset with multiple textfields for adding new terms.
The form already supports deleting of selected terms, updating of weights and adding of terms (optional to one ore more parents as child terms). Many details, like a confirmation form for deletion or validations are still missing.
If you are interested in seeing some code of the taxonomy manager module, I committed it to my project cvs directory.
To sum up, a list of functionality, that's in progress at the moment or already have been done:
My plan for the next days:
Short report about what's going on with the taxonomy manager. Last week my exams at university started (until end of June), so not much coding yet.
The last week I was working on the dynamic tree-view for hierarchical taxonomies as a form element. First I took a look on what already exists. I found the TreeView plugin for jQuery, but I wasn't really satisfied, because there where some errors and it doesn't work with the jQuery version of drupal-5. So I decided to write my own jQuery script, on which I'm working at the moment.
Besides, Benjamin (Community Managed Taxonomy) and I decided to set up a new group (called Taxonomy) for taxonomy issues, where people can discuss about taxonomy and where people can keep up with the latest tools for taxonomy managing. The weekly reports about our projects are posted in both groups (soc and taxonomy group). Additional we decided to cooperate, because our two project have similar parts, so that we can profit from the work of each other.Taxonomy
The first week of summer of code is nearly over. So it’s time for a short report what I’ve done so far with the “Taxonomy Manager”.
First of all, a short description of my project. At the moment, the Drupal’s taxonomy module provides only a simple administration page for adding / editing terms. When having a bigger amount of terms, it gets hard to manage the list of terms. My project will implement an additional powerful interface for managing longer lists of terms.
This week I thought about, what functionality is needed and how I can design a user-friendly interface for the taxonomy manager. So I did a UI design first, you can see the design in the attached image.
I plan to divide the page into two parts. On the left side, there is the dynamic tree-view of the taxonomy. The tree-view contains checkboxes and weight forms for mass editing, like deleting, merging, changing of parents and adding of terms.
By clicking on a term on the left side, the term properties appear on the right side. This area shows all term related information and allows the fast editing of synonyms, description, term name, parents, children and the related to terms.
Additional, on the top of the page, there is a autocomplete form, where you can directly select terms for editing.
For the upcoming week I plan to work on the tree-view. I tried already a jQuery plugin (Treeview). It’s based on lists and it works quite nice, but I have to look, if it’s possible to add forms like checkboxes or weight forms to the list or if it’s better to use something different (e.g. tables).
So, any additional ideas for the UI design are welcome :)SoC 2007