http://groups.drupal.org/theme-development Just to de-lurk for a second and riff off of the "Drupal theming is complex" idea, is it just me, or does anyone else think this particular approach would wind up making a lot of work for the guy? Seems like too many changes in the pipe for theming, let alone everything else going on, that this would be especially practical. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.2/372 - Release Date: 6/21/2006
Max Bell wrote:
is it just me, or does anyone else think this particular approach would wind up making a lot of work for the guy? More than that he seems to be out of touch with where the theme system is going.
-- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
No. I am not. First, let me say that PHPTemplate is not the only theme engine in the world. I am proposing a theme engine that relies on blocks, rather than flat files. Second, the recent development for PHPTemplate has been focused on splitting files containing theme_x and theme_y functions into separate x.tpl.php and y.tpl.php files. This is breaking apart lots of code into small managable sections. To override a hook, all you have to do is copy the .tpl.php file and modify. My node solution simply replaces the .tpl.php files with nodes managed in the database. Otherwise, it is basically the same idea. If I am misunderstanding your cryptically short statement, please let me know. -M On Jun 23, 2006, at 9:36 AM, Adrian Simmons wrote:
Max Bell wrote:
is it just me, or does anyone else think this particular approach would wind up making a lot of work for the guy? More than that he seems to be out of touch with where the theme system is going.
-- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com> _______________________________________________ themes mailing list themes@drupal.org http://lists.drupal.org/mailman/listinfo/themes
Mark Fredrickson wrote:
I am proposing a theme engine that relies on blocks, rather than flat files. <snip> My node solution simply replaces the .tpl.php files with nodes managed in the database. Two thoughts spring to mind. Firstly that (from what I've read) querying the database is often one of the bottlenecks in Drupal - is that not going to create a performance problem. It might facilitate an inline theme 'editor' though, I know some people like that idea.
Secondly. I have all this useful software with great features like syntax highlighting, code completion, code folding, integrated access to reference manuals etc. How do I bring those tools to bear on a tpl in a database? Not an insurmountable problem, and perhaps not even relevant to the people your idea is aimed at, but still, I pose the question ;) -- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
I am proposing a theme engine that relies on blocks, rather than flat files. <snip> My node solution simply replaces the .tpl.php files with nodes managed in the database. Two thoughts spring to mind. Firstly that (from what I've read) querying the database is often one of the bottlenecks in Drupal - is that not going to create a performance problem.
Definitely. Going to the database multiple times per page MORE than we have now will be a bottle neck.
It might facilitate an inline theme 'editor' though, I know some people like that idea.
Maybe we can have a hybrid approach: Use the database to design the layout and its components, then have a "generate" button that would convert that finished design to flat files.
Secondly. I have all this useful software with great features like syntax highlighting, code completion, code folding, integrated access to reference manuals etc. How do I bring those tools to bear on a tpl in a database? Not an insurmountable problem, and perhaps not even relevant to the people your idea is aimed at, but still, I pose the question ;)
Good point ...
On 30 Jun 2006, at 4:07 AM, Khalid B wrote:
Definitely. Going to the database multiple times per page MORE than we have now will be a bottle neck. we currently have that problem with the template stuff..
doing an drupal_get_filename, does a db query (it shouldn't imo. that should have been loaded with the module_list in the beginning) and for every template there is an extra query now. One of the reasons we are still 5% slower than core -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Op donderdag 29 juni 2006 23:47, schreef Adrian Simmons:
Secondly. I have all this useful software with great features like syntax highlighting, code completion, code folding, integrated access to reference manuals etc. How do I bring those tools to bear on a tpl in a database? Not an insurmountable problem, and perhaps not even relevant to the people your idea is aimed at, but still, I pose the question
This is in the same line of why PHP blocks and PHP pages are not perfect. I think the Ruby on Rails concept of scaffolding a theme, is a lot handier and will help us a much more then onsite editing of these themes. You run some commands and have stuff ready on your disk to start themeing with. If all your modules are in place, yuo run $~> generate.php -type theme -name MyCoolExampleComTheme -site www.example.com and it creates a long list of tpl.php files, and so. Thirdly: how often do you *really* need to change your theme? Right, once, then you release! You might have some rounds of tweaking afterwards, but that is hardly a daily task. Inline theme-editing is only handy if it does not really cover your theme (which you design once, then never touch), but when used for that grey area called "layouting a special page". Pages and places on your site that are neither in your actual design, nor plan 'ol pages. Pages like the "about section" where you really design every page separately. Bèr -- [ End user Drupal services and hosting | Sympal.nl ] Drupal repareert wederom een kritiek veiligheidslek: http://help.sympal.nl/drupal_repareert_wederom_een_kritiek_veiligheidslek
On 30 Jun 2006, at 3:46 PM, Bèr Kessels wrote:
Inline theme-editing is only handy if it does not really cover your theme (which you design once, then never touch), but when used for that grey area called "layouting a special page". Pages and places on your site that are neither in your actual design, nor plan 'ol pages. Pages like the "about section" where you really design every page separately.
that's the thing. you wouldn't mostly be editing your default markup. You would be editing the alternates. for instance : node-flexinode-1.tpl.php or overriding the template for a specific block. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On Fri, 2006-06-30 at 15:51 +0200, Adrian Rossouw wrote:
On 30 Jun 2006, at 3:46 PM, Bèr Kessels wrote:
Inline theme-editing is only handy if it does not really cover your theme (which you design once, then never touch), but when used for that grey area called "layouting a special page". Pages and places on your site that are neither in your actual design, nor plan 'ol pages. Pages like the "about section" where you really design every page separately.
that's the thing.
you wouldn't mostly be editing your default markup. You would be editing the alternates.
for instance : node-flexinode-1.tpl.php
or overriding the template for a specific block.
but it seems like you really wouldn't be editing those all that often.. and if you laid you xhtml right the first time, a little <style></style> in the node body goes a long way. Seems like overkill when the technology is already there.
Op zaterdag 1 juli 2006 00:54, schreef Darrel O'Pry:
but it seems like you really wouldn't be editing those all that often.. and if you laid you xhtml right the first time, a little <style></style> in the node body goes a long way. Seems like overkill when the technology is already there.
I think Adrian and I are talking about "designs" that are simply not possible ATM. I have seen page.tpl.php files that have huge if()s around the whole <body> tags, I have seen mytheme_page() function overwrites that choose One of a list of special-page-*.tpl.php. I have seen people including home-page.tpl.php files and so on. All that to achieve very different layouts for some parts of your site. If we had a default mechanism for that, as well as being able to edit/create such special layouts on the site, it would make things a lot simpler. So: a lot of sites will not need to override theyr themes in the database, so purely web-editable-themes are a bit silly imo. But another lot of sites, will need some flexibility to redesign certain pages in a breeze. Being able to do that from the database (add special theme page » edit xhtml » save) could be the simplest way to achieve that. Bèr
I've been using Radiant CMS for the past few days, there's a set up similar to what is being discussed here... Everything is a page in Radiant, including the stylesheet. Then there are layouts examples of which are "normal, stylesheet, and xml feed." When a page is made a layout can be chosen per page. So if I create an html template called "Portfolio" I could choose that template instead of "Normal" to create a specific page. It addresses theming pages in a method that feels very natural. I'm not really doing it justice, try out the demo: http://radiantcms.org/demo/ Bèr Kessels wrote:
Op zaterdag 1 juli 2006 00:54, schreef Darrel O'Pry:
but it seems like you really wouldn't be editing those all that often.. and if you laid you xhtml right the first time, a little <style></style> in the node body goes a long way. Seems like overkill when the technology is already there.
I think Adrian and I are talking about "designs" that are simply not possible ATM. I have seen page.tpl.php files that have huge if()s around the whole <body> tags, I have seen mytheme_page() function overwrites that choose One of a list of special-page-*.tpl.php. I have seen people including home-page.tpl.php files and so on.
All that to achieve very different layouts for some parts of your site. If we had a default mechanism for that, as well as being able to edit/create such special layouts on the site, it would make things a lot simpler.
So: a lot of sites will not need to override theyr themes in the database, so purely web-editable-themes are a bit silly imo. But another lot of sites, will need some flexibility to redesign certain pages in a breeze. Being able to do that from the database (add special theme page » edit xhtml » save) could be the simplest way to achieve that.
Bèr _______________________________________________ themes mailing list themes@drupal.org http://lists.drupal.org/mailman/listinfo/themes
Op maandag 3 juli 2006 16:13, schreef Erik Mallinson:
I've been using Radiant CMS for the past few days, there's a set up similar to what is being discussed here... Everything is a page in Radiant, including the stylesheet. Then there are layouts examples of which are "normal, stylesheet, and xml feed." When a page is made a layout can be chosen per page. So if I create an html template called "Portfolio" I could choose that template instead of "Normal" to create a specific page. It addresses theming pages in a method that feels very natural. I'm not really doing it justice, try out the demo:
This is our exact system in Railfrog. Only there we call it Chunks, not pages. It indeed feels very natural. Note that with Railgrog we will (we're working on that issue right now) import an "ordinary theme, consisting of template files" into the database. So you will design your site like you've always done. Bèr
On 29 Jun 2006, at 7:21 PM, Mark Fredrickson wrote:
Second, the recent development for PHPTemplate has been focused on splitting files containing theme_x and theme_y functions into separate x.tpl.php and y.tpl.php files. This is breaking apart lots of code into small managable sections. To override a hook, all you have to do is copy the .tpl.php file and modify. My node solution simply replaces the .tpl.php files with nodes managed in the database. Otherwise, it is basically the same idea.
i don't like the idea of using nodes.. but definitely. when you have the template files separate, you can load them into a text area, and allow people to customize them. Loading them from the database (the new system is designed with this in mind) -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
participants (8)
-
Adrian Rossouw -
Adrian Simmons -
Bèr Kessels -
Darrel O'Pry -
Erik Mallinson -
Khalid B -
Mark Fredrickson -
Max Bell