Would it be possible to automatically add a css class to the <div> tags that are generated from the bricks.

For instance, each <div> around a toolbar should get class="brick-toolbar". Each form class="brick-form", "brick-fly" and so-forth.

Edit: I have set the css class for the bricks, and it is not generated in my component. I filed a bug report about this previously, and it had been reported fixed.

www.j-cook.pro/index.php/forum/closed-ti...plied-to-bricks-jdom

I realize I can add this to each individual brick in the builder, but I have many, many layouts and bricks. If this just worked out of the box, styling a component would by much easier. It seams like it should be relatively simple change on your end that would have save an exponential amount of time for your users.

There was a fair amount of interest for this feature months ago in this thread:

www.j-cook.pro/index.php/forum/templatin...ick-divs-for-styling

Thank you.

Actually, the views and templates are gonna be rewrited soon.

Cook is gonna use JLayout to render the bricks. XML files will be used to configure views (form, filters, grids, flys)
So all the template file will diseapear and leave this job for FoF.

Then if you want to custom a view, you will gonna say it to Cook wich will write for you the code that you will be able to customize.
This is already in the works but it is really huge. The release time is not known yet.

It means that 'with or without code', it must render the same.
So I will rewrite the template DOM to fit perfectly with what FoF does invisibily for you.

Basicly you will even get tons of features more using FoF.
Be patient, there are amazing changes coming.

This sounds amazing, but I would imagine that this change is so vast that it will render most forks that involve views useless?

I am a little concerned as I am about to pickup on one my my largest projects and most of the work will revolve around the views. I can see myself doing loads of work, then you switch over to a new version, I make a small change and BOOM, the version I download is then totally incompatible with anything I have already done.

EDIT : Suspect I have nothing to worry about as just had a quick scan read about JLayouts, looks like it can handle old views as well (as far back as J2.5) easily as its works on an override type basis. I hope... =)

This sounds great. I also have compatibility concerns that were touched on by morganleecy.

How will compatible will this change be with the current j-cook output? I am currently in the process of re-factoring one of my largest projects, and to be compatible with the current j-cook output. (Which I guess is why I am here again posing the same concern as I am re-encountering it.)

I would be devastated if after completing the refactor I encounter a compatibility issue with a new version of J-Cook..

In future major version releases, would it be for you to leave the old j-cook program builds intact on your server, and then it could be a build option when you download your component.

"Build using J-Cook 1.0"
"Build using J-Cook 2.0"
"Build using J-Cook 3.0"

I'm not sure of the time requirement it would take for you to enable this, maybe more than you have - however it be very helpful. I tend to run into problems with J-Cook when I created a program in the past, with a specific version of j-cook, and when to make changes to it later. 6 months from the original date I created it and made my customizations and j-cook has changed, and the built component isn't compatible out of the box. If I could make a change to component that I created in j--cook last year and use the same build of j-cook, then I would avoid issues with an old component and an evolving j-cook. I look forward to the changes you mentioned and over all love using the builder.

Thanks for the consideration.

The problem with keeping all the old builders and associated projects is the VPS cost would start to skyrocket I am sure.

I felt like I had been kicked in the stomach when the last major new version was released as my old project would not long load or compile and I had to split it.. but after discarding nearly 40% of the project I was so disheartened I stayed away for several months. However as a dev myself I just accepted it for what it was. Now the builder is just so awesome I feel the need to do the project again, but there is a great deal of trepidation when I read posts like this with major changes ensuing. Not being caught out twice!

I'm hoping that when the code generator is changed that we have the option of generating a project using the current version (instead of the new version) so we can maintain/update our current projects where we have done extensive work in the forks. Moving forward, I look forward to the FOF integration for new projects ...

Dave

Excellent question :
Since the begging of the forks, I keep following the compatibility.

So when an upgrade comes, I can tell you what are the changes for the forks (when it is impossible to compatabilize from before)
You can have few changes to do in your forks sometimes when you upgrade, but I do my best to reduce it to the minimum. And as I tell you, this only happens when it is impossible or really to complex to make a legacy.

About views and templates, of course everything is gonna be compatible with legacy Cook version.
This is why I am working on this huge work at the moment. Keeping compatibility since Cook 2.5. (when forks arrived)
And if you do not want this Cook compatibility, then beiing able to set up to reduce and have cleaner code.

Well, this is not the only thing.
In this moment I am reading and studing FoF, so to see the conventions differences vs Cook and vs Joomla.
Example : the files are gonna be stored in 'assets' directory (Cook non-compliance to Joomla standard)...
And the forms XML have different names and structure.

My objective is to furnish you obvioulsy the best compatibility first than having more feature. The speed of growing of Cook is retained by my wish to not have bugs and structurate it well with good conventions. (And this is still not reached to my point of view)