MasinoFixedWidthSite, Extension for Almost All Customization in Websites that Generated by PHPMaker 9.2.0

Comments

1. keithh0427 says

   July 29, 2013 at 9:30 am

   Masino,

   the function, getCurrentPageTitle($pt), in userfn.php assumes that breadcrumbs are used.

   when they are not used,

   $recCount = $rs->RecordCount()

   will cause an invalid object error since the SQL statement is invalid.

   • keithh0427 says

     July 29, 2013 at 9:38 am

     I used the following code to correct it.

        if ($rs = $conn->Execute($sSql)) {
           $recCount = $rs->RecordCount();
        } else {
           $recCount = 0;
        }
     

     • Masino Sinaga says

       July 29, 2013 at 9:42 am

       Thanks for the improvement, Keith.

2. Adam Burgoyne says

   August 20, 2013 at 11:43 pm

   It seems that your Page Title Style modification is pulling some language constants into userpriv.php which should really be in the language files… without that change, userpriv.php needs to be manually edited all the time:

   if ($gsLanguage == "id") { // Indonesian language
     $Language->setPhrase("PermissionPrinterFriendly", "Ramah Cetakan");
     $Language->setPhrase("PermissionExportToHTML", "Ekspor ke HTML");
     $Language->setPhrase("PermissionExportToExcel", "Ekspor ke Excel");
     $Language->setPhrase("PermissionExportToWord", "Ekspor ke Word");
     $Language->setPhrase("PermissionExportToPDF", "Ekspor ke PDF");
     $Language->setPhrase("PermissionExportToXML", "Ekspor ke XML");
     $Language->setPhrase("PermissionExportToCSV", "Ekspor ke CSV");
     $Language->setPhrase("PermissionExportToEmail", "Ekspor ke Email");
     $Language->setPhrase("DetailUserLevelPermissions", "Detail Hak Akses Level Pengguna");
   } else { // default English
     $Language->setPhrase("PermissionPrinterFriendly", "Printer Friendly");
     $Language->setPhrase("PermissionExportToHTML", "Export to HTML");
     $Language->setPhrase("PermissionExportToExcel", "Export to Excel");
     $Language->setPhrase("PermissionExportToWord", "Export to Word");
     $Language->setPhrase("PermissionExportToPDF", "Export to PDF");
     $Language->setPhrase("PermissionExportToXML", "Export to XML");
     $Language->setPhrase("PermissionExportToCSV", "Export to CSV");
     $Language->setPhrase("PermissionExportToEmail", "Export to Email");
     $Language->setPhrase("DetailUserLevelPermissions", "User Level Permissions");
   }
   ?>
   

3. Adam Burgoyne says

   August 21, 2013 at 12:07 am

   Actually… what would be awesome is a mod that moved all the phrases (well, as many as is practical/possible) into a table – it would REALLY simplify the multi-language aspect of PHPM.

   Right now, I’m working on a project that needs to support at least 4 languages that I don’t speak… and more to come!

   Of course, I can send native speakers a copy of the ‘english.xml’ file from the PHPmaker language folder, but that doesn’t help with all the other translations that currently need to be done via PHPM.

   I really don’t want to give others access to my system and/or PHPM itself, so the only alternative is to send out the generated ‘english.xml’ file and then manually find all the relevant places in PHPM and copy/paste their translations that way. Unfortunately, the project is quite extensive so there will be several hundred words/phrases to copy/paste per language 🙁

   If there was some way to take the generated ‘english.xml’ file and process that to create a ‘master table’ of phrases, then each additional language could be translated quickly and easily via the web by adding / editing detail records.

   All it would need is a joined inline edit page and the translators could just go to work… then, either export the translations as xml files or, even better, include a little global code in each page that loaded all the required phrases directly from the database via $Language->setPhrase() calls.

   I think this kind of mod would put 9.20 way ahead of 10.0.1 🙂

   • Masino Sinaga says

     August 21, 2013 at 4:53 pm

     Thanks for the feedback, Adam.

     The main reason why I wrote the phrases in the extension side instead of in the .xml language files is that since I don’t want to touch the original nor the generated .xml language file that came from PHPMaker. I just want to make the extension will work as it is: enable it, and it will work for generating the script files. No need to customize the other files outside the extensions.

     So, I think the best approach regarding the custom language phrases is just like discussed in this topic/post. There are some advantages if we can handle the custom language phrases from the PHPMaker side. First, each project usually uses the different custom language phrases. That’s why we should handle them on projectly basis from PHPMaker side. Secondly, it will impact directly to the generated .xml language files if we handle from the Language editor in PHPMaker. In other words, we will not touch the original nor the generated .xml language files.

     In the meantime, I will keep the phrases directly in the extension side. However, you can actually customize the extension by moving out all the phrases into the .xml language files. Yeah, this will make the extension will depend on the other files outside the extensions.

     If you want to handle them by using master language table, then please consider the following: Will it cause the higher resource/traffic to your database afterwards? Honestly, I always try to avoid using database for storing and receiving the language phrases for that reason. If you want to make your web app support for many languages, then I suggest you to provide the special UI so that your web app users are able to entry the phrases, afterwards, you (as a web developer) can convert them back to the .xml language files or via PHPMaker language editor (if the PHPMaker has provided the editor code for managing the custom language phrases).

4. Adam Burgoyne says

   August 25, 2013 at 5:10 pm

   “No need to customize the other files outside the extensions.”

   That comment isn’t strictly true because the extensions are “hard coded” for English and Indonesian. What happens if someone from France, Germany, Russia, etc. wants to use the extensions?… well, right now, they have to go and identify the all files within your extensions (34 of them I believe!) that have the hard-coded messages and manually edit them for their chosen language… not fun and not practical as these need to be re-edited each time you update an extension.

   No only that, your breadcrumbs feature *requires* the original and/or generated .xml language files to be edited before breadcrumbs will display.

   So… what I’ve done today (without using a database!) is created a simple system that will allow your extensions to support any required languages, and to do so exactly as you wanted… no need to touch the original or generated .xml language files.

   It will even support your breadcrumb links so the .xml files no longer need editing at all (except to correct the awful English in many of the phrases) 🙂

   I’ll email you the files and, hopefully, you decide to implement it in your extensions.

   • Masino Sinaga says

     August 28, 2013 at 3:28 pm

     Well, it seems that we have to move all of those phrases out now into the .xml language files. For further information, please read this post.