Custom Development Needed

Ok, I call it subform. It is like another small form that may be entered multiple time in main form.

This field is planned to be developed first for Cobalt 9. This is long waited field and I think many people waits for it. But unfortunately we cannot give it bigger priority right now. Unless work for it is paid.

Please use contact us and contact me if you are willing to sponsor this field development.

Is it some kind of repeatable field?? if it is then i also want repeatable field for cobalt 9 . I must say C8 is the most amazing CCK but it have 2 most demanding feature missing # repeatable field # conditional field . Meantime ZOO cck has repeatable field feature where member can create multiple instances while submitting article . It will be great if C9 provide the same feature ( repeatable should be common field properties where admn can choose wheather field should be repeatable or not ) . Best Wishes for cobalt 9

OK. This is how we will do that.

It's more like a repeatable form, like Sergey mentioned.

Your are able to define some field "groups" that will be repeatable inside the submission form.

Scenario is the following

1. Admin defines in Cobalt CCK a "repeatable group" (or "subform" as Sergey is calling it)

2. Admin defines what fields this "repeatable group" contains

3. Admin add this "repeatable group" to a content type.

On submission form for that content type

User will be able to create multiple instances of this "repeatable group" inside submission form and submit information for each one of them.

We need this aswell for Cobalt 8 since we can't wait for Cobalt 9 to be released . It can take many months until Cobalt 9 is released.

I am willing to sponsor this field development. Anybody else ?

Many questions are rising in my mind... ;-)

How does it work with the current field system and filters etc.?

How can I expose such a field in filters/advanced search?

Are those repeated fields "real" cobalt field copies in backend field manager?

Or just "logical" instances?

How do they store their values?

From my point of view "repeated field" is basically a "logical" instance.

Sergey called it right "subform", it;s more appropiate description.

We may aswell call it "fields collection" to avoid any confusion with the actually "real" fields from within Cobalt.

So, a "field collection" contains the actually "real" fields found in Cobalt.

You can add any number of fields to a "field collection" and inside submission form, user can add

("multiply") any number of "fields collection"

Values as stored the same way the "real" fields are functioning right now.

The user just multiply the "field collection" inside the submission form and enter values for each field contained in each "collection" . Hope it makes sense :)

For example:

Admin defines a "field collection" named "Product" inside the Cobalt backend and for this "field collection" he assigns 3 fields:

A. Product Name (text field)

B. Product Description (text area)

C. Product Images (gallery field)

Inside the submission form, user will be able to define as many "products" as they need, and for each one of them they can enter the info for the above assigned fields (name,description,gallery)

So, if you have a business directory, one will be able to submit a listing for their company, and using subforms, define and submit all of their products catalog "inside" the listing itself :D

Hope it makes sense :)

PS: All other Cobalt functionality should work without any issue since we are dealing with the "real" cobalt fields ... is just a matter of "logical" instances .. as you told.

There are 2 ways to implement it.

1. Create cobalt type and in subform field set that type as fields collection. This will not be saved as article anywhere just to be used to draw form. The advantage is that all current fields may be used. Disadvantage all fields have to be refactored as output format will not fit subform.

2. Create small CCK constructor in subform field parameters and only implement basic fields like image, checkbox, text, textarea, html, select. Those are completely different fields. Advantages we can design as flexible field as possible and will not be limited by current implementation. Disadvantage only few basic fields. But on the other hand not all cobalt fields would work if use 1. method.

One of the main problem is decide how it is going to work.

How does it work with the current field system and filters etc.?

That would be one of the cool thing. Subform is almost the same as chid field, but it simply store date right in the article rather than in the other section. thus when you filter by subform field, you filter inside section where parent is unlike you would filter children in the section of children.

How does it work with the current field system and filters etc.?

How can I expose such a field in filters/advanced search?

Any field of subform may be filterable or searchable.

How does it work with the current field system and filters etc.?

How can I expose such a field in filters/advanced search?

How do they store their values?

no matter what method to use, they will store only in record fields column and record_values table. Just like any other field does.

Subform is almost the same as chid field, but it simply store date right in the article rather than in the other section. thus when you filter by subform field, you filter inside section where parent is unlike you would filter children in the section of children.

Wouldn't it make sense to re-use the Cobalt Relation fields features to solve this type of data entry? Maybe extend and streamline their usage? BTW, i had an idea-topic for Relation fields, which might explain my rough thoughts. Basically, this is a form-in-a-form concept.

edit: corrected internal link, because of new Cobalt forum

What about this field project? Any progress? I can sponsor it too.

Not yet. But I planned to create field like this for Cobalt 9. Let's see if I can do that.