It is a real pleasure to introduce Object Relation Mapping in Cook Self Service.

This 3.1 version is a revolution.
Say goodbye to all your SQL queries, and talk to the model in a human language.

Simply express what you want, and the model will prepare itself just for you.

Crazy feature. You gonna love it.
Have a lot of fun !!!
www.j-cook.pro/index.php/o/orm-system

That seems a great feature, can't wait to try it out!
Functionality which I probably will use a lot in forks (which I heavily use)

Initial thoughts:

Nice feature, however, took longer than I wanted to convert my current component to ORM. More "working" examples may be needed to reduce the conversion time. Also, the com_hellomyworld component should be updated to help bridge the gaps.

Overall, Super job

Hello Admin

Based on a chat I recently had, I believe that J-Cook should consider making the "hellomyworld" component available under each profile such that it is sandbox-ready. This would facilitate quick and easy evaluation of Cook by prospective clients without requiring them to have a personal Joomla environment. They could install and run the component and see the power of Cook without dragging a single db field. Then they could download the same and see the code structure with zero effort.

It should also help to keep the component up to date with the latest Cook framework and provide working examples of what is possible on the platform.

I guess you would need to ensure that only this component is available for download for non-paying accounts. But with Admin, all things are possible, right?

For your consideration.

Warm regards
vlemos

You are absolutely right !

It is already my idea to furnish some public project for cloning.
The thing with the demo, is the presentation of the forks. So both are interresting.

I will upgrade the demo soon

Not sure I understand, in the sandbox the forks must be in the "fork" folder and not "_fork" and this is the way it is currently. Since it is not a custom component, the same is true for the downloaded version.

The only challenge I see is how to maintain a single instance and still make it available across all accounts. Maybe the clone feature is the answer; the user is allowed to import it to their account via cloning and major changes to it defeats the download function for nonpaying users.

Just a thought
v

Final thoughts:

Cook-ORM is a very nice feature with great potential. However, the cook framework is already fairly complex and the jdom layer must be taken into account when looking at extension performance. Without doing the maths, my guess is that a cook component is a bit slower than some of the other builds but better structured and easier to maintain.

Our end-users and clients are most interested in functionality, esthetics and speed; technologies are more a design consideration. The introduction of ORM will add to the overall weight of components. This may be insignificant in most cases; however, some developers may be building for a low-end server or some other strange spec which may make static SQL preferable.

Personally, I love flexibility; therefore, would like to see ORM as an option in the cook config panel and not baked directly into the core going forward. This would allow users the ability to choose at design time based on how they see this layer enhancing their final product. Failing this, forced adoption of ORM would be the only way to benefit from other features on the road map.

I leave these thoughts for your consideration.

Wanta say all the best for 2017 to all in the j-cook forum

Warm regards
vlemos

This markup looks amazing, and I can already see the potential. However it only took one build at 3.1 to see that there was a LOT of work on my part to make this work.

All MODEL forks I have exploded spectacularly and will need rewriting so it would be NICE (though I know it would be too much work to consider) to have ORM as an optional for 3.1, or allow old Joomla calls as part of the 'enable legacy'

My concern is that as you fix more bugs going forwards I am going to be stuck at 3.0.10 for some of my major projects and miss out on the good stuff.

However stunning work, and I will enjoy using this going forwards with new projects

@vlemos

For sure, the most evolved is the framework, the slower will be the application.
But don't worry, php is fast enough and the ORM feature is not heavy at all.
If you compare Joomla and Wordpress, you might have the same comparison approach.
We could say the same for FOF.

For JDom, I agree, and I will deprecate it bit by bit. But for ORM, did you noticed latencies ?
Only one ORM request is done by page. (sometimes more in case of N:m, but so few).
So I don't think is is relevant. It is really different than JDom.

@MorganL, normally if you forked the whole prepareQuery(), there is no problem at all for your projects.
Did you tried your forks on the latest 3.1 ? Where was the problem ?

I have a 3.0.x build, with prepare query fully forked.

I built 3.1 and installed over the top, every query that was FORKED gave 'Invalid query 0'. If i removed my fork, the query worked fine

I build 3.0.10.0 (latest before 3.1) and installed over the top, my forks worked fine

Sp not pinned it down, the only thing I can think of is I create my own custom case ' ' statements in that are not diretly tied to 'views' but rather called when I need them

I will put on option for the use of ORM in prepareQuery()
ORM will always be available since 3.1 and further, but the option will let the user choose the way of coding prepareQuey() with ORM or NOT

Please don't think I am not excited for this new system (I can already see some great advantages), but as you know I have a couple of rather large projects that I would need to do a lot of testing and possible recoding on before moving to ORM

All new stuff will use it immediately which will allow me to get used to it and then eventually embrace it completely

I know...
The option will not remove ORM, it is just such as the 'exploded forms' option.
It will permit to the user to generate the models in legacy way.

But this is kind of tricky because ORM is used for accesses, publish, pivot filters,...
So I cannot generate without it. Even in legacy way, you will find some calls to ORM, but exploded

And for your forks, please check the context names.

I did changed the names BY PURPOSE for beeing able to keep the previous forks.
Legacy contexts : "[view].[layout]"
New contexts : "layout.[layout]"