-
Notifications
You must be signed in to change notification settings - Fork 373
Paul's ideas
This wiki entry is a brain-dump area for Paul to provide suggestions to Rob / Hugh for Fabrik 4.0 design.
Create an object / methods model using a modelling tool like Modelio.
Write an architecture guide which explains at a high level how Fabrik works i.e. object relationships, the event model etc.
Write a developers guide which explains coding standards and how-tos on extending Fabrik. Provide code comments to explain what each block of code does.
Try to create and hold onto Architectural integrity i.e. be clear about objects, their relationships, their hierarchy and inheritance of methods etc. and be ruthless in keeping code clean.
There should be a clear definition of how admin and run-time transactions flow.
There should be a clear separation between admin and run-time code, so that packager can package a run-time environment without any admin functionality.
All common functionality should be handled by parent objects and / or helper objects. Ideally it should not be possible to find the same code in two places.
Lists are currently a combination of table definitions and a tabular display of data. I believe that these should be separated into separate objects. All SQL interaction with the DB should be through the Table objects. Lists should be like Forms i.e. have a combination of Groups.
Each table can have 1 or more Groups.
Each group can have 0 or more Elements.
Each Form / List can display 1 or more Groups.
Two tables can be joined.
Joins can be tight or loose (tight refers to repeat group type joins - loose to databasejoin type joins).
Note: databasejoin link tables for many-to-many databasejoins are tight on one side and loose on the other.
Note: This supports nested repeating groups and other complex table relationships.
Table object handles interface with database.
Table object ensures referential integrity.
Table object marshalls SQL statements into atomic transactions and executes them in a single continuous sequence once Fabrik signals transaction ended (minimise locked records).
Group and Element objects indicate to Table which elements they need. Table object works out the SQL needed to get the data and if needed to update it.
Record locking should be implemented using locked-by and locked-deadline fields in each main table - with locked-record timeout time decided by the user i.e. if a record is locked because e.g user starts to edit a record and then closes their browser, the same user can always edit the record again, or another user can edit it if the timeout / deadline has passed (in which case they lock the record and if the other user tries to save, they get an error message because their userid doesn't match the locked-by field any more.
Ideally we should be able to avoid sessions (though I am not sure what sessions are currently used for and so not sure if they can be avoided).
First phase of every admin / run-time transaction is to marshall all needed objects. (At present all routines go get stuff multiple times. The interfaces between objects should be clean - so that one object does not need to go inside a different object.
All user-named things should be kept separate from Fabrik internals so that user can use any name for a table, list, placeholder etc. without risk of clashes with Fabrik internals.
Internal code should not need to worry about whether a setting is held as a database field or a Joomla registry/JSON parameter string. All settings should be exposed as variables - the table object should take care of how to store the data (which means that we can easily move settings from parameters to fields or back again without recoding elsewhere).
Existing F3.x lists would need to be split during upgrade.
Otherwise every current user defined setting should carry across.
Maybe we should have a central flow-control object to clearly define what controls things happening. This could be parameterised using xml-based files to decide which events to process in which order using which methods (makes it easy to add new processing events).
Perhaps data for a transaction should be stored in a single data object in order to make it easy to get hold of it. If the structure of this is cleanly defined it would make it much easier to debug and extend the functionality.
Events should flow cleanly up and down the hierarchy. Events needed by e.g. only databasejoin element are defined in the element master object as an empty method and called for every element, but only databasejoin element would override the empty method which does something useful.
Placeholder would cleanly support repeat groups and even nested repeat groups.
Every element would be able to get a form index which would indicate its position in a repeating group i.e. [] in the master record, [1], [2] etc. in the first-level sub-record, [1,1],[1,2],[2,1] in the second level sub-record.
Reference to a placeholder in the current record or a parent would return a singleton value - reference to a placeholder in a sub-record would return an array of values as now.
Clean and consistent use of ids and classes - all fb ids and classes should have a consistent naming convention i.e. fb_xxxx_name where xxxxx indicates what type of class or id it is, name indicates group or element no or name (TBD) in a way which makes it unique. Repeat group whatevers will have identical classes, but indexed ids.
I haven't spent any time working with existing JS, so not sure how cleanly architected it is. Only experience is that JS stuff seems a little unreliable - repeat groups +/- don't work on multi-page - not sure why multi-page would affect that. But same approach to architectural purity should apply to JS. Provide lots of helper functions and APIs so that code is never duplicated. Provide clean hierarchies. If we can use the plugin concept in JS that would be good too.
In addition to actual Joomla access levels, access levels should be defined as Inherited - so ability to do x can be explicitly set for each element or inherited from the group or inherited from the form. This should avoid a lot of defining of access levels during development and should also provide better functionality.