- Development - lists.drupal.org

[drupal-devel] Does the Forms API give Drupal a model view controller architecture
by Kieran Lal 27 Sep '05

27 Sep '05

Here's a quick overview of Model View Controller architectures that was updated in April 2005. http://www.jdl.co.uk/briefings/MVC.pdf I haven't spent a lot of time thinking about this. 1) Modules represent the model. They are unaware of the view, theme. 2) View - To me there are three stock views, or outputs, in Drupal. The first is just themeless output. The second is the themed output. The third is as an XML-RPC request. 3) Controller-this is traditionally about controlling input. The controller knows about it's views. The question is, does Drupal have a controller, and if it does, is it the Forms API. This is a question that is consistently coming up in comparing Drupal to Ruby On Rails and I'd like to have a solid answer. Cheers, Kieran

7 10

Re: [drupal-devel] A collection of usability problems
by Kobus Myburgh 26 Sep '05

26 Sep '05

> I think it does help. Extending the regexp to also cover node/*/edit and > user/*/edit can't be that hard. Excuse the off topic post here, but I read this here and was wondering about that many times before. Why can't we do it /node/edit/4/* instead of /node/*/edit? Would make a lot of little nagging problems I have to code around all the time go away... :-) Regards, Kobus

2 1

Re: [drupal-devel] A collection of usability problems
by Kobus Myburgh 26 Sep '05

26 Sep '05

I have added the appropriate two pages here[1] and here[2]: I conclude that this usability issue is now closed from the question Dries asked: > Problem #6: quite some people use the front page module. I've never > used the front page module but I'd like to know how it is different > from a static page? The key difference I see is that you ca have a > different front page for anonymous users. If that is the only key > difference, why aren't people using static pages? Something is wrong > here, and I'd like to figure out what. Now is the next step - will this functionality (or similar) be built into Core to finally give this usability problem the death-blow? [1] http://drupal.org/node/32257 [2] http://drupal.org/node/32258 Regards, Kobus >>> kieran(a)civicspacelabs.org 9/23/2005 6:42 PM >>> Creating an admin help page for the front page module with a child page page that includes what you have below would be great. One of the things that is coming back from the user research is the idea of structural administration. Cheers, Kieran On Sep 23, 2005, at 4:06 AM, Kobus Myburgh wrote: > Ok, as promised: > > I have installed front_page module on one of my sites, generated > some silly HTML to use as front page text, and set the settings for > the module. These are my findings: > > (Please note - this is not a review of front_page.module, but > rather a comparison of it with static nodes). > > 1. Frontpage module offers you several options for displaying: > > - For anonymous users: > > * themed - uses your current site's theme to dsplay your > text/code > * full - bypasses your sites theme, uses only your > specified text/code > * redirect - redirects you to another page/node/image/etc. > > - For logged in users: > > * same as for anonymous users > * option to have it the same as for anonymous users > > 2. Static pages can offer you a lot of the above, but, it has a LOT > more administration to do. For example, to implement these features > with static pages, you'd have to: > > 1. Check whether the person is logged in. > 2. Set all the blocks not to display on that particular page. > 3. Must know some PHP to do #1 and to do redirects - can't > use logic in HTML. > 4. No way to disable the logo section of the theme for the > page (e.g. I might just want an enlarged version of my logo with a > few bullets of text on the main page - no other themable objects), > without using another module (I think Gerhard had such a module > where you can have a different logo for the front page). > > Basically, all in all, front_page module makes things MUCH simpler, > and offers more choice than static pages. Static pages for front > pages is too involved for newbies (and lazy admins...) and > front_page module provides a great (and completely functional) > alternative. > > HTH > > Kobus > > > >>>> ITBJDM(a)puknet.puk.ac.za 9/23/2005 10:39:23 AM >>> >>>> >> Problem #6: quite some people use the front page module. I've never >> used the front page module but I'd like to know how it is different >> from a static page? The key difference I see is that you ca have a >> different front page for anonymous users. If that is the only key >> difference, why aren't people using static pages? Something is wrong >> here, and I'd like to figure out what. >> > > I'll take care of this one - giving a complete overview of the > front page module. I will highlight the differences between a > static page and the front page module and then the developers can > determine what to do with regards to this analysis. > > Regards, > > Kobus > > PS: Can we have a list drupal-usability? Or is that overkill? > > > > >

