[drupal-devel] advanced theme in core vs all in core.
Hi, Recently two issues, namely online/offline icons [1] and several Ajax issues (with konqueror mainly) made me think that we need to give more power to the themes and put less cruft in core. José A Reyero came with that exact same idea [2], which is why I think we should get this idea on the ML. I would like to see one theme in core that does and has it all: AJAX, avatars, icons for user statii, icons in the admin areas, advanced menu styles, and whatever more you can think of. Currently we all "enforce" these things onto all Drupal sites, while in fact we could (and should IMHO) ship a lightweighted drupal. Yet show the power of Drupal in a full featured theme. What do you ppl think? put AJAX in one core theme? Add the online offline icons there? Add more features to a theme? [1] http://drupal.org/node/29281 [2] http://drupal.org/node/30150 Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
My concern is that theme developers may not be good code developers. One should be able to leverage some Ajax coolness, for instance, without having to know how to write it in the theme. Ajax is highly non-trivial, and we want to have consistent behavior for a given Ajax trick regardless of the theme in use. We can't do that if we're relying on theme developers to know how to write good, clean Ajax code. Now, if all of the Ajax functionality was available in core but only activated if some flag is set in a theme, then we're talking. That way theme developers can pick and choose which features they want, but don't have to know the ins and outs of cross-browser Javascript. On Monday 05 September 2005 11:04 am, Bèr Kessels wrote:
Hi,
Recently two issues, namely online/offline icons [1] and several Ajax issues (with konqueror mainly) made me think that we need to give more power to the themes and put less cruft in core.
José A Reyero came with that exact same idea [2], which is why I think we should get this idea on the ML.
I would like to see one theme in core that does and has it all: AJAX, avatars, icons for user statii, icons in the admin areas, advanced menu styles, and whatever more you can think of. Currently we all "enforce" these things onto all Drupal sites, while in fact we could (and should IMHO) ship a lightweighted drupal. Yet show the power of Drupal in a full featured theme.
What do you ppl think? put AJAX in one core theme? Add the online offline icons there? Add more features to a theme?
[1] http://drupal.org/node/29281 [2] http://drupal.org/node/30150
Regards, Bèr
-- 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
I am sorry for being unclear, again!. Op maandag 05 september 2005 21:47, schreef Larry Garfield:
Now, if all of the Ajax functionality was available in core but only activated if some flag is set in a theme, then we're talking. That way theme developers can pick and choose which features they want, but don't have to know the ins and outs of cross-browser Javascript.
My idea, was, indeed, to intrduce some form of (E.G.) theme('form_autofill',$foo, $bar); instead of form_autofill, that does all the checks on its own ,yet fails to improve usability. I would love to see a: theme('AJAX_autofill', $foo, $bar) that is only enabled in a few themes, yet, not default drupal behaviour Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05 Sep 2005, at 10:14 PM, Bèr Kessels wrote:
theme('AJAX_autofill', $foo, $bar) that is only enabled in a few themes, yet, not default drupal behaviour
I am 100% opposed to having that be handled by the theme layer. I believe it's core functionality, and it has NOTHING (less than nothing actually) to do with the theme. I don't have an issue with there being a variable, in settings.php (not in the interface) that allows you to change the behaviour. I do however think that we need a new default theme =) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDHV6BgegMqdGlkasRAiRJAJ9QXMN5XA85DinzpqMr2/tHbFuyPQCfVWWr ++4V83gphmmnYE6PyTDr9ys= =cBqk -----END PGP SIGNATURE-----
Op dinsdag 06 september 2005 11:16, schreef Adrian Rossouw:
On 05 Sep 2005, at 10:14 PM, Bèr Kessels wrote:
theme('AJAX_autofill', $foo, $bar) that is only enabled in a few themes, yet, not default drupal behaviour
I am 100% opposed to having that be handled by the theme layer. I believe it's core functionality, and it has NOTHING (less than nothing actually) to do with the theme.
No, no,no. I never meant to move logic into the themes. I am saying that we should have a theme that has all the advanced theming stuff enabled *and* that lives in core. On top of that, I would like to see AJAX stuff disabled by default, but enabled in that same advanced theme. AJAX ATM is broken. Not just not working, but it does not degrade, which simply breaks the site. I cannot use drupal in konqueror anymore. That should never be allowed. And it is not a matter of fixing it for konqueror, because then FooBar browser, will break. In some future. I t is a matter of allowing more choice. I find the theme level a perfect place for such a choice. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Bèr Kessels wrote:
Op dinsdag 06 september 2005 11:16, schreef Adrian Rossouw:
On 05 Sep 2005, at 10:14 PM, Bèr Kessels wrote:
theme('AJAX_autofill', $foo, $bar) that is only enabled in a few themes, yet, not default drupal behaviour
I am 100% opposed to having that be handled by the theme layer. I believe it's core functionality, and it has NOTHING (less than nothing actually) to do with the theme.
No, no,no. I never meant to move logic into the themes.
I am saying that we should have a theme that has all the advanced theming stuff enabled *and* that lives in core.
On top of that, I would like to see AJAX stuff disabled by default, but enabled in that same advanced theme.
That is exactly what I think. It's like having core providing both alternatives, but never enforcing javascript. While I agree some ajax support needs to be in core, I don't like having it as a mandatory default. So, what I mean, I.e. , is: theme('ajax_table'... ) with ajax stuff and theme('table',....) free of javascript, just old plain good HTML, well tested stuff :-) Then, individual themes can use whatever they like. I actually don't mind which is the default theme - maybe full enabled AJAX could be better to impress new users :-), as long as I can have one in plain HTML
On Tuesday 06 September 2005 11:51 am, Jose A. Reyero wrote:
It's like having core providing both alternatives, but never enforcing javascript. While I agree some ajax support needs to be in core, I don't like having it as a mandatory default. So, what I mean, I.e. , is:
theme('ajax_table'... ) with ajax stuff
and
theme('table',....) free of javascript, just old plain good HTML, well tested stuff :-)
Then, individual themes can use whatever they like. I actually don't mind which is the default theme - maybe full enabled AJAX could be better to impress new users :-), as long as I can have one in plain HTML
I grant that I don't know how the new forms api works so I don't know what impact that will have, but isn't theme() called from module code? In that case, wouldn't it be the module developer that is deciding whether or not to Ajax-ify a given block? Module developer != theme developer != site admin != user. I agree that Ajax should not be forced upon the user, but surely it can be done in a cleaner way than that. There *are* ways to make Ajax degrade gracefully; just don't activate it until you've confirmed that the browser has all the features required for a given bit of functionality. (Note: If you're using the onclick, onmouseover, etc. attributes, you're doing it wrong.) If we still want to have it toggleable somehow, in case users either don't like it on principle or run into a bizarre browser setup that we didn't properly account for, that should be either a theme designer toggle or a per-user toggle, not a module coding difference if at all possible. (Yes, some modules will still need to be tweaked to be Ajax friendly.) Making the module developer decide between theme('table' and theme('ajax_table' means the user doesn't get a choice about it. Or am I misunderstanding you completely? :-) -- 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
Op dinsdag 06 september 2005 20:34, schreef Larry Garfield:
or run into a bizarre browser setup that we didn't properly account for
This can, and thus *will* happen. Hence we need to opt-in and not opt-out java stuff. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On 06/09/05, Bèr Kessels <berdrupal@tiscali.be> wrote:
Op dinsdag 06 september 2005 20:34, schreef Larry Garfield:
or run into a bizarre browser setup that we didn't properly account for
This can, and thus *will* happen. Hence we need to opt-in and not opt-out java stuff.
In an extreme case, javascript in Drupal might prevent a user from being able to do anything. At that point, I'd agree with an opt-in as opposed to opt-out. I disagree with most suggestions so far that the option should be a site-wide setting. It is a personal preference for specific users of a site. If the javascript doesn't work for them, then they can turn it off. The ideal solution so far is still to simply make the javascript work / degrade correctly in all browsers. -- David Carrington
AJAX functionality is not something that should be built-in to one 'advanced' theme, and totally unavailable in other themes. Say, for example, that we put all the AJAX stuff into pushbutton. But then webmaster Joe Foo comes along, and wants a hip-hop AJAX-powered site, but he wants to use chameleon as the basis of his site's theme. He'll have to port all the AJAX code into chameleon (or vice versa), just to get what he wants. Is this really how we want to do it? AJAX functionality should be a site-wide configurable option. I can see why some people want it in settings.php (i.e. if AJAX is broken on your site, and you can't turn off AJAX because you have to go into your site which is broken, you've got a catch-22). But from a usability perspective, it really belongs in admin > settings. And in the long run, all JS in Drupal can and will (and should already) degrade gracefully on non-supported browsers (e.g. Konqueror, Safari sometimes), so the catch-22 won't exist. Webmaster Joe Foo wants to be able to enable theme Foobar on his site, and then go to admin > settings, tick the 'Enable Dynamic HTML' (or some such) option, and have it all Just Work (tm). For this to happen, both themes and modules must be written in a JS-independent manner, with some kind of handler in the middle (similar to the theme() override system) to determine whether to output a basic or an advanced HTML page. Jaza. On 9/6/05, Adrian Rossouw <adrian@bryght.com> wrote:
I am 100% opposed to having that be handled by the theme layer. I believe it's core functionality, and it has NOTHING (less than nothing actually) to do with the theme.
I don't have an issue with there being a variable, in settings.php (not in the interface) that allows you to change the behaviour.
I do however think that we need a new default theme =)
On 05/09/05, Bèr Kessels <berdrupal@tiscali.be> wrote:
What do you ppl think? put AJAX in one core theme? Add the online offline icons there? Add more features to a theme?
I think enabling these kind of features on a per-theme basis is not the way to go. I consider it similar to say that the node delete button (or any other helpful feature) should only be included in certain themes. An example would be a website with multiple themes, where users would be confused when they change theme and suddenly don't have the same functionality that they had a moment ago. -- David Carrington
Op dinsdag 06 september 2005 10:27, schreef David Carrington:
On 05/09/05, Bèr Kessels <berdrupal@tiscali.be> wrote:
What do you ppl think? put AJAX in one core theme? Add the online offline icons there? Add more features to a theme?
I think enabling these kind of features on a per-theme basis is not the way to go. I consider it similar to say that the node delete button (or any other helpful feature) should only be included in certain themes.
An example would be a website with multiple themes, where users would be confused when they change theme and suddenly don't have the same functionality that they had a moment ago.
You are somehow correct. For the case of the online/offline buttons: they surely belong in a theme, not? The ajax is somewhat functionality, but it still lives in theme functions. So ATM you can "switch" it off in your theme. And ajax _should_ alway degrade nicely, so that if you do not have the functionality, you will have the same abilities, yet somewhat slower. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Tuesday, September 6, 2005, 11:21:13 AM, Bèr Kessels wrote:
You are somehow correct. For the case of the online/offline buttons: they surely belong in a theme, not?
Yes, but that isn't really a problem is it? If the images are set in CSS just override it in your theme CSS, if its not in CSS just make a theme_* function for it that can be overridden by themes. No different from how other icons are handled. -- Kjartan <kjartan@zind.net> :: "C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, it blows away your whole leg." - Bjarne Stroustrup
participants (7)
-
Adrian Rossouw -
Bèr Kessels -
David Carrington -
Jeremy Epstein -
Jose A. Reyero -
Kjartan Mannes -
Larry Garfield