3 ms·

"Drupal's custom content types, custom fields, and Views all allow developers to express complex logic that would, in any other development environment, be expr

"Drupal's custom content types, custom fields, and Views all allow developers to express complex logic that would, in any other development environment, be expressed as code and committed to version control" And that, in a nutshell, describes why Drupal's adoption rate is as high as it is compared to development frameworks developers actually enjoy working with. No fucking code. Non-developers can actually get results with the system without having to resort to the kind of miserable hoop jumping we developers subject ourselves to in an attempt to make sure nobody else on the team fucks something up. View got changed? Log in and change it back. Absolutely, positively MUST have an ongoing log of changes to your view/content type/custom field? All of these are exportable to code and can either be imported raw or live in modules. I suspect you've worked with exportables at some point so I simply mention this for any spectators that aren't aware there are a number of strategies for getting your configuration into code (and thus revision control) if that's your thing. Also, for the uninitiated, apendleton makes an excellent point about deploying config changes from dev/staging to production. It sucks, plain and simple.

debaserab2 14y ago
Yeah, those non-developer's you're talking about? Most of them have no idea how to change a view, because changing a view is pretty much just as complicated as coding a SQL query. If you understand how to modify a view, you probably can write an SQL query. The benefits of having a UI to manage core application behavior is lost on most clients. Most are terribly scared of editing a view, content type, or pretty much any other module specific configuration. I speak from the experience of someone whose developed about a dozen or so Drupal sites.
- kalms 14y ago
  Our clients know it pretty well - it's all about education. The button's called "revert" for a reason, and it's placed pretty prominently on the page. When we removed the fear of fucking up, they started learning.
  - skrebbel 14y ago
    Genuinely curious: your clients hack around with Views on their on production site? I'm not sure whether I think that's insane, or whether I'm simply very jealous of your clients.
    - kalms 14y ago
      Not all clients. Clients are different of course! Should something break it would be immediately obvious, and not all are prepared for that (obviously!). It also depends on the structure of the site itself. But some are comfortable changing a title, sending new arguments into panes and stuff like that. Again, depending on structure. As long as the job can be boiled down to a simple point and click routine, they get comfortable doing it. They're not too scared of filters either. Some are also comfortable setting up new panel variants. It's an extremely powerful editorial tool, when setting up sections with teasers. ("breaking news" sections based on terms for instance.)
