The is no compelling reason I can see for restricting the handled node type to 'g2_entry'.

define('G2NODETYPE',          'g2_entry');

If we proceed to use this module to handle our highly customised Definition node type, which contains a LOT of data already, we currently have these choices:

  1. Mimic our Definition type into G2 Entry, and then use Node Type to convert them all (which I might be able to automate a bit).
  2. Intervene in the G2 Glossary module code and set it to use our 'definition' type, which works like a charm, you are welcome to view it running at: http://ppi.webel.com.au/g2/initial/c (development site, temporary only)

Obviously for now I'm taking the last one :)

Comments

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm commented

As you noticed, there is no real technical reason in 6.x for maintaining this restriction : this is just an heritage from the 4.x versions of this module, at a time when CCK did not exist and there were many more node modules like this one than there are now. The specific fields added to by the module can easily be replicated with CCK fields.

I plan on making G2 node-type agnostic for D7 thanks to fields now being in core, but not do it on D5/D6 myself unless there is customer (i.e. paid) demand for that port, which I doubt.

HOWEVER... if you already did that port yourself, as you seem to imply, I have no objection to creating an experimental 6.2 branch with your code for this feature. Would you maintain it ?

webel’s picture

webel CreditAttribution: webel commented

> Would you maintain it ?
I'll think about it.

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm commented

Of course, this would mean a number of changes, but off the top of my head, I think the most significant one would be switching from the base node hook implementation to their hook_nodeapi equivalents.

webel’s picture

webel CreditAttribution: webel commented

read.

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm commented

@webel: any news since february ?

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm commented
Version: 6.x-1.x-dev » master

No answer in almost two months, assuming negative. Bumping to next version: this is definitely something I will consider for 7.x.

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm commented
Version: master » 7.x-1.x-dev

Bumping to 7.x now that the branch is opened. Details about this issue at http://wiki.audean.com/g2/choosing

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm at OSInet commented
Version: 7.x-1.x-dev » 8.x-1.x-dev
Issue summary: View changes

8.x-1.x is now the active branch. Bumping.

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm at OSInet commented
Priority: Normal » Major

This is the first new feature planned after the actual port from D6/D7 releases.

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm at OSInet commented

Progress note: in the D9/D10 8.x-1.0-alpha1 version, the node type is now a constant wherever it appears (or it should be: if not open an issue to fix it).

This will make it easier to support other bundles as a replacement for g2_entry. At that point the main hassle will be the configuration, which has to be aware of the bundle to create fields on it, meaning whenever/if this is introduced, all relevant config will have to be generated by code instead of a simple config import.

As to supporting other entity types, there is really no point and a lot of the logic depends on the NodeInterface property, so that one will be a won't fix AFAICS.