phptemplate?

Mark,

great question.

If you created page-node-1.tpl.php that would override entire page, whereas Custom Page only overrides the "content" area, inheriting the header, footer and all other regions. You probably don't want to duplicate those, in most cases.

So, Custom Page allows theming at the same level that node.tpl.php does, but there is no node-nn.tpl.php template. The next best thing you have is node-type.tpl.php and that's where problems start.

1) You would have to create a node type and a node for each custom page you need. Considering "Custom Pages" are usually entry portals to something, aggregation pages, conceptually they are very different from content items. Nodes and Node types, on the other hand should ideally be treated as content items, if you are using Drupal as a CMS.

2) Furthermore, Custom Pages use hook-based approach for preparing data for a template which is clean and arguably - aesthetically superior.

3) Probably the biggest win with Custom Pages is that it is not limited to just tpl.php files. It goes through the entire theming hierarchy. Using custom pages you can create an initial implementation (with a phptemplate_ hook) and package it with your module. Designers can modify initial implementation later by overriding it with a tpl.php implementation, easily re-using the de-coupled data layer.

4) And last minor but annoying thing about creating a meaningless node just for theming: if you do that, the contents on the node/1/edit page make no sense, because they never get displayed. It can frustrate a customer.

Hope this answers your question. Of course, there are many ways of doing things in Drupal, for every use-case, but Custom Pages seemed like a clean approach to one group of use-cases.

Thanks for the explanation, I will definitely consider using it when I get up to Drupal 6! ;)

Please clarify the project description by including at least point 1) of your reply above and put this somewhere at the beginning of the page.

sun,

working on that and on the documentation, as well. There will be other significant advantages, too. Just several to give a taste: utility functions for easily pulling-in views and nodes, hooks to allow modules define similar methods. UI allowing editors to easily and intuitively access "edit pages" of those content entities directly from a Custom Page etc.

Some of these features are under development as we speak though. We plan to re-work description and documentation with the next release, which is scheduled to happen as soon as possible.

In the true spirit of open-source, we try to "release often, release fast", which leads to a little mess in the beginning. It will have to be excused, the project is just a day old, after all :)

cheers

the project is just a day old, after all

Well, yes -- but that's also the reason why it's showing up in the new projects RSS feed on drupal.org. And this in turn leads to many eyes starring on the project description, thinking wtf? ...and another one who didn't understand Drupal's theme system..., and only a tiny number of people actually checking the issue queue to ask the same question with less offense.

So the best time to promote your project right is now - by updating/correcting the project description. If you fail to do so, you'll loose interest from the most important audience: Drupal developers and rock stars.

"and another one who didn't understand Drupal's theme system", huh? Hehe

Point well taken. I updated the home page description. Hope it is more clear, now, why this module is much more than just a misunderstanding of node.tpl.php :)

Thank you

CustomPage has a documentation ( http://drupal.org/node/286219 ) that better explains how the module works, also the project page was updated to better answer questions raised here.

Thank you

Automatically closed -- issue fixed for two weeks with no activity.