Hi Admin,
After writing up how to split projects
www.j-cook.pro/index.php/forum/design-yo...ect-management#10871
I thought of something that will allow connection to alternate data tables
What I propose is to allow users to configure the data source such as #__anytable or #__myproject_sometable (infact #__what_ever_they_like)
In the builder we can specify the table title, item title and associated aliases but what if we could specify the data table?
So how would you implement this you may ask?
if the user has defined an alternate data table
- everywhere that #__myproject_table is called is replaced with #__myalternate_table
- do not generate the create table statement for myalternate_table in the MySQL install file
- do not generate the drop table statement for myalternate_table in the MySQL uninstall file
if the user has not defined an alternate data table
- generate the default Cook Code to call #__myproject_table
- generate the default Cook Create table statement to create #__myproject_table
- generate the default Cook Drop table statement to drop #__myproject_table
So how does this effect the project?
- Effectively my split project routine is a work around to simply change the data source
- The original cook generated table title, item title and associated aliases remain unchanged
- This leaves everything in the downloaded project working exactly as generated
- The only thing that has changed is the data source
What are the benefits?
- Cook Project Downloads effectively are "linked" together without modification
- The downloaded component now connects to any table that is specified in the current database without modification by the user
- Existing Joomla Extensions could be extended by Cook Builders with ease
- access just one field in another component... how many times did you need just one field from another table in another component to further extend its capabilities?
For split projects
- the administrator menu items are no longer Retailer Warehouse, Retailer Head Office they can simply be Warehouse and Head Office
- The component name can now be com_warehouse rather than com_retailer_warehouse
- aliases are shorter
What are the pit falls?
The developer must ensure that all security and states are implemented in each project accessing the table
- published state, checked out, access permissions , core permissions... just to name a few
- some tables have relationships to other core tables, security, functionality that must be understood and probably should not be easily accessible
- lots more pitfalls I am sure
Anyhow just a suggestion