This is a reply to https://gist.github.com/3800860.

Hokay, please keep in mind I know nothing about Drupal 8, so much of what I comment on here may well be problems that are already being addressed or have been solved therein. AGAIN: If I make a poopoo face at something that has been rectified in D8, please don't be terribly irritated at me!

I am a longtime D6 dev, and have been working in D7 for the past few months, as well.

Core issues as I see them in terms of the mobile Web and the pan-device Web as a whole:

• Controllers need to be separated from template/view layers in so much as is possible. There is still too much munging between page callbacks/action and the rendered response. I think this is sort of part of what render arrays aim to ease in D7, but render arrays are complex and abysmally documented. I have asked around and no one can find true documentation on them. They're far too convoluted to figure out on one's own unless one has a lot of time, which I sadly do not.
• Let me clarify: I believe in the kind of idea that a render array represents. But it needs to make sense :).

Agreed :)

I'd say the answer is indeed "render arrays" plus the WSCCI initiative. The WSCCI initiative, in a nutshell, is about making Drupal a first-class REST server, along with the ability to get all content in multiple representations.

• Render array docs
  • docs
  • [example module]http://drupal.org/project/examples), see render_example
  • http://chicago2011.drupal.org/sessions/render-api-drupal-7
  • I agree that this is the bare minimum, but it should be mostly enough, no?
• WSCCI

• The theme layer has too many abstracted layers and yet doesn't perform what I think it intends to. Stop making it a requirement to configure so many things. More auto-detection. If there is a tpl.php for the hook, use it. I shouldn't have to mention it in my hook_theme. Or at least fix the core irony! I'm required to define template name for my hook but the only name that will work is the name of the hook (with underscores translated to dashes). That's humorous.

We could potentially add a "scan system for new template (.tpl.php) files" button somewhere or something like that. But we cannot make it all work automagically for performance reasons. Drupal can easily have hundreds of theme functions. Several dozen of which are typically called on a single page load. Imagine having to go to the file system and check if a corresponding .tpl.php file exists for every single one on every page load. That's … painful.

Regarding the naming restrictions: I don't think the restrictions themselves are so important, and AFAIK it can actually have any name you want, but it should fail more explicitly. I've also had to battle the theming system because of underscores or spaces or dashes (don't remember which). It's like broken magic, essentially.

I completely understand your frustration, but I don't think this is a truly critical issue ATM :)

• The form API needs to be rethought and view-layer stuff pulled out. Every time I '#title' => t('My form field name') in a $form array I die a little bit inside. In fact, every time I see t() I ask myself if it's an opportunity to move whatever it is to a view layer.

Three things:

1. Holy shit, yes, Form API sucks.
2. Form API does not suck for the reason you indicate though, for the simple stuff, it's great. Why do you dislike it so much?
3. What's wrong with t()? It's similar in usage to most other translation systems AFAIK?

IMO, Form API sucks for advanced use cases. As soon as you enter advanced use cases and you run into a bug, you'd wish you'd stabbed your eyes with a pen and had bashed your window with your laptop. Anything in the world seems more logical than debugging Form API, I'd even believe unicorns are possible before I believe there is one person on this planet who truly understands every single aspect of Form API and thinks it's good.

• Basically, I feel that configurable content exists at a layer where people who interact with modifying and customizing content work. That tends to be on the HTML/templating layer, not in the module logic or in controllers.

"Configurable content"? What's that? Things like Taxonomy? Webforms? If those examples are (somewhat) what you mean, then the sad truth is that some people use Taxonomy for configuration (e.g. a fixed set of categories editors must adhere to), but some use it as content (e.g. tagging/folksonomies).

In any case, separation of content and configuration and the syncing of both of them (between dev/staging/prod) is being addressed in the CMI initiative.

• Routing and menu stuff. I desire support for HTTP verbs. I would like systematic routing for resources. Trying to cram REST into Drupal is tear-inducing.

Oh, yes. Also addressed by WSCCI.

• All of these things pale when viewed against the reality that the Drupal database conflates configuration data and content. That above all needs to be solved. Management and deployment of Drupal instances is a world of pain. I'd like to be able to move my content around between environments without carrying a lot of environment-specific data with it. EDIT: Amye Scavarda has let me know I'm ignorant of the Configuration Management initiative in D8. Sounds like a move in the right direction!

YES! Again CMI initiative indeed :)

• The other nightmare is the balance between filesystem and database-based content and settings. The kind of stuff that the good ol' features module and its ilk tried to start addressing years ago. I'm seeing woefully little progress in this area, and I am sad about it!

Do you mean "content vs. configuration" here? (It sounds similar to what you asked above.) Or are you talking about actual syncing of e.g. uploaded images between dev/staging/prod?

• Too hard to manage my page delivery mechanisms. I want to be able to render my template/view layer in whatever way makes sense for the consuming client. Recently I had need to return AJAX partial views. In this case I just wanted to return rendered HTML strings that represented those partials, for injection into the page. This sent me down a long path of hacking via hook_page_delivery_callback_alter as D7 insists on returning JSON (not HTML) for XHR requests. This was too hard. And now I face the same exact situation in that I want to return some Content-type: application/atom+xml data (that is: ATOM/feed flavor of a resource also available in HTML). I got so daunted that I just had my page callback fling out a Content-type header, render the ATOM and exit(). And yeah, I know that is totally wrong.

WSCCI again!

Also: I feel your pain. I also go the route you described. Hackier, but so much less painful. If a framework/CMS is going to have its own system to do it, it should be easier/better/more complete/better in SOME way than doing it this way. I think this is because we tried to get this in Drupal 7, but didn't manage to finish it off, hence this half-baked thing. I think the relevant issue was http://drupal.org/node/145551.

• Some sort of ORM or abstracted, useful data persistence layer would sure be nice. Reinventing that wheel got old about the ninth time I did it :). I think I maybe heard this is in the works for 8? Would sure make coding resource-based web apps a lot faster.

I am not sure what you mean here, but it sounds like the TempStore, which is going in because Views is going in.

Overall, it looks like we're addressing many of the concerns you have though :)

I was very surprised to not see anything mobile-specific or WPO-specific in there?