Feature resquest: Field parameter: Add an html attribute

This is very complex thing in cobalt. With fields like text and checkbox it is ok but it it is geo position selector on the map, where I add this attribute? Or other fields like upload?

It cannot be core field parameter because it will not fit any field.

I can only suggest to make custom field template and add this attribute manually where you need it.

I can only suggest to make custom field template and add this attribute manually where you need it.

BTW, this reminds me on previous discussions about** field template parameters**. In the beginning of Cobalt history it was declared as too complex, too complicated for average users etc. I remember there was a discussion where you mentioned there is going to be a feature like this... is it on C9 roadmap?

BTW, this reminds me on previous discussions about field template parameters. In the beginning of Cobalt history it was declared as too complex, too complicated for average users etc. I remember there was a discussion where you mentioned there is going to be a feature like this... is it on C9 roadmap?

Yes, this is still on Cobalt 9 roadmap.

André Milani Marcos

I think this should be easy enough to implement. Just a new field parameter for adding a HTML attribute for the field.

Yes! But wait, it can be better.

Seblod has a very powerful plugin "Typo" feature in almost every field.

It's not just for adding HTML attributes, but you can use a (raw) field substitution syntax to include other fields also. Think of inserting 3rd-party plugin code, concatenating fields, surrounding fields with divs to change the layout, etc.

A must have feature.

I do not think it is needed since we have field templates and form templates. We can change as general fields fetch pattern as individual field wraps.

Seblod - even if you can change seblod templates it is applied to all fields and all sections, etc.. There is not system that would allow you to affect single field in certain type.

Also Cobalt has a concept. Section, type and fields has only logic parameters and all display parameters are in template parameters.

It is not true right now everywhere. We are still have to add some display parameters in field parameters because field templates do not have separate parameters. but that will be changed in Cobalt 9 and after selecting field template you may set additional parameters. Then we can add those HTML typo style management.

Sergey

I do not think it is needed since we have field templates and form templates. We can change as general fields fetch pattern as individual field wraps.

I'm not sure what you mean by this. I understand it is all about templating in Cobalt and I can see its advantages. But I can't help myself seeing templating as a form of hacking. And hacks aren't always compatible with new releases of Cobalt, Joomla or even php.

Having that said, there are many ways to Rome

Maybe a "new field parameter" is not the right word here, it should be replaced by "new feature".

This enable people like you and others (thank you pepperstreet) to come up with solutions that fit perfectly in Cobalts structure, without resorting to the almighty template. :)

On topic:

What about the creation of a new (code) field which enables us to insert code and field substitutions?

But I can't help myself seeing templating as a form of hacking. And hacks aren't always compatible with new releases of Cobalt, Joomla or even php.

it is not hacking. because it is not simply changing templates. it is templates system. There is mechanism behind that prevents you to lose changes on update.

But I can't help myself seeing templating as a form of hacking. And hacks aren't always compatible with new releases of Cobalt, Joomla or even php.

Maybe a "new field parameter" is not the right word here, it should be replaced by "new feature".

This enable people like you and others (thank you pepperstreet) to come up with solutions that fit perfectly in Cobalts structure, without resorting to the almighty template.

I totally understand what you mean. But there is small problem. You need attribute to the field, someone need attribute to field container tag, some one need another container tag and class or only class for field tag or container tag.

What I want to say, although this parameter may be useful for some people it is related to how field is rendered rather than how it behaves. And Concept of Cobalt to have only logical parameters. And rendering parameters only in template parameters. And since we do not have field template parameters mechanism, there only option is to change template without parameter.

But If we start add every parameter that people what regarding how field should be rendered, we will end up with endless number as everyone has his own opinion on that.

Let's do this. In Cobalt 9 we will add field templates parameters mechanizm and then we will be open to all sort of parameters there.

Sergey

But If we start add every parameter that people what regarding how field should be rendered, we will end up with endless number as everyone has his own opinion on that.

Yes, you got a point here.

Sergey

But If we start add every parameter that people what regarding how field should be rendered, we will end up with endless number as everyone has his own opinion on that.

Sergey

Let's do this. In Cobalt 9 we will add field templates parameters mechanizm and then we will be open to all sort of parameters there.

I am confident you will find the right solution :)

In a related subject, what about a new parameter for checkboxes and radio buttons for adding an image along with the value.

You can do it in language overrides or simple add HTML inside value.

User VAL_1 as value and add

VAL_1=" Value 1"

or use

Value 1

Directly as value text.