1 0

[drupal-devel] Re: [CS dev] Passing on Spread Firefox, Lincoln's Revenge, Democratica themes
by Chris Messina 26 Sep '05

26 Sep '05

Hey Trae, Makes perfect sense. That's exactly what I intended my theme work to be used for. Basically a CSS Zen Garden in a theme! So yeah, I don't know how to do it, but I would very much like to pass the maintainship of the themes over to you. How do we do that on Drupal.org? Chris On 9/25/05, Trae McCombs <occy(a)occy.net> wrote: > Hi Chris, > > These themes will be rolled into the new CivicSpace theme when we get > the time. The "skins"(as we are calling them -- more on that later) > will be pulled in. > > I am also going to be porting the occy.net theme to be a "skin" for the > CS theme, and we'll be taking submissions, for other included skins(and > layouts) after things get settled down. > > I am very excited about where the CS theme is going to go, it's just > going to take a wee bit of time(not too much more though) to get there. > > Trae > > PS. Just as a note: > > We have a new system we are building into the CS theme. Layouts and Skins. > > Layouts will be "plain" element positions. These layouts can be used as > a base theme if you want to build a "skin" on top of it. > > A Skin for the CS theme is going to be the actual theme, or style. You > should be able to take a skin, and move it to another layout and get a > different layout but with the same colors. > > This might not make sense now, but when we get things polished, and the > documentation(Robin "mozillaman" Monks will be writing) is done, I'm > sure everyone will see the huge benefits. > > Chris Messina wrote: > > Hey all, > > > > I'm looking for a new maintainer for Spread Firefox, Lincoln's > > Revenge, Democratica who can take those original styles and port them > > to the CivicSpace XHTML foundation > > (http://drupal.org/project/civicspace_theme) If you want details on > > this task, let me know. It's just become quite obvious that I don't > > have the time to maintain these themes and it's time for someone else > > to move them forward! > > > > Chris > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: civicspace-dev-unsubscribe(a)civicspacelabs.org > > For additional commands, e-mail: civicspace-dev-help(a)civicspacelabs.org > > > > -- > Trae "occy" McCombs || http://occy.net/ > Founder - Themes.org // Linux.com > CivicSpaceLabs - http://civicspacelabs.org/ >

2 1

[drupal-devel] really really really really off-topic
by Adrian Rossouw 26 Sep '05

26 Sep '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 <itior> XML is like violence, if it doesn't solve the problem, just use more. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDN/FZgegMqdGlkasRAsbfAJ4wEEZ3hUfNJtXc7d+fVRXA+dZU+QCeNSiZ X6KH2X1v+2vPQbeff8KAi7U= =kXeZ -----END PGP SIGNATURE-----

1 0

Re: [drupal-devel] A collection of usability problems
by Kobus Myburgh 26 Sep '05

26 Sep '05

Ermmm... I meant /node/edit/* instead of /node/*/edit Kobus >>> ITBJDM(a)puknet.puk.ac.za 9/26/2005 12:58 PM >>> > I think it does help. Extending the regexp to also cover node/*/edit and > user/*/edit can't be that hard. Excuse the off topic post here, but I read this here and was wondering about that many times before. Why can't we do it /node/edit/4/* instead of /node/*/edit? Would make a lot of little nagging problems I have to code around all the time go away... :-) Regards, Kobus

1 0

[drupal-devel] Passing on Spread Firefox, Lincoln's Revenge, Democratica themes
by Chris Messina 26 Sep '05

26 Sep '05

