[drupal-devel] Idea - move help text out of code into database
I'm going to re-float here on both lists the idea of having each module's help texts provided within the Drupal database, as opposed to being hardcoded in. Advantages: the help text documentation would be - easier to maintain - easier to translate - easy to tailor to user's experience level and preferences (tag each helptext with a 'User experience level" vocabulary and select the text according to the user's preferences) I think it would make the code easier to maintain also. Code review and documentation review could occur independently. Comments? Djun
On 12 May 2005, at 11:05 PM, Kieran Lal wrote:
On May 12, 2005, at 10:56 PM, puregin wrote:
Comments?
You write it, and we will use it. :-)
I was hoping someone would tell me it's already been done, just like all of my other 'brilliant' ideas ;-) Djun
On Fri, 13 May 2005, puregin wrote:
On 12 May 2005, at 11:05 PM, Kieran Lal wrote:
On May 12, 2005, at 10:56 PM, puregin wrote:
Comments?
You write it, and we will use it. :-)
I was hoping someone would tell me it's already been done, just like all of my other 'brilliant' ideas ;-)
There's a theory that says that if you wait long enough it will happen. ;) Cheers, Gerhard
I like this; But i foresee quite some difficulties with providing those texts as data for the database. Not all modules have a modulename.[my/pg]sql file. and making the file mandatory only for the help text is not a good option IMO. Also: what we need, IMO is a help-tyext importer. One that makes nodes (or other **searchable**) content on drupal.org from the help texts. Op vrijdag 13 mei 2005 07:56, schreef puregin:
I'm going to re-float here on both lists the idea of having each module's help texts provided within the Drupal database, as opposed to being hardcoded in.
Advantages: the help text documentation would be - easier to maintain - easier to translate - easy to tailor to user's experience level and preferences (tag each helptext with a 'User experience level" vocabulary and select the text according to the user's preferences)
I think it would make the code easier to maintain also.
Code review and documentation review could occur independently.
Comments?
Djun
Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
I fully agree. I have a few modules that do not use database at all, and are popular because of that among the less technically inclined. Perhaps help can be in a central table for all modules, and then there is a file with each module that the install process populates the database with? The author only maintains the help file with each release. Could be tediuos for upgrades, ...etc. On 5/13/05, Bèr Kessels <berdrupal@tiscali.be> wrote:
I like this; But i foresee quite some difficulties with providing those texts as data for the database. Not all modules have a modulename.[my/pg]sql file. and making the file mandatory only for the help text is not a good option IMO.
On May 12, 2005, at 10:56 PM, puregin wrote:
Comments?
I actually think that not only should it be in the database but that the database should be populated over xml-rpc. Why? CivicSpace, Development Seed, Bryght, Bloggers all have different target audiences. We should allow for the complete customization of admin/help documentation. This is similar to the system module which allows for different site directories to be created with an XML- RPC call. Imagine if you will you are a small independent contractor and you get a call from a client saying they can't figure out how to use taxonomy. Change the admin help documentation on the source server and tell them to go to cron.php. POOF instant understandable documentation. Of course, if I a patch doesn't get submitted to add this functionality in the next 72 hours or so I am going to go ahead and submit all 60 module admin help patches to head anyway. :-) Cheers, Kieran
On Fri, May 13, 2005 at 07:50:14AM -0700, Kieran Lal wrote:
On May 12, 2005, at 10:56 PM, puregin wrote:
Comments?
I actually think that not only should it be in the database but that the database should be populated over xml-rpc. Why?
Before deciding on XML-RPC we need to decide if documention will be pulled from servers or pushed to individual Drupal installations. I expect for the best security and reliability it must be pull. This means we are just grabbing public information off a server. No need for something as complex as XML-RPC. Just throw it in XML so there is an adequate place to keep any metadata. It could even use RSS, although I think we should avoid using RSS for things which don't need it. -Neil
Op vrijdag 13 mei 2005 20:33, schreef neil@civicspacelabs.org:
. It could even use RSS, although I think we should avoid using RSS for things which don't need it.
True, but RSS is for "free". the parsers are in core already, the RSS generators for Drupal are tested and proven. I think that alone is big pro for choosing an existing system. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
I'm going to re-float here on both lists the idea of having each module's help texts provided within the Drupal database, as opposed to being hardcoded in.
Advantages: the help text documentation would be - easier to maintain
Not going to be easier to maintain, since it would be in database.[my|pg]sql instead of the module files. In fact, it would need to be in both SQL files.
- easier to translate
I don't see your point. Isn't the PO files already easy to translate.
- easy to tailor to user's experience level and preferences (tag each helptext with a 'User experience level" vocabulary and select the text according to the user's preferences)
This might be interesting, but is probably easier to do without moving help text around. Goba
participants (7)
-
Bèr Kessels -
Gabor Hojtsy -
Gerhard Killesreiter -
K B -
Kieran Lal -
neil＠civicspacelabs.org -
puregin