Hello,
I would like to link a component created in cook with another cook-created component.
I have a "machines" component that i want to be used by other components in the way that when i want to select a machine, it gives me the whole cascading ajax thing related to the machine field in the machines component.
So :
machines component, 4 tables : company, building, group, machine, with cascading combo boxes to get to the machine.
shop component, where i have to use the machine field, with the combo boxes attached to it, from the machines component IN the shop component.
If you see what i mean, i'd like some insight on how to do this. I already forked the model and the tables, but i get nothing.
Any lead greatly appreciated.
Thanks to you all, and cook rules the world (at least joomla's)

Is it possible to get an answer please ? At least to tell me that it is not possible, or that i shoud use the TRIGGER mysql function in some way ?

depends if you want to read or write datas.

If you want to call a controller fro a component to another, just change the 'option' var in the query of the task call
If you want to read/load datas from another component, just look where the models are instancied.
$model = Model::getInstance('component', 'viewModel');

In the default views, when the page calls automaticallly with $this->getModel(), then it loads the context model, but nothing is forbidden, you can replace by any model you wants using the previous example.

For the moment Cook do not connects thrid tables automatically between projects.
Only users and viewslevels tables have their respectives models in you component in order to read those tables.

Can you describe precisely the challenge you need to accomplish ?

VeCrea wrote: VeCrea, Admin and others Miss me?

Its been nearly 18 months since i did as you are looking to do...
but give me a day or so and i will check out the current component build and post reply

I used to create the same table fields in each component
prefix the common table name
build component
then do a full folder text search and replace using something like notepad++
, removed the sql install / uninstall lines for common tables as needed
rezip and install component

i did write something up a long time ago... cant remember but i think i narrowed it down to a few search and replace sequences

@VeCrea,
Found this one that i wrote up think it was in the early days of Joomla 2.5 component builds not sure how relevant to 3.0 and 3.2+ builds...
if it does not point you in the right direction or you need more help let me know.
www.j-cook.pro/index.php/forum/design-yo...ect-management#10871

alternatively you could flick me a basic table structure and FK relationships, grouping i perhaps could help... (dont need all the fields just the table names, FK relationships and filter groupings)

Hi BTB, nice to hear from you.

Always excellent help. Yes for sure we miss you here.

Thanks, will look into this. Found another find/replace pattern, but will test yours too.
Thanks anyway

Over the past few days I have been testing some connections with various other components and have found a few work arounds that i needed to make with out of the box component builds I have documented some of these for Admin and in the next few days I will pass some details on to Admin to consider for the road map of future capabilities of Cook.

However i feel that it is worth noting for those that wish to play with search and replace routines that allow Cook components to interact with the core and other third party extensions there is at least one extremely important consideration that you MUST be aware of
- make absolutely certain that you check the sql uninstall file and comment out or delete the drop table lines of tables you do not want to delete when you uninstall your component

- we always hear it but many of us do not do it often enough - Make sure you have a Backup! of both your site AND your data before installing your component

for example lets look at the core users table recreated as #__mycomponentname_users in your fresh component build...
seems simple enough to search for #__mycomponentname_users and replace it with #__users
but in the uninstall file located at admin/sql/uninstall.mysql.utf8.sql we now have a issue
DROP TABLE IF EXISTS #__users
if we uninstall the modified component without modifying the uninstall file we will also uninstall Joomlas user table!!!

There are many issues that one must consider and these have been discussed here previously about user access permissions, published state...

Although i can see many of the suggestions that I will send to Admin would make out of the box Cook components even more powerful when it comes to integration with other components and extensions such power could be dangerous... But rather than mess around with search and replace i guess if you really want to integrate with other components use the power of the fork file!

Excellent post.
You are absolutly right about the search/replace way, we must be very carefull and replace carefully knowing what we are doing.

The main problem for me about these interractions is at the sandbox level. How to test such features when the related component is a third part such as another extension from JED ?

Many questions remains still unanswered for me, and until I have the solution, I cannot propose anything.
The only possible thing is to propose interractions between user projects (when they are splitted), and to interract more with native Joomla components only.

It should also use triggers at the application level. In this way connections between components could be interresting.
Yes, please send me your proposals because it is a good momment for that. I have almost finished a rewrite of the interface, so I can include that in this rewrite. Accessing to others tables in the same user workspace.

admin wrote:
sent!!
-some of your unanswered questions could be within

admin wrote: I personally would not worry about testing third party extensions from the JED in the sandbox, far to many of them , far to many user specific configurations... even down to how they save a date, or file location would need to be considered, how would one tell Cook in the sand box that it must save a unique ID in a specific format?

But as long as we can get to the data tables we need you can at least download Cook component install on our own test server and then continue more specific development

As long as the table uses standard field names for publish, access, order... ... you can at least create a record save it, change its published state, order, delete and a few more standard actions and your changes are replicated in the original component. the only thing we need to do is make sure our user access levels are the same as the main component...

if the changes that i proposed were made you could say that Cook integrates "standard" joomla functions in the sandbox and downloaded component for external data source tables that you create

Whats great about Cook is that you can take a third party extension form that you do not like recreate its tables / fields and create your own custom layouts with the added benefit of making that form into a form wizzard

too easy (what more could one want)

I agree with BTB300. To a certain level, i don't even use the Sandbox so i wouldn' bother.
And i already told you, those kind of really advanced stuff could make it to another category of users, with other aspirations than the basic quick and easy component.

Thank you soo much BTB300,

Your mail was consistant. I am looking forward into it. Some improvements are easy to do some others more complex.
I agree for the sandboxes, the simpliest will be to put a limit of this feature, so it will not be testable there. And so I will concentrate more on what really desserves the users.

I think I will do it in successive steps. First only for reading other components tables from your builder workspace. So the only thing, will be to recreate the structure of the third component because cook will not provide the fields maps of others component.

In this case a SQL import feature would be a must for automatically build the structure. I searched a little bit into that, but not enough. If somebody can help for decomposing a SQL query into object structure it would be easily integrable afterwards.

Writing in third component tables, is called a "database hack" and I think it can only be done with locals models. The generated components are actually already providing an example with 'thirdusers' and 'thirduserlevels'. Those models are the ones to use for managing datas wich are not coming from Cook component. The example you wrote in the email is correct, but not necessary for 'users' and 'viewlevels' because they are created anyways. Better to use them.
In case of cook third component it would not be necessary. This is the all point. I do not want to recreate local models for each table.
It depends of the context. sometimes simple SQL join (from regular generated model) is enough and nothing else is required.

For the moment I try to finish the current work, and I will do that as soon as I can.

Thanks Admin,
you know i have never looked in the third users folder thanks for the advice
user tables were included in my example email more because they a different structure to that of the standard build, #user_usergroup_map has no primary key...let me do some homework on this I cant promise anything at the moment but
- I have seen some sites that allow table structure import for sql testing
- and may be able to dig through my old code snippets from years ago that may help

admin wrote:
Agreed 100% that is all we need - the ability to read the data from the third tables "out of the box"
this also gives us the table structure and the Cook Developer can then choose to implement write to third party tables if needed

as for writing to third tables = database hacking - agreed as well...
- some components are well written and have developer API's making integration relatively simple
- but others not so great and database hacking is needed
- should we write to / database hack a third party component?... A debate that would never end... a decision that needs to be made and implemented by the Cook Developer on the local level
- the need to write to a third party table is job specific and usually requires much more than simply writing to their data table

Sometimes the end user just wants a simple way to update multiple components that deal with the same "content" or add some additional functionality that does not exist within the existing components, they do not want to go into three components in order to manage their site and that's where Cook Self service comes in Cook allows us to create a solution for the end user that allows them to manage their web site data how they want to

Take for example a site that has an events listing component, they also duplicate the same event details in a Joomla content article, and they also use a shop component to manage various rates such as early bird specials, group discount rates... in this case write to would be an advantage when creating a custom Cook solution

however something that has not been yet discussed is that the Cook developer could implement such specific write to functionality to third party tables by using the power of classes by extending the model classes

Agreed in some cases it would be "nice" if we could write to third party tables out of the box (long term) but not essential