Hi, everyone - here is what I and sun have come up with recently:

Basically we (we - both rsvelko and sun and WE - the drupal community ) would pretty much like it if there was only one Project with a couple of submodules in it that solve "the Glossary" problem ...

Instead we have 3 modules - This module (glossify - node based) is similar to Glossary (taxonomy term-based, usage ~1400 as of May 2009) and G2 Glossary ( node-based, usage ~20) modules.

So here I paste our emails with sun to serve for a start of the planning:

sun:

"
Hi Vladimir,

thanks for your response.

I have no roadmap or clear vision of what I want to do. All I know is that I need a feature-wise complete replacement for Glossary module. I think the architectural design is trivial:

- Nodes define glossary terms (title) and description (body).

- A CCK textfield may be used to define synonyms. (optional)

- A CCK nodereference may be used to define related terms. (optional)

- The module defines a separate build mode to render the node's body in a suitable format/markup for acronym/abbr tags or tooltips.

- A (customizable) default view is provided to output the glossary.

- Support for hovertip, tooltip, and other paranoia.

- Taxonomy may be used to categorize glossary term nodes. (built-in core feature ;)

Future:

- Check whether glossify'ing can also work on the client-side, using a client-side caching approach.

Hrm. The more I think about it, the more I think I want to either take over the project or start a new one - because I'm not sure how much of the current module can be kept. Especially, since we would also have to rule out things like http://drupal.org/node/496646, and more importantly http://drupal.org/node/363367 ;)

Thoughts?

Thanks,
Daniel
"

rsvelko:

""2. I suggest we happily co-maintain this module or start a new one.

3. Most importantly I need you to tell me why do you want to completely rewrite the glossary module? It is the one that has about 1000 usage .... Can we not collaborate with its maintainers ?

We definitely need to start anew but there is so much we can use from the glossary/g2/glossify triplet ...

These 3 G-modules ( glossify/glossary/g2 ) that are present all serve a different use case while basically doing the same thing - so there is so much place for code reuse ...

We need to carefully split features into non-intersecting areas and do them in submodules ( thus we can solve the whole problem if all are enabled and suit the specific use-cases if only some sub-parts are enabled ... ):
- just for example :
- tag based
- node based
- node-body parser and terms-links (hovertips/blabla) replacer (best if it is a input filter)
- term page
- views of terms - alphabetical ...
- admin UI
......

X-posting these letters into a new issue in glossify.

Still not sure if we need a new project or we can reuse some of the old ones ...

"

Comments

rsvelko’s picture

rsvelko commented

have cross-posted this issue in the queues of Glossary and G2 Glossary.

Have created a wiki page on drupal groups - the group that gathers duplicate modules....

fgm’s picture

fgm
Primary language French
Location Paris, France
commented
Priority: Critical » Normal

This is something I suggested to the Glossary maintainer long ago, but she (Nancy W) and I we were unable to find any way to merge our code bases, due to very large differences in both design choices and needs.

There is a comparison on d.o. here: http://drupal.org/node/266511 and another one on the audean wiki http://wiki.audean.com/g2/choosing where all authors could update their entry se we can go further along that way.

This is in no way critical, though, for any of the modules.

I still think there could be at least one common part: the filter, which is a must for all glossary engines.

The feature blocks also have much in common, at least regarding the result. But the implementation is vastly different.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

Thinking a bit longer about it, I think we could probably refactor this common code:

  • the filters: glossary and g2 both use filters. It is probably feasible to offer an admin choice of either filter model (automatic, as in glossary, or manual as in g2)
  • the feature blocks output, i.e. the block theming: whatever the underlying storage, most of these are common to g2 and glossary, and a common theme could be probably be used by both backends

I don't know if/how this fits with glossify, though.

@sun: one interesting point of both glossary and g2 is that neither needs CCK, so sites wishing to avoid it for whatever reason (performance ?) still have that advantage over a CCK-based solution: CCK's storage, like D7 fields, requires multiple joins on each rendering, which these older modules avoid. Of course, the "modern" way to do it would probably be to implement a custom CCK storage model, which could alleviate the performance issue and still offer CCK flexibility, but that seems really over the top for most needs.

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

@rsvelko: Please feel free to update the comparison page with your module's information. http://drupal.org/node/266511

The audean.com article is very old and probably should not be referenced any longer.

guillaumeduveau’s picture

guillaumeduveau
Location Toulouse
commented

I think it's very different to have a glossary based on nodes, or a glossary based on terms. So is the Grand Unification realistic ? (well at least we could have only 2 of them)

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

There are pieces that may be sharable, such as the filter. But I think it would take a lot to get them there.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

Nancy, only doc maintainers can edit that page, because it uses a table.

This is why I suggest updating it on the wiki, where anyone can have access, and you'll be able to paste the page here once it is done, since I think you have that permissions.

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

All it takes to join the Doc team is a simple request to the Documentation queue.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

Not really: it also takes a moral commitment to actually work on the docs. But nevermind.

rsvelko’s picture

rsvelko commented

OK, guys - I have recently (today) rewritten glossify and have used a html dom parser in it.

Will see how the other 2 modules filter content and we are going to work toward some parts of the unification ...
Let us begin with the

1. items (terms/nodes)
+
2. html text
=
3. filtered html text with terms in it as links/hovertips etc...

To unify the terms and nodes approaches we can use a settings page with grand checkboxes - use taxonomy terms and/or use node types...

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

Suggestion: if you are coming to Drupacon Paris, maybe we could do a glossary sprint all three together ?

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

I will not be able to make it. Since Moshe Weitzman originally wrote this module, perhaps you can ask him.

rsvelko’s picture

rsvelko commented

glossify is going to join with Alinks and give birth to the new SEO Links module.

rsvelko’s picture

rsvelko commented
Status: Active » Closed (won't fix)