Needs review
Project:
Node Profile
Version:
4.7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
17 Dec 2006 at 19:39 UTC
Updated:
8 Oct 2008 at 13:06 UTC
Jump to comment: Most recent file
Comments
Comment #1
Bèr Kessels commentedAnd here is a prototypish patch. It does not yet contain the [create] link. And I included a few todos, such as 'unhardcode the [] bracketses'
Comment #2
fagoa 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 ;)
Comment #3
Bèr Kessels commentedHere is the new patch for nodeprofile.
Code still needs work though!
Comment #4
Bèr Kessels commentedA 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.
Comment #5
fagothanks 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.
Comment #6
Bèr Kessels commentedThis 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.
Comment #7
TimDavies commentedThis is a really handy feature :)
I've attached an updated version of the first patch with the arguments round the right way....
Comment #8
Bèr Kessels commented@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".
Comment #9
Bèr Kessels commentedReading 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.
Comment #10
fagoyep, that sounds to be a good idea - really useful!
Comment #11
markhope commented(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?
Comment #12
markhope commentedWhen 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.
Comment #13
Bèr Kessels commentedRelated: a required API change to nodefamily, that will make this patch better. http://drupal.org/node/109465
Comment #14
Bèr Kessels commented.. and here is a new patch, with the blocks splitted out into two blocks.
Comment #15
Bèr Kessels commentedAttached 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.
Comment #16
Bèr Kessels commentedoh, and the code is ready, i think you should test it :)
Comment #17
Bèr Kessels commentedA better patch The last one made Drupal hang on 'configure', caused by a 'default:' in the switch. This patch does not contain that default:
Comment #18
markhope commentedWould 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?
Comment #19
Bèr Kessels commentedSime; 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?
Comment #20
fagohm, yes there is no weighting in nodefamily. I would just order by node type alphabetically or introduce the ordering as setting of the block?
Comment #21
summit commentedHi,
Is this code still relevant on Drupal 5?
Anyone for a drupal 5 patch then?
greetings,
Martijn