[GRASS-dev] [GRASS GIS] #2593: Use GRASS GIS 7 for module of the day

GRASS GIS trac at osgeo.org
Thu Jun 11 10:14:48 PDT 2015


#2593: Use GRASS GIS 7 for module of the day
--------------------------+-------------------------
  Reporter:  wenzeslaus   |      Owner:  grass-dev@…
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  Website
 Component:  Website      |    Version:  unspecified
Resolution:               |   Keywords:  php
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-------------------------

Comment (by wenzeslaus):

 Well, the code has a few strange places which would use some refactoring,
 but anyway, I think that the change should be applied everywhere:

 {{{
 #!diff
 - while (substr($a[$ra], 0, 27) != "<tr><td valign=top><a href=")
 + while (substr($a[$ra], 0, 29) != "<tr><td valign=\"top\"><a href=")
 }}}

 This will need to be changed next time the HTML file will be changed, e.g.
 replacing attributes by styles or change in formatting. Besides possible
 refactoring of this PHP, the complete solution I have in mind for some
 time already is to have XML, CSV, JSON and plain text files generated
 automatically and available online. These files could be used by tools
 like this one (or some interactive manual pages) for searching and showing
 info about modules without parsing of HTML which can change anytime.

 For the "random" part this should be changed too (just optimization and
 avoiding a warning):

 {{{
 #!diff
 - $ra = rand(0, 1000);
 + $ra = rand(0, count($a));
 }}}

 I'm not sure how the "day" part should be changed if at all, but there are
 some magic numbers as well.

 BTW, I saved the file and then executed in command line using `php
 grass_moday.php`. I had to add `<?php` at the beginning and `?>` at the
 end. I also downloaded the
 [http://grass.osgeo.org/grass70/manuals/full_index.html full_index.html]
 file (`wget http://grass.osgeo.org/grass70/manuals/full_index.html`)

 BTW2, these things are not in grass-web repository? Why not? Are they too
 intimate, i.e. too many strange paths etc.? Or too much management
 overhead?

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2593#comment:11>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list