apendleton 14y ago
Being able to export and commit isn't really good enough; keeping a work log is only a relatively small part of the capacity for version control systems to expedite development. Many projects have development workflows where new features are developed in branches, and only merged when they're ready to be deployed. Suppose, in a Drupal project, you had two such features being developed simultaneously, and each added different new fields to a given content type, with corresponding changes to views and authorship workflows. Assuming it were even practical for each developer on a Drupal project to have their own development instance of the database powering a site (which it totally isn't), it's true that each developer could export their own version of the given content types, views, etc., and commit them to version control. The exported blobs are pretty much opaque to many Drupal developers (or non-developers, as you say), though, and may not be expressed sufficiently sanely that Git could figure out what changes actually took places. When these features were ready to be merged, would the merge work? Who knows? What if there were merge conflicts? Would developers be able to resolve them? Worse, what if Git's notion of the correct merge strategy didn't actually produce a semantically correct result? All of these operations take place on generated code that nobody wrote and nobody reads, which is scary enough that the whole process wouldn't be trustworthy. Exportables are yet another in a long series of efforts in the Drupal community to attempt to address a deficit they have with respect to most other web stacks, and again they've done it in a way that doesn't really deliver the benefits of the feature as it exists elsewhere (see also Drupal's "database abstraction layer" or its supposed "object-oriented design").
- knieveltech 14y ago
  "Being able to export and commit isn't really good enough; keeping a work log is only a relatively small part of the capacity for version control systems to expedite development. Many projects have development workflows where new features are developed in branches, and only merged when they're ready to be deployed." Features, exportables, Strongarm (et al) are all compatible with the workflow you're describing. Our development workflow is heavily dependent upon branching. All new feature development takes place in branches that are later merged into dev, with stable "snapshots" taken from dev whenever we do a release. Pretty standard stuff, and we use features and installation profiles heavily in our implementation work. "Suppose, in a Drupal project, you had two such features being developed simultaneously, and each added different new fields to a given content type, with corresponding changes to views and authorship workflows." What you're describing isn't a credible workflow, it's a mess. Field declarations for a single content type strewn across multiple features? Why? Designing a content type and exporting it to code shouldn't take more than 30 minutes for even the most complex content types. If additional features are required they can be added to the feature but separation of concerns typically dictates that that code goes into a separate module. Cleaner that way. "ssuming it were even practical for each developer on a Drupal project to have their own development instance of the database powering a site (which it totally isn't)" All of our developers maintain local mirrors of the dev environments for all of the clients they work with. This includes snapshots of the dev database. Also, how is maintaining a local copy of a database either impractical or in any way a Drupal-specific problem? Any project that includes a datastore is going to have similar issues. "The exported blobs are pretty much opaque to many Drupal developers (or non-developers, as you say), though, and may not be expressed sufficiently sanely that Git could figure out what changes actually took places. When these features were ready to be merged, would the merge work? Who knows? What if there were merge conflicts? Would developers be able to resolve them? Worse, what if Git's notion of the correct merge strategy didn't actually produce a semantically correct result?" Merge conflicts happen with any workflow. Merge uncertainty is an issue with revision control, regardless of what platform you're developing in. As far as manual merges goes, I submit that any developer should be capable of manually merging simple array declarations (because that's all exportables are). "All of these operations take place on generated code that nobody wrote and nobody reads, which is scary enough that the whole process wouldn't be trustworthy." I think our definitions of both "code" and "trustworthy" differ greatly. Exportables aren't huge blocks of opaque logic. They're simple associative arrays. I have no problem trusting code that generates array declarations and has been tested by the core project devs, security team, module maintainers, and several thousand developers on tens of thousands of websites. Your mileage may vary. "Exportables are yet another in a long series of efforts in the Drupal community to attempt to address a deficit they have with respect to most other web stacks, and again they've done it in a way that doesn't really deliver the benefits of the feature as it exists elsewhere" 100% accurate, you'll get no argument from me here. "database abstraction layer" My kneejerk reaction when this was first announced: DBTNG is a fucking travesty foisted onto the community by Acquia as part of a corporate play for the "enterprise" market. After a year of screwing around with it: It still a pain in the ass but with all of the bullshit going on with the MySQL project courtesy of Oracle, this might turn out to be very very useful. "object-oriented design" Who claimed Drupal was object oriented? Seriously, I'd like to know so I can spill my drink on them if I ever run into them at a DrupalCon afterparty.

debaserab2 14y ago

Yeah, those non-developer's you're talking about? Most of them have no idea how to change a view, because changing a view is pretty much just as complicated as coding a SQL query. If you understand how to modify a view, you probably can write an SQL query. The benefits of having a UI to manage core application behavior is lost on most clients. Most are terribly scared of editing a view, content type, or pretty much any other module specific configuration. I speak from the experience of someone whose developed about a dozen or so Drupal sites.

kalms 14y ago
Our clients know it pretty well - it's all about education. The button's called "revert" for a reason, and it's placed pretty prominently on the page. When we removed the fear of fucking up, they started learning.
- skrebbel 14y ago
  Genuinely curious: your clients hack around with Views on their on production site? I'm not sure whether I think that's insane, or whether I'm simply very jealous of your clients.
  - kalms 14y ago
    Not all clients. Clients are different of course! Should something break it would be immediately obvious, and not all are prepared for that (obviously!). It also depends on the structure of the site itself. But some are comfortable changing a title, sending new arguments into panes and stuff like that. Again, depending on structure. As long as the job can be boiled down to a simple point and click routine, they get comfortable doing it. They're not too scared of filters either. Some are also comfortable setting up new panel variants. It's an extremely powerful editorial tool, when setting up sections with teasers. ("breaking news" sections based on terms for instance.)

apendleton 14y ago

