Drupal 6.2 theme system standalone
Hello, I've extracted a couple of functions from drupal 6.2 so I can use drupal themes in my own CMS without using the rest of drupal. It's only been a couple of hours since I started work on this, so this is still all very rough. So far it runs the themes included with drupal (bluemarine, chameleon, garland and pushbutton) and the internet_services theme from the drupal themes site. To play with it, you need to extract the attached file into a directory and copy the include/theme.inc file and the themes/ folder from the drupal distribution into that directory. Bob
Quoting Bob Pepin <bob.pepin@gmail.com>:
Hello, I've extracted a couple of functions from drupal 6.2 so I can use drupal themes in my own CMS without using the rest of drupal. It's only been a couple of hours since I started work on this, so this is still all very rough. So far it runs the themes included with drupal (bluemarine, chameleon, garland and pushbutton) and the internet_services theme from the drupal themes site.
To play with it, you need to extract the attached file into a directory and copy the include/theme.inc file and the themes/ folder from the drupal distribution into that directory.
Excuse my harshness in this but why should I really care about your fork of the Drupal theme engine to another CMS? This list is about coding for Drupal and I don't see how what you have is about coding for Drupal. What you have posted is about using pieces of Drupal in other software which isn't quite what I think this list is for. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Hey Bob, that totally awesome. I'd love to know how you got around hook theme.. and I think a decent amount of work has gone into keeping various drupal subsystems as pretty stand alone... basically the stuff in the includes directory... awesome to hear you're working with porting the theme system... I assume we're talking phptemplate, cuz that stuff is just awesome.. Just remember the licensing, and credit where credit is due :).. /me points at Adrian and all the people in the room who have contributed to Drupal's theme system over time. .darrel. On Fri, Jun 13, 2008 at 8:35 AM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Bob Pepin <bob.pepin@gmail.com>:
Hello,
I've extracted a couple of functions from drupal 6.2 so I can use drupal themes in my own CMS without using the rest of drupal. It's only been a couple of hours since I started work on this, so this is still all very rough. So far it runs the themes included with drupal (bluemarine, chameleon, garland and pushbutton) and the internet_services theme from the drupal themes site.
To play with it, you need to extract the attached file into a directory and copy the include/theme.inc file and the themes/ folder from the drupal distribution into that directory.
Excuse my harshness in this but why should I really care about your fork of the Drupal theme engine to another CMS? This list is about coding for Drupal and I don't see how what you have is about coding for Drupal. What you have posted is about using pieces of Drupal in other software which isn't quite what I think this list is for.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Fri, Jun 13, 2008 at 8:35 AM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Excuse my harshness in this but why should I really care about your fork of the Drupal theme engine to another CMS? This list is about coding for Drupal and I don't see how what you have is about coding for Drupal. What you have posted is about using pieces of Drupal in other software which isn't quite what I think this list is for.
In general (not to target you directly in any way) there is not really an excuse for harshness in email. You have time to think and write polite and respectful words. If you don't want to sound harsh, don't be harsh. Drupal is open source. Anyone is free to use it for what they wish as long as they share their derivative work. He is sharing his. It may not be useful for you but it might be for someone. Among other things Drupal takes PHPTemplate and builds on top of it for theming. What Bob is doing is not all that different. While it is not about Drupal development itself, it is about using Drupal's code base which might be relevant to any Drupal developer even if only to say that he tried something that he thought was possible and is making it work. You never know what may come if it (or anything on or around Drupal). It is nice to at least hear of these things so we are aware of them, IMHO. Thanks for sharing Bob. Best, Matt
On 13 Jun 2008, at 6:59 PM, Matt Galvin wrote:
Drupal is open source. Anyone is free to use it for what they wish as long as they share their derivative work. He is sharing his. It may not be useful for you but it might be for someone. Among other things Drupal takes PHPTemplate and builds on top of it for theming. What Bob is doing is not all that different.
yeah. tbh, i wrote and tested phptemplate (and formsapi) completely separately from drupal before starting to integrate it. Some of the more recent changes in D6 might make it a bit harder to separate, but it should still be workable.
I am someone who could have used this when migrating from wordpress with a combination of "legacy" php flat files that called into wordpress for theming. In the end I decided to leave both the wordpress theme and the theming of the flat files (through wordpress) as is, but that decision means most of the older pages look very different from the newer ones, have different formatting, different menus. In short, what is outlined in the first post would be extremely helpful for people coming from a similar situation. A helping hand in moving TO Drupal, not away from it.
Question for the pseudo lawyers in the room. Does this mean that Bob's work must be GPL'd? On Fri, Jun 13, 2008 at 1:04 PM, Adrian Rossouw <adrian@bryght.com> wrote:
On 13 Jun 2008, at 6:59 PM, Matt Galvin wrote:
Drupal is open source. Anyone is free to use it for what they wish as long as they share their derivative work. He is sharing his. It may not be useful for you but it might be for someone. Among other things Drupal takes PHPTemplate and builds on top of it for theming. What Bob is doing is not all that different.
yeah. tbh, i wrote and tested phptemplate (and formsapi) completely separately from drupal before starting to integrate it.
Some of the more recent changes in D6 might make it a bit harder to separate, but it should still be workable.
-- Ken Rickard agentrickard@gmail.com http://ken.therickards.com
Well for now I've put GPL on it, which makes sense cause a lot of what I have done is simply assembling the drupal functions used by the theme system into one place. You could even create a script for extracting those functions from the drupal codebase, which would also make maintenance easier, maybe something like this even exists already? Besides, I figured most of the development happening on this will be improving compatibility with certain themes by either importing or adding stubs for the extra drupal functions used by them, which is something where it makes a lot of sense to share contributions. Anyway, I plan on layering a very thin entry point to this library just on top of the drupal callbacks, so the idea is for example not to implement any custom cache facility inside this but instead to provide hooks where you can register your own routines for handling caching from outside the library. This will hopefully prevent the GPL from infecting your projects ;) But besides, I'd also be interested to know if theoretically I would be forced to use the GPL in this particular case, so if we've got any license war veterans in here, feel free to comment. On Fri, Jun 13, 2008 at 19:15, Ken Rickard <agentrickard@gmail.com> wrote:
Question for the pseudo lawyers in the room. Does this mean that Bob's work must be GPL'd?
On Fri, Jun 13, 2008 at 1:04 PM, Adrian Rossouw <adrian@bryght.com> wrote:
On 13 Jun 2008, at 6:59 PM, Matt Galvin wrote:
Drupal is open source. Anyone is free to use it for what they wish as long as they share their derivative work. He is sharing his. It may not be useful for you but it might be for someone. Among other things Drupal takes PHPTemplate and builds on top of it for theming. What Bob is doing is not all that different.
yeah. tbh, i wrote and tested phptemplate (and formsapi) completely separately from drupal before starting to integrate it.
Some of the more recent changes in D6 might make it a bit harder to separate, but it should still be workable.
-- Ken Rickard agentrickard@gmail.com http://ken.therickards.com
On Fri, 13 Jun 2008 19:04:04 +0200, Adrian Rossouw <adrian@bryght.com> wrote:
yeah. tbh, i wrote and tested phptemplate (and formsapi) completely separately from drupal before starting to integrate it.
Some of the more recent changes in D6 might make it a bit harder to separate, but it should still be workable.
I can report that it is indeed very workable (and bliss) to use FAPI outside Drupal. Heine
Quoting Matt Galvin <mgalvin@simplifiedcomplexity.org>:
On Fri, Jun 13, 2008 at 8:35 AM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Excuse my harshness in this but why should I really care about your fork of the Drupal theme engine to another CMS? This list is about coding for Drupal and I don't see how what you have is about coding for Drupal. What you have posted is about using pieces of Drupal in other software which isn't quite what I think this list is for.
In general (not to target you directly in any way) there is not really an excuse for harshness in email. You have time to think and write polite and respectful words. If you don't want to sound harsh, don't be harsh.
Alright, then I must have meant to be somewhat harsh.
Drupal is open source. Anyone is free to use it for what they wish as long as they share their derivative work. He is sharing his. It may not be useful for you but it might be for someone. Among other things Drupal takes PHPTemplate and builds on top of it for theming. What Bob is doing is not all that different.
I've no problem with anyone using any piece of open source and making it his own. I have a problem with getting that changed source in my Inbox. Especially since that changed source was for use outside of Drupal.
While it is not about Drupal development itself, it is about using Drupal's code base which might be relevant to any Drupal developer even if only to say that he tried something that he thought was possible and is making it work. You never know what may come if it (or anything on or around Drupal). It is nice to at least hear of these things so we are aware of them, IMHO.
That is fine, many people share many things and this list seems to be becoming an announcement list for all the work going on. However, post a link or create an issue with the files attached. Please be kind and don't post a file in email that not everyone is going to use. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Earnie Boyd wrote:
Excuse my harshness in this but why should I really care about your fork of the Drupal theme engine to another CMS?
Seems to be a bit of a misunderstanding here. :) This decoupled theme engine is useful. As an empirical example, I have to work on some old, crufty hand-crafted PHP sites and often look to api.drupal.org to see how things _should_ be done. The owners simply won't let me switch it to Drupal, for a variety of -- misguided -- reasons. So for those of us who love the Drupal API, but are unable to use the full CMS in certain circumstances, this is useful (license issues notwithstanding). This doesn't read like a fork, just a copy that will probably be repeated when the theme engine changes. Using the word 'fork' implies some sort of conflict, which is rather disingenuous. That 'other CMS' is hardly a competitor to Drupal, just a home-brew project. Remember: we can't all use Drupal all of the time, luckily the GPL allows us to mix-and-match code from a variety of sources (as long as the licenses are compatible). This is mildly off-topic for the dev list, but since a number of people who hack on Drupal are interested I believe we can put pedantry aside for a moment. Unless we should have a development-related-to-drupal-but-not-exactly-on-topic-for-the-dev-list errrr, list? Thanks for contributing this back, Bob! :) Kind Regards, Liam McDermott.
I've put a somewhat more complete version that includes an API and a theme browser up on google code. http://drupal-theme-standalone.googlecode.com/ btw, drupal isn't perfect either, just earlier I spent fifteen minutes hunting a bug just because I dared to create a variable called $theme in some toplevel code.. turned out that global was already taken by the drupal theme system, which apparently doesn't bother too much with error checking, so all I got was a blank page, no error message, no nothing.. of course PHP isn't completely innocent in this either ;) On Fri, Jun 13, 2008 at 22:36, Liam McDermott <liam@intermedia-online.com> wrote:
Earnie Boyd wrote:
Excuse my harshness in this but why should I really care about your fork of the Drupal theme engine to another CMS?
Seems to be a bit of a misunderstanding here. :)
This decoupled theme engine is useful. As an empirical example, I have to work on some old, crufty hand-crafted PHP sites and often look to api.drupal.org to see how things _should_ be done. The owners simply won't let me switch it to Drupal, for a variety of -- misguided -- reasons.
So for those of us who love the Drupal API, but are unable to use the full CMS in certain circumstances, this is useful (license issues notwithstanding).
This doesn't read like a fork, just a copy that will probably be repeated when the theme engine changes. Using the word 'fork' implies some sort of conflict, which is rather disingenuous.
That 'other CMS' is hardly a competitor to Drupal, just a home-brew project. Remember: we can't all use Drupal all of the time, luckily the GPL allows us to mix-and-match code from a variety of sources (as long as the licenses are compatible).
This is mildly off-topic for the dev list, but since a number of people who hack on Drupal are interested I believe we can put pedantry aside for a moment. Unless we should have a development-related-to-drupal-but-not-exactly-on-topic-for-the-dev-list errrr, list?
Thanks for contributing this back, Bob! :)
Kind Regards, Liam McDermott.
On Friday 13 June 2008, Bob Pepin wrote:
I've put a somewhat more complete version that includes an API and a theme browser up on google code.
http://drupal-theme-standalone.googlecode.com/
btw, drupal isn't perfect either, just earlier I spent fifteen minutes hunting a bug just because I dared to create a variable called $theme in some toplevel code.. turned out that global was already taken by the drupal theme system, which apparently doesn't bother too much with error checking, so all I got was a blank page, no error message, no nothing.. of course PHP isn't completely innocent in this either ;)
Creating a global variable in the first place was your first mistake. They are a design flaw by definition for exactly the reason you describe. Creating one that was not namespaced to your module was mistake #2, for the reasons you describe. :-) You cannot really error check globals in that way, which is part of the problem with them. Friends don't let friends use globals. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Sat, Jun 14, 2008 at 07:14, Larry Garfield <larry@garfieldtech.com> wrote:
On Friday 13 June 2008, Bob Pepin wrote:
btw, drupal isn't perfect either, just earlier I spent fifteen minutes hunting a bug just because I dared to create a variable called $theme in some toplevel code.. turned out that global was already taken by the drupal theme system, which apparently doesn't bother too much with error checking, so all I got was a blank page, no error message, no nothing.. of course PHP isn't completely innocent in this either ;)
Creating a global variable in the first place was your first mistake. They are a design flaw by definition for exactly the reason you describe. Creating one that was not namespaced to your module was mistake #2, for the reasons you describe. :-)
Well, since PHP does have neither namespaces nor modules (okay, you can use classes as some kind of poor man's namespaces if you don't mind writing ClassName::function() all the time), mistake #2 was unavoidable ;) My point though was that $theme is not exactly the ideal name for a global variable used inside a library. But since the library I'm talking about was previously simply a little module living in its little closed drupal world, I can understand why it turned out the way it did.
You cannot really error check globals in that way, which is part of the problem with them.
Well in this case $theme was an instance of one of my own classes, whereas the library was treating it as a string. Something that in most languages would've either been detected at compile time or would have signaled an error at runtime instantly. And for error checking globals in general, simply requiring variables to be declared before use and signaling an error when a variable with the same name already exists can prevent those conflicts (this would work similar to how PHP prevents you from accidentally redefining a function). And then of course being able to create properly lexically scoped variables (like the "let" keyword that exists in various languages for example) would avoid the problem altogether. Okay, enough off topic for today, have a nice weekend ;) Bob
Bob Pepin schrieb:
Well, since PHP does have neither namespaces nor modules (okay, you can use classes as some kind of poor man's namespaces if you don't mind writing ClassName::function() all the time), mistake #2 was unavoidable ;)
Every programming language that allows you to name your functions and variables arbitrarily supports namespaces. $YOUR_NAMESPACE_your_valiable YOUR_NAMESPACE_your_function() _YOUR_NAMESPACE_your_private_function() HTH, Eric
That's not strictly 100% accurate, since with real namespaces, the scope would be restricted; although for the purposes here, your suggestion would be practical. Victor Kane http://awebfactory.com.ar On Sat, Jun 14, 2008 at 9:56 AM, Eric-Alexander Schaefer < eric.schaefer@eas-consulting.de> wrote:
Bob Pepin schrieb:
Well, since PHP does have neither namespaces nor modules (okay, you can use classes as some kind of poor man's namespaces if you don't mind writing ClassName::function() all the time), mistake #2 was unavoidable ;)
Every programming language that allows you to name your functions and variables arbitrarily supports namespaces.
$YOUR_NAMESPACE_your_valiable YOUR_NAMESPACE_your_function() _YOUR_NAMESPACE_your_private_function()
HTH, Eric
Well, since the original reason for using the variable here was being able to shorten down DrupalThemeStandalone::init() to $theme->init() in a 10-line test script, making that $DrupalThemeStandalone_TestScript_theme->init() would kind of defeat the purpose. But you are right of course that global variables used in libraries should always have some sort of LIBRARY_NAME prefix. But then again I could also have avoided the problem by simply putting all of my code inside a main() function, instead of naively expecting an innocent looking 5-letter variable name like $theme not to be used already by some functions somewhere as a global variable to keep their state. On Sat, Jun 14, 2008 at 15:07, Victor Kane <victorkane@gmail.com> wrote:
That's not strictly 100% accurate, since with real namespaces, the scope would be restricted; although for the purposes here, your suggestion would be practical.
Victor Kane http://awebfactory.com.ar
On Sat, Jun 14, 2008 at 9:56 AM, Eric-Alexander Schaefer <eric.schaefer@eas-consulting.de> wrote:
Bob Pepin schrieb:
Well, since PHP does have neither namespaces nor modules (okay, you can use classes as some kind of poor man's namespaces if you don't mind writing ClassName::function() all the time), mistake #2 was unavoidable ;)
Every programming language that allows you to name your functions and variables arbitrarily supports namespaces.
$YOUR_NAMESPACE_your_valiable YOUR_NAMESPACE_your_function() _YOUR_NAMESPACE_your_private_function()
HTH, Eric
Quoting Eric-Alexander Schaefer <eric.schaefer@eas-consulting.de>:
Bob Pepin schrieb:
Well, since PHP does have neither namespaces nor modules (okay, you can use classes as some kind of poor man's namespaces if you don't mind writing ClassName::function() all the time), mistake #2 was unavoidable ;)
Every programming language that allows you to name your functions and variables arbitrarily supports namespaces.
$YOUR_NAMESPACE_your_valiable YOUR_NAMESPACE_your_function() _YOUR_NAMESPACE_your_private_function()
Why should Bob do that when Drupal doesn't? We need to take a stab at using a $drupal static array that is controlled by a drupal_register function. If only one argument is passed then drupal_register will return the value of the requested variable from the $drupal static array. Else all other arguments are stored as a value of the variable and that stored value is then returned. Note that the first argument is always the associative index value for the $drupal array. If only two arguments are passed then the stored value should only be the value of the second argument. If more than two arguments then the argument array is stored after the index value is shifted off of the array. I'm working up a patch for this. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On 14 Jun 2008, at 4:41 PM, Earnie Boyd wrote:
Why should Bob do that when Drupal doesn't? We need to take a stab at using a $drupal static array that is controlled by a drupal_register function. If only one argument is passed then drupal_register will return the value of the requested variable from the $drupal static array. Else all other arguments are stored as a value of the variable and that stored value is then returned. Note that the first argument is always the associative index value for the $drupal array. If only two arguments are passed then the stored value should only be the value of the second argument. If more than two arguments then the argument array is stored after the index value is shifted off of the array. I'm working up a patch for this.
drupal_get_context and drupal_set_context there's been patches before, and there's patches in the queue still Dries didn't like the idea when i floated it 5 years ago, but maybe it's time =)
On Sat, 2008-06-14 at 16:47 +0200, Adrian Rossouw wrote:
Dries didn't like the idea when i floated it 5 years ago, but maybe it's time =)
If we're talking about that kind of a major change, is it time to revisit the question of whether Drupal should use PHP's OOP features, now that the PHP language has better OO support than it did several years ago? I realize this has been discussed before, and I'm not trying to open a flame war here. If the answer is "Hell no!", then I will not start a fight about it. I just thought we might be trying with things like home-grown contexts to reinvent a wheel that's already solved by classes. Kind regards, Scott -- Syscrusher <syscrusher@4th.com>
On a side note, the next person designing a callback interface should also keep in mind that call_user_func can take array($classname, $methodname) as first argument. Would have avoided all the name clashes with callbacks in themes right now. On Sat, Jun 14, 2008 at 17:00, Syscrusher <syscrusher@4th.com> wrote:
On Sat, 2008-06-14 at 16:47 +0200, Adrian Rossouw wrote:
Dries didn't like the idea when i floated it 5 years ago, but maybe it's time =)
If we're talking about that kind of a major change, is it time to revisit the question of whether Drupal should use PHP's OOP features, now that the PHP language has better OO support than it did several years ago?
I realize this has been discussed before, and I'm not trying to open a flame war here. If the answer is "Hell no!", then I will not start a fight about it. I just thought we might be trying with things like home-grown contexts to reinvent a wheel that's already solved by classes.
Kind regards,
Scott
-- Syscrusher <syscrusher@4th.com>
On 14 Jun 2008, at 5:03 PM, Bob Pepin wrote:
On a side note, the next person designing a callback interface should also keep in mind that call_user_func can take array($classname, $methodname) as first argument. Would have avoided all the name clashes with callbacks in themes right now.
except when you use that format you can't pass references to functions, as it makes copies of everything chx wrote a simple call_user_func array replacement that passes references a few years ago. basically : function call($func, &$var1, &$var2, &$var3, &$var4, &$var5, & $var6 ... etc) { if (function_exists($func) { return $func($func, &$var1, &$var2, &$var3, &$var4, &$var5, & $var6 ... etc); } }
the same array($classname, $methodname) format is supported by call_user_func_array, and according to the doc at php.net Note: Referenced variables in param_arr are passed to the function by a reference, others are passed by a value. In other words, it does not depend on the function signature whether the parameter is passed by a value or by a reference. No idea though if it's always been that way or if it's changed recently or if maybe it goes back to passing by value if we're calling an object method. On Sat, Jun 14, 2008 at 17:12, Adrian Rossouw <adrian@bryght.com> wrote:
On 14 Jun 2008, at 5:03 PM, Bob Pepin wrote:
On a side note, the next person designing a callback interface should also keep in mind that call_user_func can take array($classname, $methodname) as first argument. Would have avoided all the name clashes with callbacks in themes right now.
except when you use that format you can't pass references to functions, as it makes copies of everything
chx wrote a simple call_user_func array replacement that passes references a few years ago.
basically :
function call($func, &$var1, &$var2, &$var3, &$var4, &$var5, &$var6 ... etc) { if (function_exists($func) { return $func($func, &$var1, &$var2, &$var3, &$var4, &$var5, &$var6 ... etc); } }
Classes make really lousy namespaces. That is semantically a wrong use of classes, and also hurts the new Drupal 7 registry. Classes should be used for tight-coupling bundles of code and data. They are not a poor man's namespace. On Saturday 14 June 2008, Bob Pepin wrote:
On a side note, the next person designing a callback interface should also keep in mind that call_user_func can take array($classname, $methodname) as first argument. Would have avoided all the name clashes with callbacks in themes right now.
On Sat, Jun 14, 2008 at 17:00, Syscrusher <syscrusher@4th.com> wrote:
On Sat, 2008-06-14 at 16:47 +0200, Adrian Rossouw wrote:
Dries didn't like the idea when i floated it 5 years ago, but maybe it's time =)
If we're talking about that kind of a major change, is it time to revisit the question of whether Drupal should use PHP's OOP features, now that the PHP language has better OO support than it did several years ago?
I realize this has been discussed before, and I'm not trying to open a flame war here. If the answer is "Hell no!", then I will not start a fight about it. I just thought we might be trying with things like home-grown contexts to reinvent a wheel that's already solved by classes.
Kind regards,
Scott
-- Syscrusher <syscrusher@4th.com>
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
We could even go futher and require PHP5.3. That way namespaces would be available. ----- Original Message ----- From: "Syscrusher" <syscrusher@4th.com> To: <development@drupal.org> Sent: Saturday, June 14, 2008 5:00 PM Subject: Re: [development] namespaced global variables [WAS: Drupal 6.2theme system standalone] On Sat, 2008-06-14 at 16:47 +0200, Adrian Rossouw wrote:
Dries didn't like the idea when i floated it 5 years ago, but maybe it's time =)
If we're talking about that kind of a major change, is it time to revisit the question of whether Drupal should use PHP's OOP features, now that the PHP language has better OO support than it did several years ago? I realize this has been discussed before, and I'm not trying to open a flame war here. If the answer is "Hell no!", then I will not start a fight about it. I just thought we might be trying with things like home-grown contexts to reinvent a wheel that's already solved by classes. Kind regards, Scott -- Syscrusher <syscrusher@4th.com>
On 14 Jun 2008, at 5:00 PM, Syscrusher wrote:
If we're talking about that kind of a major change, is it time to revisit the question of whether Drupal should use PHP's OOP features, now that the PHP language has better OO support than it did several years ago?
how is that a major change ? we simply find all occurences of global and $GLOBALS, and replace it with context_get. we will also be able to track whenever global variables change because you need to use context_set to use them, so it's impossible to fsck up your site by accidentally wiping out globals.
Don't want to start a whole discussion again on this, but the adoption of OO paradigm eliminates the need for most globals in the first place. That's the advantage, along with a lot of others... Victor Kane http://awebfactory.com.ar On Sat, Jun 14, 2008 at 12:09 PM, Adrian Rossouw <adrian@bryght.com> wrote:
On 14 Jun 2008, at 5:00 PM, Syscrusher wrote:
If we're talking about that kind of a major change, is it time to revisit the question of whether Drupal should use PHP's OOP features, now that the PHP language has better OO support than it did several years ago?
how is that a major change ?
we simply find all occurences of global and $GLOBALS, and replace it with context_get.
we will also be able to track whenever global variables change because you need to use context_set to use them, so it's impossible to fsck up your site by accidentally wiping out globals.
This is the question, globals should be shied away from altogether. On Sat, Jun 14, 2008 at 12:00 PM, Syscrusher <syscrusher@4th.com> wrote:
On Sat, 2008-06-14 at 16:47 +0200, Adrian Rossouw wrote:
Dries didn't like the idea when i floated it 5 years ago, but maybe it's time =)
If we're talking about that kind of a major change, is it time to revisit the question of whether Drupal should use PHP's OOP features, now that the PHP language has better OO support than it did several years ago?
I realize this has been discussed before, and I'm not trying to open a flame war here. If the answer is "Hell no!", then I will not start a fight about it. I just thought we might be trying with things like home-grown contexts to reinvent a wheel that's already solved by classes.
Kind regards,
Scott
-- Syscrusher <syscrusher@4th.com>
On 14 Jun 2008, at 5:00 PM, Syscrusher wrote:
I realize this has been discussed before, and I'm not trying to open a flame war here. If the answer is "Hell no!", then I will not start a fight about it. I just thought we might be trying with things like home-grown contexts to reinvent a wheel that's already solved by classes.
Classes do not give us any benefits here over a simple , easy to debug, easy to understand function which works exactly like variable_get and variable_set. Query builders, data api, forms api.. these are things where objects would be beneficial. not something as simple as this.
Quoting Syscrusher <syscrusher@4th.com>:
On Sat, 2008-06-14 at 16:47 +0200, Adrian Rossouw wrote:
Dries didn't like the idea when i floated it 5 years ago, but maybe it's time =)
If we're talking about that kind of a major change, is it time to revisit the question of whether Drupal should use PHP's OOP features, now that the PHP language has better OO support than it did several years ago?
My opinion is that no and yes. Some modules would benefit from the use of OO while the Drupal core functionality should remain procedural.
I realize this has been discussed before, and I'm not trying to open a flame war here. If the answer is "Hell no!", then I will not start a fight about it. I just thought we might be trying with things like home-grown contexts to reinvent a wheel that's already solved by classes.
Put your flames to http://drupal.org/node/270538 if you wish. I'm working on a feature that we can use to namespace all variables. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Saturday 14 June 2008, Earnie Boyd wrote:
Quoting Syscrusher <syscrusher@4th.com>:
On Sat, 2008-06-14 at 16:47 +0200, Adrian Rossouw wrote:
Dries didn't like the idea when i floated it 5 years ago, but maybe it's time =)
If we're talking about that kind of a major change, is it time to revisit the question of whether Drupal should use PHP's OOP features, now that the PHP language has better OO support than it did several years ago?
My opinion is that no and yes. Some modules would benefit from the use of OO while the Drupal core functionality should remain procedural.
Drupal core should use procedural where it makes sense to do so, and OO where it makes sense to do so. Contrib should use procedural where it makes sense to do so, and OO where it makes sense to do so. PHP code should use procedural where it makes sense to do so, and OO where it makes sense to do so. Religious adherence or distaste for one mechanism or the other is simply naive and damaging to the architecture of the project (any project, not just Drupal). -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Quoting Larry Garfield <larry@garfieldtech.com>:
Religious adherence or distaste for one mechanism or the other is simply naive and damaging to the architecture of the project (any project, not just Drupal).
No "yes or no" argument from me, I totally agree. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
drupal_get_context and drupal_set_context
there's been patches before, and there's patches in the queue still
New patches should not use the term 'context'. Panels 2 (& Views?) already occupy that namespace with a concept that will hopefully be adopted by more contrib modules and perhaps core. sun
Quoting "Daniel F. Kudwien" <news@unleashedmind.com>:
drupal_get_context and drupal_set_context
there's been patches before, and there's patches in the queue still
New patches should not use the term 'context'. Panels 2 (& Views?) already occupy that namespace with a concept that will hopefully be adopted by more contrib modules and perhaps core.
The names of the functions can be discussed in http://drupal.org/node/270538 so that we can come to a good agreement and track it their. I have a patch coded but it is not yet tested. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Quoting Adrian Rossouw <adrian@bryght.com>:
On 14 Jun 2008, at 4:41 PM, Earnie Boyd wrote:
Why should Bob do that when Drupal doesn't? We need to take a stab at using a $drupal static array that is controlled by a drupal_register function. If only one argument is passed then drupal_register will return the value of the requested variable from the $drupal static array. Else all other arguments are stored as a value of the variable and that stored value is then returned. Note that the first argument is always the associative index value for the $drupal array. If only two arguments are passed then the stored value should only be the value of the second argument. If more than two arguments then the argument array is stored after the index value is shifted off of the array. I'm working up a patch for this.
drupal_get_context and drupal_set_context
there's been patches before, and there's patches in the queue still
Dries didn't like the idea when i floated it 5 years ago, but maybe it's time =)
And there will be another patch at http://drupal.org/node/270538 once I upload the patch. I have most of it coded already, just need to do some testing but don't have time to set that up yet. Wife is having health issues and I'm having development delays because of that. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
participants (15)
-
Adrian Rossouw -
Bob Pepin -
Daniel F. Kudwien -
Darrel O'Pry -
Earnie Boyd -
Eric-Alexander Schaefer -
FGM -
Heine Deelstra -
Ken Rickard -
Larry Garfield -
Liam McDermott -
Matt Galvin -
Naheem Zaffar -
Syscrusher -
Victor Kane