Hi Admin,
The "Object (JSON)", is a great field, very useful if you wanna add many options that don't require a single field in the DB.

Now my point is, why couldn't it be a "wizard" element in the jcook-builder?

I think it would have much more sense in this way, so I can add unlimited other regular "data types" elements inside the "Object (JSON)" and magically the xml form and the script for the json encoded / json decoded are added automatically in the jcook-generated component.

This feature is not finished.

Because I have to rewrite the JS Builder to add new droppables areas for this. Long job.
This is planned fo future. Not as a wizard, but as a sublist inside the table fields (probably togglable to open the JSON field and add data types inside)

For the moment, write in your XML form file, at the end of the file, inside the <fields> tag.
Find your JSON field and add fields inside.

I created in db Object (JSON) within Cook. Then I put JSON object in layout item.
In xml form of the model I found this:

So my problem is I need to save some calculations in JSON object mentioned above.

Here is an example what I need to save:

I am expecting after encoding and saving that I will find in one cell of db somethig like this:

The question is if there is prepared logic for this operation in cook. I found there some logic but not sure if it is enough for my situation.
Please someone can point me?

thanks

Is there a good way to define the fields dynamically? I need to be able to let the user define the fields that are stored so I can't build an XML file ...

Thanks!
Dave

To be honest I have no idea how to add fields dynamically. Maybe someone else

dyoungers wrote: To do this, to my mind the most secure and robust way of doing this would be to create a table that stores field types, then allow administrators of your component to add fields within the confines of the defined field types you give them.

So let's say for example you wanted to give users the option to create their own select list/combo field and a radio field:

1. Create a table 'MyComponentName Custom Fields' and add an enumeration field
2. Add the 'Select' & 'Radio' options to the field
3. Add fields to the table that represent the parameters of the combo field that you want to allow admins to override (such as 'field_id', 'field_label', 'field_class' etc, etc...)
Then, depending on whether it is one or multiple fields you want to allow them to add to the form:

4. Either:
   • (Case Single) - Add an FK field to the table you want to add custom field data to, allowing you to get custom field definitions.
   • (Case Mulitple) - Add another 'join' table that stores the FKs of both the item you wish to add custom fields to + the custom field id FK. Then, naturally, you'll need to get a 'filtered' view of records from the custom fields table where the item id (form you're adding them to) == the FK.
5. Clone & Override the base JDom radio & combo inputs to allow values from your custom fields table to be used as args in your JDom calls

Of course, you'll have to get your hands a bit dirty in the code but, this shouldn't be too difficult.

Following these basic principles, you should be able to render your custom fields.

Further to this, if these custom fields are likely to be used throughout the rest of your component, i.e. not just in one view, you might consider writing an event or helper function (example:onGetMycomponentCustomFields() ) that you can call throughout your component.

Then, you can return custom fields wherever you like.

Hope it helps!

Best of luck,

Gez

ADD
one small thing that I forgot to add is, in your custom fields table, you'll need to add a text field to allow users to specify options and values. So, with that in mind, you will need to decide how you want the admins to delimit their fiel's option values and labels.

For example,
1. You may them to add each option value/text on a new line with value and text delimited by a pipe like:
0|None
1|One
2|Two

OR, maybe using a JSON field type like:
{"0" : "None"}, {"1" : "One"}, {"2" : "Two"}

In my opinion, the JSON approach would be much easier as you can use either Joomla or native PHP json_encode/decode functions that will avoid having to explode.

Either way, another thing that you will have to consider is front-end validation but, this shouldn't give you too much of a headache!

Hope it helps!

Gez

Gez,

Thanks for your thoughts as it gives me some confirmation as to my direction! While I did have have some of the same thoughts in my head (how to store field defs and using JSON for configuration) it was great to hear your thoughts on JDOM and common handler as well. Not sure when I'll have time to work on this but hopefully soon.

Thanks again!
Dave

No worries mate!

A really good example of how this feature is implemented is in Akeeba Subscriptions which you can get from akeebabackup(dot)com for which I've quite recently done some quite extensive plugin development.

Akeeba Subs approach combines both a 'standard' implementation of adding custom fields to a subscription plan (referred to as a 'level' in AKSubs terminology) as well as providing a simple plugin architecture to create custom class definitions too.

Best of luck!

Gez

A small tutorial for JSON fields :

www.j-cook.pro/index.php/j/json-field