Being able to export and commit isn't really good enough; keeping a work log is only a relatively small part of the capacity for version control systems to expedite development. Many projects have development workflows where new features are developed in branches, and only merged when they're ready to be deployed. Suppose, in a Drupal project, you had two such features being developed simultaneously, and each added different new fields to a given content type, with corresponding changes to views and authorship workflows. Assuming it were even practical for each developer on a Drupal project to have their own development instance of the database powering a site (which it totally isn't), it's true that each developer could export their own version of the given content types, views, etc., and commit them to version control. The exported blobs are pretty much opaque to many Drupal developers (or non-developers, as you say), though, and may not be expressed sufficiently sanely that Git could figure out what changes actually took places. When these features were ready to be merged, would the merge work? Who knows? What if there were merge conflicts? Would developers be able to resolve them? Worse, what if Git's notion of the correct merge strategy didn't actually produce a semantically correct result? All of these operations take place on generated code that nobody wrote and nobody reads, which is scary enough that the whole process wouldn't be trustworthy. Exportables are yet another in a long series of efforts in the Drupal community to attempt to address a deficit they have with respect to most other web stacks, and again they've done it in a way that doesn't really deliver the benefits of the feature as it exists elsewhere (see also Drupal's "database abstraction layer" or its supposed "object-oriented design").

knieveltech 14y ago
"Being able to export and commit isn't really good enough; keeping a work log is only a relatively small part of the capacity for version control systems to expedite development. Many projects have development workflows where new features are developed in branches, and only merged when they're ready to be deployed." Features, exportables, Strongarm (et al) are all compatible with the workflow you're describing. Our development workflow is heavily dependent upon branching. All new feature development takes place in branches that are later merged into dev, with stable "snapshots" taken from dev whenever we do a release. Pretty standard stuff, and we use features and installation profiles heavily in our implementation work. "Suppose, in a Drupal project, you had two such features being developed simultaneously, and each added different new fields to a given content type, with corresponding changes to views and authorship workflows." What you're describing isn't a credible workflow, it's a mess. Field declarations for a single content type strewn across multiple features? Why? Designing a content type and exporting it to code shouldn't take more than 30 minutes for even the most complex content types. If additional features are required they can be added to the feature but separation of concerns typically dictates that that code goes into a separate module. Cleaner that way. "ssuming it were even practical for each developer on a Drupal project to have their own development instance of the database powering a site (which it totally isn't)" All of our developers maintain local mirrors of the dev environments for all of the clients they work with. This includes snapshots of the dev database. Also, how is maintaining a local copy of a database either impractical or in any way a Drupal-specific problem? Any project that includes a datastore is going to have similar issues. "The exported blobs are pretty much opaque to many Drupal developers (or non-developers, as you say), though, and may not be expressed sufficiently sanely that Git could figure out what changes actually took places. When these features were ready to be merged, would the merge work? Who knows? What if there were merge conflicts? Would developers be able to resolve them? Worse, what if Git's notion of the correct merge strategy didn't actually produce a semantically correct result?" Merge conflicts happen with any workflow. Merge uncertainty is an issue with revision control, regardless of what platform you're developing in. As far as manual merges goes, I submit that any developer should be capable of manually merging simple array declarations (because that's all exportables are). "All of these operations take place on generated code that nobody wrote and nobody reads, which is scary enough that the whole process wouldn't be trustworthy." I think our definitions of both "code" and "trustworthy" differ greatly. Exportables aren't huge blocks of opaque logic. They're simple associative arrays. I have no problem trusting code that generates array declarations and has been tested by the core project devs, security team, module maintainers, and several thousand developers on tens of thousands of websites. Your mileage may vary. "Exportables are yet another in a long series of efforts in the Drupal community to attempt to address a deficit they have with respect to most other web stacks, and again they've done it in a way that doesn't really deliver the benefits of the feature as it exists elsewhere" 100% accurate, you'll get no argument from me here. "database abstraction layer" My kneejerk reaction when this was first announced: DBTNG is a fucking travesty foisted onto the community by Acquia as part of a corporate play for the "enterprise" market. After a year of screwing around with it: It still a pain in the ass but with all of the bullshit going on with the MySQL project courtesy of Oracle, this might turn out to be very very useful. "object-oriented design" Who claimed Drupal was object oriented? Seriously, I'd like to know so I can spill my drink on them if I ever run into them at a DrupalCon afterparty.