Warning: session_write_close(): write failed: No space left on device (28) in /var/www/joomleague/dokuwiki/doku.php on line 116

Warning: session_write_close(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php5/sessions) in /var/www/joomleague/dokuwiki/doku.php on line 116
dev:backend:jlxmlimport - JoomLeague

Joomleague XML import

This rather large piece of code reads an exported JLG file, and gives the user the opportunity to merge that with with possibly already present information in the Joomleague tables (persons, positions, seasons, leagues, clubs, teams, events, …). The merged results will be added to the database.

Processing Steps

Reading of the Import Data

The JL XML file contains all information of a project and is written with a(n older) version of Joomleague, using the JL XML EXport feature. The name already indicates that all info is available in XML format. It contains records for all objects that are needed by the project, the project itself, its season, league, divisions, clubs, teams, project teams, team players, project positions, et cetera. Foreign keys are used in the database to refer to objects in another table, and these values will also be found in the XML records.

In a first step the user selects a file to be imported. The file will be read and parsed into a complex data structure, where every database entry and the results will be shown in a second window where the user can manipulate it.

Manupulating the Data

The objects that are read in can be used as new data and imported as such, but they can also be linked to already present objects in the database. In former case all objects are newly created, in the latter case existing database objects are used.

User scenarios for coupling of imported data to the database (current situation)

The import module allows the user to coupled imported teams/clubs to the same existing team/club, to another team/club in the database, or to a newly created team/club in the database (FIXME see picture club_and_team_assignment1.png).

The following scenarios for coupling a team/club to the database - with described behavior - are supported:

  1. the imported team/club is matched against the database. If found, then the top checkboxes will be selected and the right texts are put in the accompanying text boxes. The other checkboxes are unchecked. Also the disabled team textboxes for name, info, short name and middle name will be filled with the right text. Same for club text box and selector for name and country.
  2. the user can decide to connect the imported team to another team in the database. The selector will show all teams in the database, and once a team is selected the popup closes and the team information is updated by checking the middle checkbox, unchecking the other checkboxes and fill the team name, short name, info and middle name with the proper text while disabling these text boxes. Also the club information is updated by checking the top checkbox and putting the right club name in the disabled textbox; the other checkboxes for club are unchecked. The disabled textbox and selector for clubname and country are also set correctly.
  3. the user can decide to connect the imported club to another club in the database. That automatically means that a new team must be coupled to the imported team. If the user wants to select both club and team, then he should use the method described in 2). By selecting another club from the database, the top and bottom checkboxes are unchecked, the middle one is checked, the top disabled textbox is set to the selected club name, the disabled bottom textbox and selector for the club are also set correctly. The 2 topmost team checkboxes are unchecked, the lower one is checked, and the now enabled textboxes are filled with …
  4. the user can decide to create a new team in the database for the imported team. Then the 2 topmost checkboxes are unchecked, the lower one is checked, and the now enabled textboxes for team name, info, short name and middle name are filled with … The club part is left unchanged.
  5. the user can decide to create a new club in the database for the imported team of a club. Then the 2 topmost checkboxes for the club are unchecked and the lower one is checked. The now enabled textbox and selector for club name and country are filled with … When a new club is created in the database, that automatically means that a new team also needs to be created. Therefore the 2 topmost checkboxes for team are unchecked and the lower one is checked, the now enabled textboxes for team information at the bottom are filled with …

FIXME The … parts need some discussion.

User scenarios for coupling of imported data to the database (proposed situation)

Next picture (club_and_team_assignment2.png) shows how the UI can be made more easy to understand for the user.

It basically boils down to 3 possible choices per project team for the user:

  1. use existing club and team from the database
  2. use existing club from the database but a create a new team in the database
  3. create a new club and team in the database

It is then also much easier/more logical how the controls behave (get enabled, disabled, which contents it contains) from a programming perspective.

The club/team to be imported is matched against clubs and teams that are present in the database. In case both match, then the upper radio button is automatically selected and the textboxes at the right are disabled and show the contents of the database. In case only the club matches, then automatically the middle radio button is selected, and only the team text boxes are enabled, so that the user can enter the desired information. If both club and team do not match, then the lower radio button is automatically selected, and both club and team text boxes are enabled for editing.

The user can of course overrule the selection by choosing another radio button than was determined automatically. Clicking on the radio button will open a popup where the team or club can be selected from the available values in the database (similar to what happens now when clicking a checkbox). We could even differentiate between radio button clicks:

  • When the top radio button is selected a popup is shown with a selector that is populated with all teams available in the database. The text for each line in the selector consists of “club - team”.
  • When the middle radio button is clicked a popup is shown with a selector that is populated with all clubs available in the database. The text for each line in the selector consists of “club”. The team that will be created will use the information from the import file.
  • When the bottom radio button is clicked no popup is shown. The club and team that will be created will contain the information from the import file.

Remark: “text boxes” should not be read too literally; also selectors (e.g. for country selection) are meant here.

Merging and Storing of the Project

The database from which the export was done had certain values for the foreign keys in the different objects. It is most likely that the foreign keys are different in the database into which we want to import the project. Therefore all keys need to be updated before writing the objects to the database.

The Code

Involved code files are the jlxmlimports controller, model and view (different layouts).

When selecting the XML Import menu entry in the Administration menu at the left, the default layout view is activated, allowing the user to select a file to be imported, and to upload the file.

Reading of the Import Data

Clicking on Upload file will result in save() being called on the controller. The selected input file is then copied to a temporary folder. In case of a zip-file the contained files are extracted to the temporary folder.

Manupulating the Data

The user will be led to a next screen in the import process. The controller will enable the form layout view, which in turn loads the data by calling getData() on the model. The data will be bound to member variable xml of the view. The form view will create a form with the primary data (league, season, club, team, person, event, statistic) and let the user decide to create new entries for them in the database, or to bind them to already existing entries in the database.

FIXME Describe what the user can set/change and how that influences the import. Also explain how that works in the code (javascript stuff)…

When the user clicks Start import the selected/filled in values are validated using chkFormular(). There is one peculiar thing: the function directly returns true while there is a lot of 'checking code' (that is bypassed this way). FIXME check if this return true should be removed.

Merging and Storing of the Project

In member function importData($post) of the model all records will be obtained from the $post variable and stored in fields like _newclubs. Then the import-work really starts by calling member functions like _importClubs(), which copy the data from the import structure (via $this→_getDataFromObject($import_club,'id') and the like) to a database table object (via $p_club =& $this→getTable('club')), and determine the translation table from old foreign key values to the new (via _convertClubID). This database object is then stored in the database (via $p_club→store()).

First all highest level objects (with no dependencies on others) are processed, and then the ones that have dependencies are processed, using the foreign key translation member variables.

The controller will execute insert(), which activates the info layout view. It shows the results of the import.


In Other Languages
Translations of this page:
QR Code
QR Code dev:backend:jlxmlimport (generated for current page)