Text area handler: node creation links [#697248]

Comment	File	Size	Author
#1	697248.views_.text-area-handler-node-creation.patch	3.84 KB	joachim

#2	697248-2.views_.text-area-handler-node-creation.patch	3.75 KB	joachim

	views text area node creation links.png	33.33 KB	joachim

Comment #1

joachim CreditAttribution: joachim commented 27 January 2010 at 22:12

File	Size
697248.views_.text-area-handler-node-creation.patch	3.84 KB

Patch.

Note: #697208: handler validation only gets given default display means that validation can fail -- hence the current check in render().

Also also see #697182: textarea handlers shouldn't need to be defined in hook_views_data, whose fix will have implications for code here.

Log in or register to post comments

Comment #2

joachim CreditAttribution: joachim commented 27 January 2010 at 22:12

Status:

Active

» Needs review

File	Size
697248-2.views_.text-area-handler-node-creation.patch	3.75 KB

Updated with fixes from comments in IRC.

Log in or register to post comments

Comment #3

dawehner

German

CreditAttribution: dawehner commented 27 January 2010 at 22:31

I would like to have a option to select node types.

Log in or register to post comments

Comment #4

joachim CreditAttribution: joachim commented 27 January 2010 at 22:38

todo: function label() can be dropped and inherited.

@dereine: I would say all the types need to be enabled by default in the option for that, so you get all the types from the filter with a minimum of UI steps.

Log in or register to post comments

Comment #5

dawehner

German

CreditAttribution: dawehner commented 27 January 2010 at 22:48

ok, but
1) we can't be sure, that we have a type filter
2) we cannot be sure, thats the key is "type". I think we have to iterate through all filters and check table and field of the table of the filter.

Log in or register to post comments

Comment #6

joachim CreditAttribution: joachim commented 27 January 2010 at 23:30

> 1) we can't be sure, that we have a type filter

Without one this handler doesn't make sense does it? If you want *all* types, just chuck in a block with the create content menu!

> 2)

So is the key in that array aliased?

Log in or register to post comments

Comment #7

merlinofchaos CreditAttribution: merlinofchaos commented 13 March 2010 at 00:15

Status:

Needs review

» Needs work

Rather than checking for an existing filter, why don't we just select the type from the list of types in the options? I realize it's mildly more annoying, but having to introspect the view is difficult. Also, I can see where relationships could make this tricky. Let's say you've got a node view with a noderef relationship to a node type (let's say artist -> album) and you want to add an album to the artist...but the album is part of the related node. That's pretty ooky.

Log in or register to post comments

Comment #9

joachim CreditAttribution: joachim commented 13 March 2010 at 09:08

*steps over the spam*

We could check for the filter, and if we don't find it, fall back to a list of types in the options. Best of both worlds :)

This is postponed anyway until text area handlers get turned back to plugins IIRC.

Log in or register to post comments

Comment #10

dawehner

German

CreditAttribution: dawehner commented 13 March 2010 at 09:14

As far as i understand it, you would need quite a lot of rewrite to be able to create multiple instances of a plugin.

Dagmar only developed a method to create instances for the same kind of plugin in different "areas".

And hey jochachim, you needed to have multiple instances, so live with handlers :)

Log in or register to post comments

Comment #11

joachim CreditAttribution: joachim commented 13 March 2010 at 10:23

Sorry; it's been a while since I looked at all this...

But I seem to remember on IRC we talked about this: #697182: textarea handlers shouldn't need to be defined in hook_views_data so at least some architectural changes are needed; developing text area doodads should probably wait until we get the API figured out.