Enable inserting node contents witout creating new context by default (good reasons provided)

If you want a list of arbitrary nodes and ordering, have you looked at http://drupal.org/project/nodequeue ?

Hi gragus - thanks for the detailed explanation and references, as well as the kind words; when I'm more used to dealing with #260510: Panels for Drupal 6.x?, you can ask anything this reasonably and at least expect a fair response :) catch does make a good point - it does sound a lot like what you're looking for is adequately addressed by nodequeue. But since you've taken the time to write out and reference your explanation, I can at least address your valid concerns about panels' conceptual inaccessibility to a general audience, as well as your desire (which I share) to see the panels interface be extended into something that's transparently and intuitively usable by that general audience. I do have to warn you, however, that I don't have the time to be able to keep up with the length of the posts you linked to - there's a lot of dev to be done.

There are several issues that need to be addressed first. With all the energy you're putting into this, I'm surprised that you're as concerned about us simply titling a particular method as 'deprecrated'. It may not be the wisest choice, but the deprecation refers to the evolution from Panels1, not that the method is somehow invalid. MUCH more importantly, however, is that you've misgauged the nature of Panels itself. Panels.module, and most of the associated .inc files that are in the /includes and various plugins directories, are _completely_ abstracted from the type of operation you're talking about. Since the core Panels API comes packaged with all the various submodules, people naturally assume that many of the navigational, textual, and other informational elements are in some way basic or fundamental to the core of Panels itself. With very few exceptions, they are not; in terms of their interaction with the Panels API, panels node (legacy), panels page, mini-panels, panels views (legacy) have absolutely no special-privilege access to the API, no custom code going on inside the API that allows them to do their thing. They're simply client modules that bear a striking resemblance in terminology and appearance to those few pieces that are 'core' Panels because - surprise surprise - merlin coded all of them.

The problem isn't that core Panels can't or isn't designed to do any of the things you're talking about, or that it's irrevocably married to the use of terms like 'Context' in its UI. It's entirely possible to design a panels client module that makes extensive and complex use of context without the user ever having the slightest idea. The problem you're focused on here is with the particular way in which panels_node(legacy) implements the Panels API. And though your points and end goals are certainly valid, we're not going to change panels_node(legacy) to suit, as there are plenty of things for which it works just fine right now, nor are we going to introduce any such changes into the API, because doing so would at minimum slow down the rest of the API so that it could consider a special, less-abstracted case, and at worst, would just plain break all other panels client modules. So while I agree with the end goal, the remedy you've proposed would actually take us further away from it. What I'd encourage you to do is write that module, because we do, indeed, need it.

So I've reflected some more on this, and here's where I'm at:

I think I may have somewhat misrepresented the real reason for titling the describing panels nodes legacy as a deprecated method. In truth, though, probably the worst misrepresentation is even calling panels_node_legacy a module at all - in actuality, it is _nothing_ more than a standard panels content type plugin with a couple of extra hook invocations. In fact, compared to a number of the content types that are packaged with Panels, it's pretty elementary.

We've marked it as deprecated because it's as close to deprecated as you can get with a panels plugin - virtually any other plugin that displays node data, especially now that it's possible to create panes more or less directly from CCK fields, is more flexible and provides more granular control than do legacy nodes. But this is about more than just the software engineer's eternal quest for ultimate granularity and abstraction; the real justification for marking the method as deprecated is that, while it works, utilizing it will put you at odds with the direction that the rest of the community is going, and I think we'd be really remiss if we didn't advise people that there's virtually nothing they could want to do with that content type that couldn't be done better by another one. That includes your goal. In this particular case, the issue is that using whole node types to provide such micro-level content will put you at odds with the drupal interface sooner rather than later; that's REALLY what CCK aims to do via its fields. As you point out, you've only been working with drupal for a couple days, and you've jumped in on one of the more abstract ends of a framework/community that's already pretty steeped in abstraction.

It's not that I don't - fully - appreciate the need to bring the abstractions of drupal into interfaces that can be appreciated and intuited by the average user. The fact is, there's an enormous amount of abstraction that needs to be harnessed with drupal, and modules that try to get ahead of themselves will fail - Panels included. At the endof the day, I think that Panels2's real achievement was creating an interface that allows many of the most abstract, most powerful methods currently used in drupal together into an interface so that site designers at all levels can (well, once we finish doccing it) create and manage complex, but relatively non-participatory, websites with ease. Panels3 isn't going to reinvent that wheel - in large point, it's going to be about extending the interfaces to the point where they can reach out to average users in a transparent and intuitive way. Unfortunately, we just can't rush it.

So, all that said - don't worry about not having the time to dev right now. Contribute if & when you can. If you want to write up the method you used, great - the more csae studies, the more accessible it becomes, and that's great all around.