Re: [drupal-devel] settings inconsistencies
On Wed, 02 Feb 2005 03:47:36 -0500, Andre Molnar <mcsparkerton@yahoo.co.uk> wrote:
Dries Buytaert wrote:
That makes the menu too long/flat, IMO. One alternative would be to have 'access control' and 'profile' tabs directly under 'admin - user', instead of under 'admin - user - configure' (one level less deep).
Patch to follow if the attached screen capture is what you would like.
Should be "profile settings" (no "s" on profile). And configure contains the following still? * settings * permissions * roles Personally, I'd love to have an something like Administer -> Permissions that had *just* permissions and roles. Yes, these are tied to "users", but they are a separate activity except when actually applying roles to users. As well, any node access-related options would go in this area (node privacy by role, taxonomy access, etc.). Following that method, configure under user becomes just settings, and we've eliminated an entire level under user. We talk a lot about "setting permissions", but it is at least 4 clicks to get to the permissions screen and not visible at all until you are at Admin > Users > Configure. -- Boris Mann http://www.bryght.com
Could be please leverage these discrussions to a higer level? These issues keep popping up. And whene we solve them on a case-tocase base, we will never have consistancy. We need one, consistent solution!
1) documentation is on http://dev.bryght.com/t/wiki/DrupalRestructure 2) working example is at http://consistent.drupaldevs.org/ Please log in there with your drupal ID, and give me a shout (IM or mail) ***NOTE!! the settings and changes wont make any sense for anonymous **nor** for registered users. Only adminsitrators see how it should look!** So again: Do not start yelling: "it looks like crap" when you do not have admin rights there!!
Bèr Op woensdag 2 februari 2005 10:07, schreef Boris Mann:
On Wed, 02 Feb 2005 03:47:36 -0500, Andre Molnar
<mcsparkerton@yahoo.co.uk> wrote:
Dries Buytaert wrote:
That makes the menu too long/flat, IMO. One alternative would be to have 'access control' and 'profile' tabs directly under 'admin - user', instead of under 'admin - user - configure' (one level less deep).
Patch to follow if the attached screen capture is what you would like.
Should be "profile settings" (no "s" on profile).
And configure contains the following still? * settings * permissions * roles
Personally, I'd love to have an something like Administer -> Permissions that had *just* permissions and roles. Yes, these are tied to "users", but they are a separate activity except when actually applying roles to users. As well, any node access-related options would go in this area (node privacy by role, taxonomy access, etc.).
Following that method, configure under user becomes just settings, and we've eliminated an entire level under user.
We talk a lot about "setting permissions", but it is at least 4 clicks to get to the permissions screen and not visible at all until you are at Admin > Users > Configure.
-- Boris Mann http://www.bryght.com Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Bèr Kessels wrote:
Could be please leverage these discrussions to a higer level?
I read the wiki pages. My 0.02. The real solution is to allow each module to build its own menu/s. Not as local tasks - but full on stand alone menus that get blocked. This guarantees that each menu will automatically have all like items grouped together - and all settings are handled in the right place. user_module should only handle building user menu blocks - right now it is in charge of blocking not only user menu items and user setting menu items - but all module settings menu items as well. Not the place for it IMHO. I had proposed a change to the menu system to allow modules to build their own menus, but I wasn't thinking about the default navigation menu... not until now did I realize new possibilities (if done right) we could: a) unload all sorts of menu block building work from user module (where it shouldn't really be). b) get rid of the menu_module completely (the menu system would remain, but menu administration would be handled by the modules). c) automatically have role based display of module blocks (since all module blocks would be based individual menus) What I had originally proposed for the menu system and book module is only the tip of the iceberg for what could be done if modules build their own menus. This would be a major overhaul - but not too difficult. The framework is all there - its just about refactoring it. I'll be happy to start working on code for this. andre p.s. but since this isn't realistically going to happen by 4.6 we do need to talk about what is best under the current situation.
Op woensdag 2 februari 2005 12:13, schreef Andre Molnar:
Bèr Kessels wrote:
Could be please leverage these discrussions to a higer level?
I read the wiki pages. My 0.02.
The real solution is to allow each module to build its own menu/s. Not as local tasks - but full on stand alone menus that get blocked. This guarantees that each menu will automatically have all like items grouped together - and all settings are handled in the right place.
user_module should only handle building user menu blocks - right now it is in charge of blocking not only user menu items and user setting menu items - but all module settings menu items as well. Not the place for it IMHO.
Right. But the *allow* part should be stressed. It is not *must*. Because, for example, xtrastatistics.module should not make a menu block extra statistics, but should place its menu entries under statistics.
a) unload all sorts of menu block building work from user module (where it shouldn't really be). True. But this should be step #2. First we must agree upon the way menus should be ordered. IMO these are two separate (related, yes, but not depending on one -another) tasks.
b) get rid of the menu_module completely (the menu system would remain, but menu administration would be handled by the modules).
Then you want to give away the power to make your own menu structure, suited for your personal preferences? -1 on that.
c) automatically have role based display of module blocks (since all module blocks would be based individual menus) This is not quite clear. At least I fail to see what this has got to do with the menu-structures.
Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Bèr Kessels wrote:
b) get rid of the menu_module completely (the menu system would remain, but menu administration would be handled by the modules).
Then you want to give away the power to make your own menu structure, suited for your personal preferences? -1 on that.
hehe - okay not remove it completely - but its role as the place to the maintain the main menu would be taken away
c) automatically have role based display of module blocks (since all module blocks would be based individual menus)
This is not quite clear. At least I fail to see what this has got to do with the menu-structures.
right - this was a combination of me mixing abstraction layers in my head - and getting ahead of myself - sorry. andre
Bèr Kessels wrote:
Right. But the *allow* part should be stressed. It is not *must*. Because, for example, xtrastatistics.module should not make a menu block extra statistics, but should place its menu entries under statistics.
Yes - clearly. If a module's primary purpose is to extend an existing module - that it would follow that it would append its additional administration settings to the original module's menu. Allow - not must andre
Bèr Kessels wrote:
Op woensdag 2 februari 2005 12:13, schreef Andre Molnar:
Bèr Kessels wrote:
Could be please leverage these discrussions to a higer level?
I read the wiki pages. My 0.02.
The real solution is to allow each module to build its own menu/s. Not as local tasks - but full on stand alone menus that get blocked. This guarantees that each menu will automatically have all like items grouped together - and all settings are handled in the right place.
user_module should only handle building user menu blocks - right now it is in charge of blocking not only user menu items and user setting menu items - but all module settings menu items as well. Not the place for it IMHO.
Right. But the *allow* part should be stressed. It is not *must*. Because, for example, xtrastatistics.module should not make a menu block extra statistics, but should place its menu entries under statistics.
In actuality the extension of a module in that manner should not happen. This is against the whole concept of plugin modularity. Probably the reason for the prolification of modules is that they are not autonomous as they should be. Many of the present modules should be completed as variants of the original an thus be able to relplace them entirely. If a module is dependant on another module for UI controls then that module should be able to replace the original entirely. In this case statistics.module would not be used or installed but xtrastatistics.module would replace it and carry with it all statistics functionality and the newer functions along with the necessary UI. This philosofy is one that is solid in other software industries but only in parts of Drupal. Holding to it in the case of modules would solve a lot of the problems with UI and and database modification. -- Carl McDade
Carl, I couldn't disagree with you more. Carl McDade wrote:
In actuality the extension of a module in that manner should not happen. This is against the whole concept of plugin modularity. Probably the reason for the prolification of modules is that they are not autonomous as they should be. Many of the present modules should be completed as variants of the original an thus be able to relplace them entirely.
What happens when you have two modules that append functionality to an existing module. If you do this then you would need 4 different files that administrators have to choose between to get functionality they want. e.g. example.module example_with_extension1.module example_with_extension2.module example_with_extension1_and_with_extension2.module Now how about 3? You do the binary math and you will see how quickly this could get out of control. And how do you maintain this? If something changes in example.module what do you do with [say] 127 different files that all have the same code embedded in them? This is the exact opposite of modularity.
This philosofy is one that is solid in other software industries but only in parts of Drupal. Holding to it in the case of modules would solve a lot of the problems with UI and and database modification.
Solid? What you describe is unmaintainable bloat. andre
Andre Molnar wrote:
Carl, I couldn't disagree with you more.
Carl McDade wrote:
In actuality the extension of a module in that manner should not happen. This is against the whole concept of plugin modularity. Probably the reason for the prolification of modules is that they are not autonomous as they should be. Many of the present modules should be completed as variants of the original an thus be able to relplace them entirely.
What happens when you have two modules that append functionality to an existing module. If you do this then you would need 4 different files that administrators have to choose between to get functionality they want.
e.g. example.module example_with_extension1.module example_with_extension2.module example_with_extension1_and_with_extension2.module
Now how about 3? You do the binary math and you will see how quickly this could get out of control.
And how do you maintain this? If something changes in example.module what do you do with [say] 127 different files that all have the same code embedded in them?
This is the exact opposite of modularity.
This philosofy is one that is solid in other software industries but only in parts of Drupal. Holding to it in the case of modules would solve a lot of the problems with UI and and database modification.
Solid? What you describe is unmaintainable bloat.
andre
In your example then those modules would be forced to be part of the system core. As a "plugin" module they would not qualify. As stated previously "many" is the key word here. Qualification to either category of "core" or "plugin" should have a line drawn. What I am proposing is a system in the same way an operative system works with drivers which is the proper status of a plugin module. What you are describing in your example is similar to the system of dlls or so where the files may or may not be dependant on other files in a particular group. This is off-topic to this convo but it is important to mention. The reason that Drupal is going to be very hard to optimize performance on is because every module is loaded. This stems from the fact that there is no real definative differences made between the "core modules" and "plugin modules" and there should be. This also leads to the core being bloated as you mentioned. -- Carl McDade Information Technology Consult www.carlmcdade.com carlmcdade@gmail.com Customer Relationship and E-commerce Technology Services for small businesses ____________________________________________________________________________ kläppavägen 9a 82735 Ljusdal Sweden tel.0651-15805 telefax 0651-10875 Organisationsnummer: 590310-2050 VAT-nr. SE590310205001 Innehar F-Skattebevis bankgiro: 5115 4433
Op donderdag 3 februari 2005 09:45, schreef Carl McDade:
This philosofy is one that is solid in other software industries but only in parts of Drupal. Holding to it in the case of modules would solve a lot of the problems with UI and and database modification.
This philosofy is -and i am happy about that- nbot Drupals. It is this philosofy that made *nuke a unmaintanable chaos, anarchy. No, We have this idea of modules-that-extend-modules now, and we will stick to that AFAIKS (AFAIKH as far as i can hope). The next step in this philosofy are the bundlles. For weblinks we are working on an example. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Bèr Kessels wrote:
Op donderdag 3 februari 2005 09:45, schreef Carl McDade:
This philosofy is one that is solid in other software industries but only in parts of Drupal. Holding to it in the case of modules would solve a lot of the problems with UI and and database modification.
This philosofy is -and i am happy about that- nbot Drupals. It is this philosofy that made *nuke a unmaintanable chaos, anarchy.
No, We have this idea of modules-that-extend-modules now, and we will stick to that AFAIKS (AFAIKH as far as i can hope). The next step in this philosofy are the bundlles. For weblinks we are working on an example.
Regards, Bèr
This paradigm is not condusive to bloat or anarchy in that the true core is controlled and developed with care. The core does not have to make accomodations for a needed functionality to be added. What this allows is the implementation of other software as modules and the possiblilty of developing modules as stand alone software. The ability to borrow from or connect to the core rather than weighing it down with interdependancies is the best method for continued improvement without the luggage of performance and usability problems. Items brought into the core could actually be made smaller and more powerful by bringing them closer to the core rather than weakening the core by making adhoc adjustments and increasing its size with extensions. Mvh -- Carl McDade Information Technology Consult www.carlmcdade.com carlmcdade@gmail.com
Op donderdag 3 februari 2005 11:51, schreef Carl McDade:
This paradigm is not condusive to bloat or anarchy in that the true core [...] adjustments and increasing its size with extensions.
The success of the various unices (linux at the top) lies in the fact that small progams (anloge: modules) do one thing, but do it well. Instead of that windows-environment where you need yet another Freeware app to do yet another task only to find out it does neraly the same as foobar, with that minor difference. I.e: there is not one single CD burner application for windows that does its job good and nothing more. you will find loads of apps that allow you rto rip, collect, and even play music. So why should we need: burner.module burner-with-ripper.module burner-withplayer.module burner-with-oggplayer.module when the best solution is to have burner.module, ripper.module, player.module ogg.module. And to make them work together? Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Bèr Kessels wrote:
Op donderdag 3 februari 2005 11:51, schreef Carl McDade:
This paradigm is not condusive to bloat or anarchy in that the true core [...] adjustments and increasing its size with extensions.
The success of the various unices (linux at the top) lies in the fact that small progams (anloge: modules) do one thing, but do it well. Instead of that windows-environment where you need yet another Freeware app to do yet another task only to find out it does neraly the same as foobar, with that minor difference. I.e: there is not one single CD burner application for windows that does its job good and nothing more. you will find loads of apps that allow you rto rip, collect, and even play music. So why should we need: burner.module burner-with-ripper.module burner-withplayer.module burner-with-oggplayer.module
when the best solution is to have burner.module, ripper.module, player.module ogg.module. And to make them work together?
Regards, Bèr
That solution is fine as long as the core is player.module and burner and ripper and ogg. There would be problems though if someone wanted to extend player module in a manner that does not actually add function but in reality changes player.module to something other than its original capabilities. ie the original: player.module (wmv,mpeg,asf) /burner /ripper /ogg In the present state of thingswith a closed system core, needing to add Mpeg2 functionality would be: player.module (wmv,mpeg,asf) /burner /ripper /ogg -> newplayer.module (mpeg2) /burner /ripper /ogg or player.module ( /burner /ripper /ogg) wmv,mpeg,asf -> newplayer.module (mpeg2) So you can see where the module bloat is coming from. Inorder to use any of the players two modules have to be loaded everytime because of their interdependacy. The module rather than being upgraded by the new functionality becomes interdependant. The solution to this would of course be to redo the core module so that it is open to all formats and does not provide its own core format. this way would set only one : player.module ( /burner /ripper /ogg) -> newplayer.module (wmv,mpeg,asf ,mpeg2) or player.module ( /burner /ripper /ogg) -> newplayer.module (wmv,mpeg) -> newplayer.module (asf ,mpeg2) This is of course is a large task and smacks of OOP. So a good end solution would be to remove player .module from it's "core" status and set it to "plugin" status this would allow it to be changed to: player.module (wmv,mpeg,asf,mpeg2) /burner /ripper /ogg Which would reduce the load on the core and give more flexibility to the module. The decision to make the player.module part of the core was not a good one. The player.module should have been a fully seperate module to begin with. This goes back to my previous statement that "many" of the modules should not be extended but made replacable. This does not apply to every module and there should be a set criteria for "core" and "plugin". I hope this is confusing enough to understand ;) -- Carl McDade Information Technology Consult www.carlmcdade.com carlmcdade@gmail.com Customer Relationship and E-commerce Technology Services for small businesses ____________________________________________________________________________ kläppavägen 9a 82735 Ljusdal Sweden tel.0651-15805 telefax 0651-10875 Organisationsnummer: 590310-2050 VAT-nr. SE590310205001 Innehar F-Skattebevis bankgiro: 5115 4433
I really don't understand you here. But since this is all talk, instead of concrete proposals, I leave it with this. If you want to see the module system in Drupal changed, please providea concrete proposal, with use of cases, examples, and off course reasons why it would be better. Bèr Op donderdag 3 februari 2005 13:29, schreef Carl McDade:
Bèr Kessels wrote:
Op donderdag 3 februari 2005 11:51, schreef Carl McDade:
This paradigm is not condusive to bloat or anarchy in that the true
core
[...] adjustments and increasing its size with extensions.
The success of the various unices (linux at the top) lies in the fact that small progams (anloge: modules) do one thing, but do it well. Instead of that windows-environment where you need yet another Freeware app to do yet another task only to find out it does neraly the same as foobar, with that minor difference. I.e: there is not one single CD burner application for windows that does its job good and nothing more. you will find loads of apps that allow you rto rip, collect, and even play music. So why should we need: burner.module burner-with-ripper.module burner-withplayer.module burner-with-oggplayer.module
when the best solution is to have burner.module, ripper.module, player.module ogg.module. And to make them work together?
Regards, Bèr
That solution is fine as long as the core is player.module and burner and ripper and ogg. There would be problems though if someone wanted to extend player module in a manner that does not actually add function but in reality changes player.module to something other than its original capabilities.
ie the original:
player.module (wmv,mpeg,asf) /burner /ripper /ogg
In the present state of thingswith a closed system core, needing to add Mpeg2 functionality would be:
player.module (wmv,mpeg,asf) /burner /ripper /ogg -> newplayer.module (mpeg2) /burner /ripper /ogg or player.module ( /burner /ripper /ogg) wmv,mpeg,asf -> newplayer.module (mpeg2)
So you can see where the module bloat is coming from. Inorder to use any of the players two modules have to be loaded everytime because of their interdependacy. The module rather than being upgraded by the new functionality becomes interdependant. The solution to this would of course be to redo the core module so that it is open to all formats and does not provide its own core format. this way would set only one :
player.module ( /burner /ripper /ogg) -> newplayer.module (wmv,mpeg,asf ,mpeg2) or player.module ( /burner /ripper /ogg) -> newplayer.module (wmv,mpeg) -> newplayer.module (asf ,mpeg2)
This is of course is a large task and smacks of OOP. So a good end solution would be to remove player .module from it's "core" status and set it to "plugin" status this would allow it to be changed to:
player.module (wmv,mpeg,asf,mpeg2) /burner /ripper /ogg
Which would reduce the load on the core and give more flexibility to the module. The decision to make the player.module part of the core was not a good one. The player.module should have been a fully seperate module to begin with. This goes back to my previous statement that "many" of the modules should not be extended but made replacable. This does not apply to every module and there should be a set criteria for "core" and "plugin".
I hope this is confusing enough to understand ;) Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On Thu, 3 Feb 2005 13:47:06 +0100, Bèr Kessels <berdrupal@tiscali.be> wrote:
I really don't understand you here.
I really don't understand what all the confusion is about either. There is a big difference in requirements between a web application and a desktop application. A web application must be tailored to load as little code as possible for each "screen" to provide good performance so loading everything into a core is undesirable. There are also many server applications that load modules only when they are needed (like Apache). The ability for modules to extend other modules is the foundation of Drupal. Otherwise, node.module would need to understand and handle every input on the node creation form, from story text to file attachments and image captchas. User's would no longer have the ability to disable (or simply not install) the captcha module to remove this functionality. As Bèr suggested, perhaps you should provide some code which can demonstrate a better approach.
... remove player .module from it's "core" status and set it to "plugin" status this would allow it to be changed to:
player.module (wmv,mpeg,asf,mpeg2) /burner /ripper /ogg
Which would reduce the load on the core and give more flexibility to the module. The decision to make the player.module part of the core was not a good one. The player.module should have been a fully seperate module to begin with. This goes back to my previous statement that "many" of the modules should not be extended but made replacable. This does not apply to every module and there should be a set criteria for "core" and "plugin".
I think there is a mixup of ideas. What is core, what is module, what is plugin. Core is a tested and accepted bundle of apis and modules. It is a distribution thing, rather a 'program he structure' thing. Modules, or plugins (like the flexinode ones) are extensions using an api to be included in a setup. The module bloat - the number of modules in contrib is natural. People have ideas, people want changes, people not always agree on changes, others don't care or don't know about these changes, so follows (nearly) duplicate functionality. Sometimes there are competing modules/solutions, and it is not clear which one is better. That is not a drupal phenomenon, it is very common when you have the freedom to use and abuse code and the will to share the results. The good solutions meeting some common requirements, like need, popularity, quality end up in core - core drupal distribution. Core functionality ends up in the other core - drupal apis, like the file-api, it is lightweight and useful. I reckon there is term overloading going on here. IMO the project structure is clear and understandable, one of the main reasons I actually ended up using and abusing drupal. If I don't like something or require something extra - there is a clean way to do it. Core/Contrib split is understandable. The case with the settings is more of a UI issue, which needs resolving by actually finding the best solution for the current structure, rather than assuming it is failure by design (core design). I think the UI team have some good ideas and attitude, but since I'm no expert there I can only criticise or complain, and I've done enough of that. 2pc Vlado -- Vladimir Zlatanov <vlado@dikini.net>
Forgive me its late (now early) and my thinking is cloudy and not precise. I am starting to mix my layers of abstraction - and re-reading what I wrote doesn't make sense (not the way I wrote it). It all boils down to the fact that each module's menu needs to be distinguished from other module's menus. The menu_block call should be responsible for handing off block generation for each and every menu. (not the way user module is handing off that job now) modules could also generate menus of other types - not just admin menus. Sorry for the confusion - hopefully these two messages put together paint a clearer picture of what I am talking about. Now I need some sleep. andre Andre Molnar wrote:
Bèr Kessels wrote:
Could be please leverage these discrussions to a higer level?
I read the wiki pages. My 0.02.
The real solution is to allow each module to build its own menu/s. Not as local tasks - but full on stand alone menus that get blocked. This guarantees that each menu will automatically have all like items grouped together - and all settings are handled in the right place.
user_module should only handle building user menu blocks - right now it is in charge of blocking not only user menu items and user setting menu items - but all module settings menu items as well. Not the place for it IMHO.
I had proposed a change to the menu system to allow modules to build their own menus, but I wasn't thinking about the default navigation menu... not until now did I realize new possibilities (if done right) we could:
a) unload all sorts of menu block building work from user module (where it shouldn't really be).
b) get rid of the menu_module completely (the menu system would remain, but menu administration would be handled by the modules).
c) automatically have role based display of module blocks (since all module blocks would be based individual menus)
What I had originally proposed for the menu system and book module is only the tip of the iceberg for what could be done if modules build their own menus.
This would be a major overhaul - but not too difficult. The framework is all there - its just about refactoring it.
I'll be happy to start working on code for this.
andre
p.s. but since this isn't realistically going to happen by 4.6 we do need to talk about what is best under the current situation.
On Wed, 2 Feb 2005 10:52:25 +0100, Bèr Kessels <berdrupal@tiscali.be> wrote:
Could be please leverage these discrussions to a higer level?
These issues keep popping up. And whene we solve them on a case-tocase base, we will never have consistancy. We need one, consistent solution!
I too would urge that we not make yet another round of rushed organizational changes. It may be hard to find things now but finding them when they move around every release is frustrating too. I think that the best thing to do is identify a few individuals who are more specialized in UI design and let them come up with an overall organizational structure which fits where Drupal is and where it's going. Designing by committee may give everyone a warm fuzzy feeling but is quite likely to result in...well, what we have now.
Boris Mann wrote:
Patch to follow if the attached screen capture is what you would like. Should be "profile settings" (no "s" on profile).
Yup - typo :P
And configure contains the following still? * settings * permissions * roles
see attached
Personally, I'd love to have an something like Administer -> Permissions that had *just* permissions and roles. Yes, these are tied to "users", but they are a separate activity except when actually applying roles to users. As well, any node access-related options would go in this area (node privacy by role, taxonomy access, etc.).
That is actually the current state of CVS - except that 'rules' are also there.
We talk a lot about "setting permissions", but it is at least 4 clicks to get to the permissions screen and not visible at all until you are at Admin > Users > Configure.
Well the attached screen capture is halfway between the two options - 2 less click from the way it used to be - and one more click from the way it is right now. A pretty good trade off IMO. Keeps it grouped with users and still saves clicks. andre
participants (6)
-
Andre Molnar -
Boris Mann -
Bèr Kessels -
Carl McDade -
Chris Cook -
Vladimir Zlatanov