Data and code achitecture for Joomfish 3.0

GeraintEdwards edited this page Nov 25, 2011 · 2 revisions
Clone this wiki locally

Architecture is a rather grand word - it more of a quick brain dump of the thinking behind Joomfish for Joomla 1.7.

Requirements

  • Only mysqli driver is supported
  • PHP 5.2 and ideally 5.3

Data Structure

Joomfish 2.x Approach

  • Data is stored in #__jf_content table - a separate row for each translated field
  • JFDatabase acts AFTER joomla has fetched its data and then replaces field values with the translated ones where available
  • Fields to be translated are configured using 'content element files' - XML files that include information about fields, pre/post translation handlers, reference tables etc.

Joomfish 3.0 Approach

2 Different systems available selected on a table by table basis by the content element file:

Joomla Native

  • Data is stored in the core tables using the new language flag
  • Use a mapping table to associate original and translation
  • Translation can be made in the core component page e.g. administrator/com_content or in Joomfish
  • JFDatabase acts in a similar way to Joomfish 2.x replacing values with translations AFTER joomla gets the data. N.B. I did experiment with modifying the queries but handling joins and subqueries makes this very difficult. The best way to handle this is within the core CMS code - something for Joomla 3.0?
  • Note that the tables supporting this new system are currently menu, content, categories and modules. Some of the features have this hard coded at present (I'm working on this !!)

Joomfish 2.x

  • Same system as Joomfish 2.x BUT with slightly different way of processing the rows of data to be translated which is faster and simpler than Joomfish 2.1/2.2

A note on JForm

  • Handling JForm has been very difficult - I have addressed menu and module parameters and content attributes.
  • It only supports changing the value of the translation - i.e. you can't compare the original. We would need to use an iFrame to allow us to do this since the JForm code will not behave well with 2 instances on the same HTML because of clashes with form element names and ids.
  • This has been done using TranslateParams.php in the backend models folder (I know its in the wrong folder!).
  • This file should be split up into separate files - I'm thinking that a plugin architecture would be good. This is because JFDatabase also has some code relating to saving jform output too.