With the new way forms are displayed, it seems impossible to get another layout than a simple list of fields, combos, and so... impossible to get something nicely layed out with divs and so...
Am i wrong ? Because if i'm not, if it is really impossible to do so, it's a HUGE step backwards for me.

Well, JForms.

What you see is the contracted version of your form.
Is enumerating all the fields founds in the XML form file :
In this XML file, you will find all the differents possibles forms for this table. (distinct front/back)
So, you can freely add / remove some fields here.



In the template now :

You can also replace your layout page with JDom calls, as before.
The only thing changed is you must specify the field group : jform (always, for the moment)

You can adopt another way to display the fields, something else than only a ul list.

So, a possibility is to can call each individual field, in order to display them how you want. You'll find good tutorials.
I may explain it later, but not the courage now.


Just to explain you something important.
JForms is not here to help you rendering the HTML. It is not really the goal.

Using JForms means that you have a better coherence for PHP validation rules, you can group the fields, etc...
But regarding the HTML rendering, it is really poor. It still implements JHTML inside
There are a lot to do to handle well the unique statements
No JS client side validator... (strange because thi idea behind JForms can be to unifiate the JS and PHP validations)
Files are not handled.
ACL views are not handled....

So to my opinion, in J!2.5, JForms still lacks and I had to create a layer common class, and to override every single field type.

JDom is kept and called in JForms. It can looks heavy, but it is not. Every class does its different job and in term of structure, it is good.

By the way, let comment and give me you opinions about JDom. Do you find it usefull ? Do you think it is heavy ?
What about proposing it for the core ?

As I often said, I believe Jdom is wonderful once you understand how it works and what it does. Definitely something to promote into core of joomla. But is joomla 3.0 not changing everything ? How will Jdom evolve with the coming of joomla 3.0?

Yes you are right, in the VIEW there is the loop with all the fields previosuly retrieved from the xml.
this is the joomla standard and nobody is saying you wrote it wrong.

I just think that coding/modifying the form for my needs would lose all the time saved in the generation of the component using j-cook.
The main reason because I'm using j-cook is because I wanna save time in the repetitive coding so I can focus on the custom coding and logic of my component.
IN MY CASE, If I have to write most of the view layouts on each component release, I think that is enough to do not justify the use of the j-cook.

Jdom is a very good tool, but I would use it ONLY for custom coding, and not for regular task.
I would use it to easily create my custom objects to call when needed , and then use it on all my projects just adding the objects reference files in the jdom folder and making a call (like it is now).
I would not use it to ECHO a simple string, that's just wasting of code and time.

As I said in another post, I will propose you 3 ways of coding for the forms :

- Condensed (JForms)
- Exploded (JForms)
- Legacy (JDom)

(I developped only one option, in order to propose you V2.0 earlier)

JDom will still remain, no choice it is so handly.

In case of a form structure modification :
If you use the exploded use of JForms, you will may have to write in 2 files (template, and XML)
If you use JDom legacy structure, it is more easy, but you still have a repetition of source code (no choice when you template the positions of each field)
If you use the condensed way, it is limited, but good for administration.

The future JSON formated objects in 'attribs', will also use the foreach condensed logic.