The fact we have a book on front-end CMS design is irony in itself.
The problem with popular CMS systems today stems from the tight coupling of back-end architecture and front-end architecture.
Remove the coupling, and the need for a book on Front End Drupal vanishes, leaving us with a simple API which we can integrate with our own custom or third party front-end.
I agree with this and it's one of the reasons I like drupal. It makes the back-end, which used to be the largest part of a job (setting up a way to put data into a system), into the smallest.
With the way templates work, you're pretty much free to do whatever you want. And honestly, if you just want to throw out the drupal front-end system altogether you could do that, and either use their API to get the data you need or just write your own way to get the data out of the database in the way you want.
Remove the coupling, and the need for a book on Front End Drupal vanishes, leaving us with a simple API which we can integrate with our own custom or third party front-end.
I disagree. With decoupling you might have a simple API, but that API is specific to the CMS you're using. You might still want to have a book from which to learn how to use it to create front ends.
I disagree. With decoupling you might have a simple API, but that API is specific to the CMS you're using. You might still want to have a book from which to learn how to use it to create front ends.
You're missing the point. If the API is designed well you won't be using it to create front ends, but just to fetch the page data to insert into an existing front end made by other means. Which negates the point of a Drupal Front End book. Maybe a chapter on the API in a Drupal Backend book.
CMS should have no "front end" (Score:2)
The problem with popular CMS systems today stems from the tight coupling of back-end architecture and front-end architecture.
Remove the coupling, and the need for a book on Front End Drupal vanishes, leaving us with a simple API which we can integrate with our own custom or third party front-end.
Re: (Score:0)
I agree with this and it's one of the reasons I like drupal. It makes the back-end, which used to be the largest part of a job (setting up a way to put data into a system), into the smallest.
With the way templates work, you're pretty much free to do whatever you want. And honestly, if you just want to throw out the drupal front-end system altogether you could do that, and either use their API to get the data you need or just write your own way to get the data out of the database in the way you want.
I have
Re: (Score:1)
Remove the coupling, and the need for a book on Front End Drupal vanishes, leaving us with a simple API which we can integrate with our own custom or third party front-end.
I disagree. With decoupling you might have a simple API, but that API is specific to the CMS you're using. You might still want to have a book from which to learn how to use it to create front ends.
Re: (Score:0)
I disagree. With decoupling you might have a simple API, but that API is specific to the CMS you're using. You might still want to have a book from which to learn how to use it to create front ends.
You're missing the point. If the API is designed well you won't be using it to create front ends, but just to fetch the page data to insert into an existing front end made by other means. Which negates the point of a Drupal Front End book. Maybe a chapter on the API in a Drupal Backend book.