I have tested this item ✅ successfully on 08fa825

cool idea, also it allow to add huge text as default value for textarea, editor, more easy

test example for textarea:

<field type="textarea" name="myfield1" class="input-xxlarge" rows="6">
  <default><![CDATA[
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Cras risus velit, malesuada ut feugiat semper, blandit sit amet velit.
Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.
  ]]></default>
</field>

for editor:

<field type="editor" name="myfield2" >
  <default><![CDATA[
<h3>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</h3>
<p>Cras risus velit, malesuada <strong>ut feugiat semper</strong>, blandit sit amet velit.<br />
Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.</p>
  ]]></default>
</field>

I like this but I think the check should be flipped, first check if there is a default attribute and then check for a default node. Just to be 100% BC safe ?

Just asked myself, do we even need a <default> tag? Would that not also also work:

<field type="textarea" name="myfield1" class="input-xxlarge" rows="6">
  <![CDATA[
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Cras risus velit, malesuada ut feugiat semper, blandit sit amet velit.
Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.
  ]]>
</field>

@laoneo and how about subform then, with changes from another pull #12813 ?

<field type="subform" name="myfield" multiple="true">
    <![CDATA[
    [
       {"key1": "value1", "key2": value2},
       {"key1": "value3", "key2": value4},
       {"key1": "value5", "key2": value6}
    ]
    ]]>
   <form>
            <field name="key1"  label="key1"  type="text" />
            <field name="key2"  label="key2"  type="text" />
    </form>
</field>

looks not very good without <default>,
I think use <default> tag is a good idea.

True...

On Nov 26, 2016 3:43 PM, "Fedir Zinchuk" notifications@github.com wrote:

@laoneo https://github.com/laoneo and how about subform then, with
changes from another pull?

looks not very good without ,
I think use tag is a good idea.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#12451 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPUwCPW2zhv6o3B2Hp9FYcZy33DvAWHks5rCEWhgaJpZM4KZYfR
.

@laoneo You might be right about precedence. It's not likely to make any difference but it could, in theory.

Anyone else agree it should be flipped or see a reason why it shouldn't?

I think flipping will be more safe, in case if some extension already use <default> tag in own needs

Finally I got around to changing the precedence.

@okonomiyaki3000 it is works, if formsource is external file,
but broken when the form source is "children":

<field type="subform" name="myfield" multiple="true">
  <default><![CDATA[
[
        {"key1": "value1", "key2": "value2"},
        {"key1": "value3", "key2": "value4"},
        {"key1": "value5", "key2": "value6"}
]
]]></default>
	<form>
	  <field name="key1"  label="key1"  type="text" />
	  <field name="key2"  label="key2"  type="text" />
	</form>
</field>

@laoneo maybe you have an idea?

@Fedik The problem here is in JFormFieldSubform::setup()

if (!$this->formsource)
{
	// Set the formsource parameter from the content of the node
	$this->formsource = $element->children()->saveXML();
}

This is too flexible. A proper implementation would be like this:

if (!$this->formsource && $element->form)
{
	// Set the formsource parameter from the content of the node
	$this->formsource = $element->form->saveXML();
}

Changing it now may break BC. I will check a little. However, your example can work if the <default> and <form> elements are swapped. As long as <form> is first, it will be fine.

Maybe it does not need to be seen as a break since, even now, only a <form> element will actually work there.

OK, so here's the fix. Technically, it's a change to current behavior.

Before
A subform with no formsource will get its formsource from its children.
The first child must be a <form> element or the field will be broken in some way.
Any subsequent children (<form> or otherwise) will have no effect on the field.

After
A subform with no formsource will get its formsource from its first <form> child.
Any child node other than the first <form> will just be ignored.

Essentially, any subform definition that currently works will continue to work just the same. Some definitions which are currently broken (should such things exist at all), may be fixed.

I have tested this item ✅ successfully on 078a86c

@Fedik can you please test again?

I have tested this item ✅ successfully on 529f83f

Tested it with custom fields with #16659. If this one gets in, #16659 will be ready to be tested.

I have tested this item ✅ successfully on 529f83f

RTC after two successful tests.

As this one get in now, can you guys please test #16659. Would be nice to support that feature in custom fields, would make the default value attribute much more stable.