Just seeing if it is a good idea at all to create this: a block that shows the node-profile nodes with links.
Example:
About You [edit]
About your career [edit]
Your Location [create]
Equal Opportunities [create]
[edit] shows up when a node exists, [create] when it does not yet exist.

Attached is an example.

Comments

Bèr Kessels’s picture

StatusFileSize
new2.57 KB

And here is a prototypish patch. It does not yet contain the [create] link. And I included a few todos, such as 'unhardcode the [] bracketses'

fago’s picture

Project: Node Family » Node Profile

a great idea :)

However I'd like to introduce nodefamilies that might be used independent from nodeprofiles, as soon as I've the time to do it. For these this block wouldn't make sense.

As an affect this code would sit better in the nodeprofile module I think. Would you be so kind to write your patch for the nodeprofile module, so that it lists a View/edit link for each profile?

furthermore, your patch is reversed, I suppose you mixed up the diff arguments ;)

Bèr Kessels’s picture

Status: Active » Needs work
StatusFileSize
new0 bytes

Here is the new patch for nodeprofile.

Code still needs work though!

Bèr Kessels’s picture

Status: Needs work » Needs review
StatusFileSize
new2.84 KB

A renewed PAtch.

New features:
* a [create] link for nodes that are not yet created
* a theme function, so that the [] is no longer hardcoded
* better logic.

fago’s picture

Status: Needs review » Needs work

thanks ber.

You create a block for each nodefamily - however I would suggest to create only one for each nodeprofile.

But then we need to create links not only for the children but also siblings and profile node itself. Then it would be nice when the create link stays, if users can create more nodes of a type.

Bèr Kessels’s picture

Then it would be nice when the create link stays, if users can create more nodes of a type.

This is not too hard. In fact, I had it in, but then found that in the nodefamilies that case never appeared :). I will put it back and get your other suggestions addressed too.

TimDavies’s picture

StatusFileSize
new2.51 KB

This is a really handy feature :)

I've attached an updated version of the first patch with the arguments round the right way....

Bèr Kessels’s picture

@obscurity could you explain in more detail what you cahnged? It is not very clear. And why not take the last patch, this patch-versioning-and-branching makes an issue really confusing, we should try to keep the last patch in a thread the "one to test".

Bèr Kessels’s picture

Reading trough the code and listing all the possibilties I conclude that my initial plan needs to be re-thought.

I therefore want to split out the one block into two.
'My %type' block shows only the blocks that were submitted, possibly with an [edit] and [delete] link.
'New %type' block will show lists with 'create %type' links.

This will not only make the code a lot simpler, it will improve the overall 'concept' of the blocks, thus enhancing usability.

Please let me know what you think about splitting up the blocks.

fago’s picture

yep, that sounds to be a good idea - really useful!

markhope’s picture

(Following this issue)

I like the two block block concept for more generic usage. If I understand correctly two blocks would be visible, one with node-profile nodes already added and the other listing nodes to chose from to add to your profile?

So (in Bèr's example) the second block could be titled 'Add CV/Resume pages' - Once created they move to the 'My CV/Resume' block?

markhope’s picture

When the user is only allowed to create 1 node per content type (sorry can't remember which module controls this) will this only display the create/add link in the 'New %type' block, when it is possible to do so? I think this is important for usability.

Bèr Kessels’s picture

Related: a required API change to nodefamily, that will make this patch better. http://drupal.org/node/109465

Bèr Kessels’s picture

.. and here is a new patch, with the blocks splitted out into two blocks.

Bèr Kessels’s picture

StatusFileSize
new11.02 KB

Attached is a screenshot that shows how this works:
The user has filled in three nodes from the family, one is missing, the 'about me' node.

This case shows clearly how things work if you have a max set to 1.
However, say I can submit three nodes of 'About my career' type, then, unless I have all three filled out, a single create link for that type will appear in the 'Create Usernode' block. that link will be there, until I have 3 of these nodes, and therefore can submit no more of such nodes.
IF all the nodes in a family are fulfilled, the block will dissapear (core Drupal feature ampty blocks are not rendered). This is easily overridable in the theme.

Bèr Kessels’s picture

Status: Needs work » Needs review

oh, and the code is ready, i think you should test it :)

Bèr Kessels’s picture

A better patch The last one made Drupal hang on 'configure', caused by a 'default:' in the switch. This patch does not contain that default:

markhope’s picture

Would it be possible to retain the weight of the listed nodes, so that once created they maintain the same order in 'My %type' as they do in 'New %type'

Would this be a good default behavior?

Bèr Kessels’s picture

Sime; what is the 'preferred way' to weight nodes in nodefamily? AFAIK nodefamily has no weigting, so should I grab the order from pageroute -- if that module exists?

fago’s picture

hm, yes there is no weighting in nodefamily. I would just order by node type alphabetically or introduce the ordering as setting of the block?

summit’s picture

Hi,

Is this code still relevant on Drupal 5?
Anyone for a drupal 5 patch then?

greetings,
Martijn