| Project: | freelinking |
| Version: | 4.6.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hi,
Yesterday I made a few extensions to the freelinking module, and I wonder if you are interested in adopting them, or not. Here they are:
- New settings to independently enable or disable CamelCase linking and double-square-brackets linking.
- Simplified match-replace process, using preg_replace_callback instead of preg_match_all/preg_replace. It is simpler, faster, and also avoids problems when the freelinking text contains regexp characters, like in [[Welcome|Hello]].
- Probably the most important is that I extended the freelinking syntax: the general syntax is now [[Label|LinkType:Target]]. If a Label is specified, it will be used for the link's label. If the LinkType is omitted, Target is expected to be a node title. So [[Welcome|Welcome to Drupal]] would create a link named Welcome that points to the node named Welcome to Drupal. LinkType permits to provide different meanings for the target. The interesting part is that other modules can provide their own LinkType hooks. I implemented two default link types: node and term. Node permits to link to a node by id, for instance [[Page|node:4]] will create a link named Page that points to node/4. Term creates a taxonomy link: [[Page|term:1+2]] creates a link to taxonomy/term/1+2. All these new items being optional, the original syntax giving only the node title still works.
Please tell me if you find it interesting and want to include my changes. I include the source anyway.
Guillaume Pothier (gpothier, gmail.com)
| Attachment | Size |
|---|---|
| freelinking.module | 6.06 KB |
Comments
#1
Your first set of improvements sound great.
I'm a little concerned about the complexity of the second set of options. While in theory some of the items sound interesting, I know I wouldn't want users having to know that a "node/4" even exists, and the same goes with taxonomy terms. For taxonomy terms, might it be possible to do taxo:friendly-name-of-term?
Just my 2¢.
#2
Note: I haven't looked at the code yet, and probably won't be in a position to do so for another day yet.
I agree with Boris, that, while these extensions sound very powerful and exciting on the surface, that they might be too complicated for general use. I really love the idea of modules being able to provide module-specific extensions to the LinkType syntax; I can see the advantages and capabilities of that, if implemented very carefully.
For example, what about freelinks like:
Interesting.
Thanks for your interest in freelinking.module; I'll definitely take a look at adopting pieces of them into the module.
#3
Boris:
It indeed depends on the intended audience. I am setting up a site for a team of seasoned developpers! So for us it is a real benefit to be able to link to a stable node id instead of a title that can change.
For the node linking there is no problem as the default syntax permits to link using node title.
I entirely agree with you that it would be interesting to link to taxonomy pages by name, the advantage of the extensible syntax is that it is really trivial to add this functionality: it amounts to create a new function, copy-paste the original title lookup query code and adapt it to look at taxonomy terms instead of nodes (and also explode the original string to handle , and + between terms).
eafarris:
As I said above the complexity of the new features is all realtive and we can create more user-friendly extensions. As for adding link types, I agree that there are lots of possibilities.
As far as I am concerned I would like to add Javadoc and source link types so that I can do things like:
[[SomeClass|javadoc:someproject:org.thing.SomeClass]]
And the same with a source link type, which links to generated cross-referenced source code html pages.
g
#4
Perhaps a framework that could be extended via user-contributed include files like flexinode's field*.inc files. Very intriguing.
#5
Yes, that's another interesting possibility.
So we could do the following:
- Remove the controversial node and term link types from freelinking core.
- Manage a set of .inc files, each providing one link type. A settings page could permit to selectively enable/disable each one of them. We could create some kind of link type descriptor, with tag name, documentation, etc. The freelinking module could come with many predefined link types, like node and term, and more.
- Allow external modules to define their own link types. This is useful to keep this possibility in addition to the repository of .inc files, because it allows a module to extend freelinking without having to spread its installation files. But instead of the current hooking technique, we should create a single hook like hook_linktypes() that returns an array of link types. This would permit to include link types contributed by external modules in the aforementioned settings page. Therefore, freelinking_linktypes(), which is freelinking core's own hook_linktypes() implementation, would simply scan the .inc files. Other modules would do whatever they want to.
Here is the structure I suggest for link type descriptors:
- tag name (the part that comes before the colon: [[Label|Tag:Target]]
- short description
- documentation
- flag that indicates if the link type should be activated by default. This is useful in the case you install a module that defines new link types: the module can say that its link types must be activated by default, without asking the user to go to the freelinking's settings page. Of course, the use can still disable any link type afterwards. It's just that when the link type is first detected it is activated.
- callback function that does the processing when a freelinking/xxxx page is requested. Typical case is simply drupal_goto, but who knows...
g
#6
In addition to the points I just posted, I think we also could make the syntax customizable by administrators: the settings page could have an option to add/remove syntaxes. This would amount to input regular expressions with the right number of capture groups, one for each of the three elements (Label, LinkType tag and Target).
g
#7
While I'd like to see _all_ these features... the thing that caused me to find this page was mention of a way to disable CamelCase. As it happens, for my particular implementation, CamelCase is kind of useless and annoying. There's terms used on my site that I don't _want_ CamelCase enabled for... such as on the page that _already_ lists the defeinition for the word that's been CamelCased to.
I don't know about the other additions, but I _seriously_ need to be able to disable CamelCase on my site. If nothing else, that would be important to me. : )
#8
You can disable CamelCase in HEAD. Grab the tarball, but the current version in HEAD is not compatible with Drupal 4.6.x. The last revision of freelinking.module to be compatible with 4.6 was 1.13, which you can get here:
http://cvs.drupal.org/viewcvs/*checkout*/drupal/contributions/modules/fr...
The HEAD version has *lots* of improvements.
#9
I found CamelCase linking fails when I have CamelCase text inside HTML tags (especially tags) so I've re-written it for my own site to skip links and any text inside tags. That way if I have CamelCaseLink freelinking won't try to replace either. Or if I had something like:
this is some text
freelinking won't try to replace the text inside the
tag and cause problems.
If you are interested my version of the script is attached. Unfortunately it is based on the current downloadable version and not the version on the head. I did add the ability to disable CamelCase linking that you have in the HEAD.
#10
So let me get it straight, in order to get freelinking working properly (i.e. disabling camelcase) if you have to work with, say, Irish names like McDonald and don't want them freelinked, I have to upgrade to 4.7?
#11
Not necessarily. If you want a version of freelinking.module with some of the extra features that will be provided by the 4.7 branch, you can get the last version of freelinking.module from HEAD that is still compatible with Drupal 4.6, which I pointed out in #8 above. No new features will be added to the 4.6 branch; all current work is being done in HEAD, which will soon be branched for 4.7.
#12
looks like that code works, but don't forget to add the mysql code too:
http://cvs.drupal.org/viewcvs/drupal/contributions/modules/freelinking/f...
#13
Too old, but some useful ideas.