Hey all, I'm looking for a new maintainer for Spread Firefox, Lincoln's Revenge, Democratica who can take those original styles and port them to the CivicSpace XHTML foundation (http://drupal.org/project/civicspace_theme) If you want details on this task, let me know. It's just become quite obvious that I don't have the time to maintain these themes and it's time for someone else to move them forward! Chris

1 0

Re: [drupal-devel] two minor usability issues, introduced recently
by Kobus Myburgh 25 Sep '05

25 Sep '05

> We don't have usability tests -- how do you envision this to be done? One hindrance in getting usability testing done is because the usability people are not necessarily technical people. When a new feature comes in as a patch, the usability expert has to patch his copy of Drupal, then get around to test it for usability. This is however not easily done, as I, for example, am a technical dufus with a little bit of coding skills. I am however majoring in usability, so, I can provide some usability testing but where and how? I have a possible solution for this issue. Before reading the proposed solution, keep in mind that it is only to stimulate thought, as I am not sure how technically feasible it is: 1. Set up a site based on HEAD. 2. Assign a technical person to update and maintain it. 3. When an update is applied (patch or other), simply add/update the a "changelog" or "issue" or something. 4. When a usability person analyzes the change, he documents it accordingly on the same issue. 5. Developers read the usability person's report and change the code if necessary. 6. Usability testers get access to test all new aspects of the page/page/feature/whatever. 7. Of course the database might need to be refreshed now and then. Regards, Kobus

3 2

RE: [drupal-devel] Admin theme
by Steven Peck 25 Sep '05

25 Sep '05

>From a usability stand point I can't stand a separate admin area. I tried really hard to like it and had four people whose sites I run try it. They all said that being pulled out of their site was a jolt. With the migration of more of the 'set once a forget it' settings to the admin settings link, stuff iis even easier to find then ever. With roles determining what can be seen, those with limited roles see what they can see within the context of the sites theme without the jolt of going to what seems to be a completely different site. -sp > -----Original Message----- > From: drupal-devel-bounces(a)drupal.org > [mailto:drupal-devel-bounces@drupal.org] On Behalf Of Robert Douglass > Sent: Sunday, September 25, 2005 4:42 AM > To: drupal-devel(a)drupal.org > Subject: Re: [drupal-devel] Admin theme > > I think the CivicSpace admin theme is the model we ought to > be striving for. I love it. > > Bèr Kessels wrote: > > for me the admin theme has a few requirements: > > * it must be able to disable when someone feels he/she is > not helped with it. > > * it must be profilable (a forum site has a different > concept of what > > pages are admin then a personal blog) > > > > > * tackle this in a blocks/sections alike interface, where sets of > > regexps define what pages are admin and what pages not. > > A set of regexps is the way I'd like to see it implemented. > The two points above would be satisfied by having regexps. > > > * it must be overridable in a theme > > Wouldn't one just change the admin theme? What do you mean by > this last point, Bèr? > > -Robert > >

1 0

[drupal-devel] Help system redesign
by Larry Garfield 25 Sep '05

25 Sep '05

Last night there was a discussion in #drupal regarding the help system, and the need for an overhaul therein. Dries asked me to send a note to this list with what was discussed and the thoughts on where to go with it. This is a developer, documenter, and translator issue, so input from all three parties is welcome. Problems with the current help system, vis, hook_help() ----------------------------------------------------------------------- - Huge blocks o' text in the source code file. - Because the strings are large, translation of help files via PO is slooooow. - Synchronization with the online handbook is tedious and difficult, which means it sometimes doesn't get done. Proposed solution ----------------------- Replace hook_help() with a database-based help lookup system that incorporates translations directly in the database. The database table would look something like this: help ( hid, module, key, locale, helptext ); The key would be a short textual string that identifies the help text in question, serving the same function as $section in hook_help(). (Possibly with the same naming scheme, possibly not.) Then, hook_help() would be replaced with a function help_get(): /* Example function, missing lots of necessary error checks */ function help_get($module, $key, $locale='en') { $help = db_fetch_object(db_query("SELECT helptext FROM {help} WHERE module='%s' AND key='%s' AND locale='%s'", $module, $key, $locale)); return $help->helptext; } What gets returned, then, is an already-localized string, ready for printing/theming/whatevering. The help lookup is always a single database hit, no slow textual substr() matching needed. That also means that PO files are much smaller, and module source code doesn't have to have giant masses of text in it. Issues and solutions -------------------------- Links: I'd say the solution here is to have links flagged in the database for easy conversion by help_get() before they're returned. For example: ... Go to the <link url="admin/modules">modules page</link> to enable... help_get() would then, before returning the string, check for <link> tags, extract the data, and replace it with the output from an l() call. I'm not sure of the efficiency of the syntax above, but something along those lines should be easiest. (Good place for a regex?) Data loading: Of course, there needs to be some way to get helptext into the database in the first place. That would require an auxiliary file along with the .module file, say .help. See below for comments on the format of .help. When the module is enabled on admin/modules, the .help file is parsed into the help table once. When the module is disabled, the help table is cleared of any records for that module to avoid cruft. While this does make enabling and disabling a module a bit slower, that's not done often enough that it should make any practical difference. We would need to then make sure that the module's name and short description are available in the module itself, as those are needed on the admin/modules page. The simplest solution would be to have a hook_module_info() function, which returns an array of the form: array('name' => 'node', 'description' => 'Allows content to be submitted to the site and displayed on pages.'); Those text strings are small enough that they can be handled by the current translation system. admin/modules would then include every .module file (as now) and then call the _module_info() hooks to get the data to display. Data format, data entry, handbook sync -------------------------------------------------- These all dovetail together, so I'm going to discuss them all at once. - The Docs team wants to be able to write help text for core and contrib modules without futzing about with MySQL dumps or some other obscure format. A web-frontend is preferred. - Developers need to be able to enter their own help text without going through the drupal.org docs team. That's especially important for custom modules that need help text but don't end up on Drupal.org for whatever reason. (Custom for a client, commercial modules, etc.) - The Translation people don't want to have to deal with obscure file formats either. - Keeping the text in the online handbook in sync with the in-system text in the actual module should be sufficiently trivial that no one thinks to not do so. That's a tall order, and a problem that hasn't been solved yet. :-) My recommendation for the intermediary help files would be an XML format, one reasonably easy to import/export from the online handbook and reasonably easy to hand-edit. The Docs and Translations teams could then edit the text in the online handbook and export it to the necessary XML files, as can the translation team, while developers can write the XML file directly via their XML editing method of choice. The file needn't be complicated. For instance: <drupal:help module='node' locale='en'> <drupal:entry key="description">Some <b>HTML</b> here.</drupal:entry> <drupal:entry key="stuff">Some other text.</drupal:entry> </drupal:help> When the module is enabled, the XML file is parsed into the help table, as mentioned. It's a one-time event, so performance is a non-issue. There would be a separate file for each locale. So the node module, for instance, would have: node.module node.mysql node.help node.es.help node.de.help ... As now, English would be the default language. Besides being easier to edit, using XML files instead of an SQL dump keeps the help text database-independent. Otherwise, we'd need separate mysql and pgsql files for each locale. Other thoughts ------------------- I have not worked with the current help system that extensively, so I'm not sure how it handles context-sensitive help. By that I mean "What's this?" type help, or other "what do I do on this page" help text. One advantage to this method is that keys reserved for the main help system could be pre-defined, while a module author would be free to add additional help keys for his module. So on the foobar/4/edit page, the module author could write: $output .= theme('help_link', 'foobar', 'edit'); Which would return a formatted link to context-appropriate help, such as: <div class="help-link"><a href="help/foobar/edit">Help on this page</a></div> help/foobar/edit then would trigger the callback for 'help', which would dutifully display the theme('help') for module 'foobar', key 'edit'. Both of those could then be re-themed to allow pop-up help windows, javascript overLib (http://www.bosrup.com/web/overlib/) calls, or whatever else a theme-author felt like doing. Some more thought here is definitely needed, but I'd love to see more non-admin-user context sensitive help in Drupal. Conclusion -------------- I'm sure at least some of the above is insanely stupid, so please point out where gently. :-) Dries said he suspects this would be a 4.8-targeted improvement, which I think is likely given the amount of legacy code and how close we are to 4.7's release. Devs, Docs, and Trans, your input please! My thanks to Dries, Amazon, webcheck, killes, and everyone else who was in the channel last night for this discussion. *dons flame retardant suit* -- Larry Garfield AIM: LOLG42 larry(a)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

10 19