@test Success. Works as desired, and Hathor, too. Modal allows in both templates changing the creator, and filtering by category works, too, in both.

P.S.: Hathor of course with mootools modal.

Note to committers DO NOT merge this for 3.4. Wait until me and @phproberto have worked out the final desired form for a rendering class.

After applying patch I can see boostrapped modal window.

@richard67 @gunjanpatel thanks for the tests, but as @wilsonge stated in his comment this might have to wait a little bit more...

@dgt41 Yes, I've seen ... was easy to test and I had a bit time so I tested quickly ... which then seemed to make @wilsonge panic a bit that it could be merged too soon ;-)
What confused me a bit is that here you use the bootstrapped modal only for the isis, but in the other PR for the version property you have for both isis and Hathor a bootstrapped one. Was this by purpose?

@richard67 Actually is isis and protostar not hathor and yes in this one I didn’t copy the layout to html folder of protostar as it is not used (i think so, but I might be wrong) in front end

@dgt41 Ahhh, sure, I was wrong with the other PR. Thanks for clarification.

@test works fine for me! thanks for removing this mootools object :-)
At this moments, tree successful tests. Can somebody please set this PR as RTC?

@wilsonge

Note to committers DO NOT merge this for 3.4. Wait until me and @phproberto have worked out the final desired form for a rendering class.

What is the state here?

@zero-24 can we move this to RTC?

@wilsonge is your comment above (10 Jan 205) #5655 (comment) still valid? Else i think we can move to RTC here @dgt41

It's definitely a 3.5 thing anyhow. You can mark it as RTC but hold off merging it for now. I'm still chatting to Roberto about JLayouts atm

Thanks @wilsonge RTC but hold off merging it for now

#Test OK

@wilsonge Have you figured things out as to what to do with this PR? Can this be merged into 3.5 or should it wait longer?

A couple of comments :)

• If you move the logic that all the fields have to JFormField getInput() method you will save most of the getInput methods in child fields because the logic of getting the active layout and pass it data received from getLayoutData() will be probably the same. So I'd directly create a base getInput() in:

https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/form/field.php#L676

• If you do something like:

        $layout = !empty($this->element['layout']) ? (string) $this->element['layout'] : $this->layout;

in the top of the getInput method you can specify a different layout for the same field type (see my comment in #7948 (comment)). That multiplies x10 the power of fields and drastically reduces the number of fields your extensions require because most of the times that can be done with a layout.

I'm talking about something like:

<field 
    name="test" 
    type="list"
    label="Test field"
    layout="mylib.field.select2"
/>

That would be a list field type using a select2 override. So with one single field type you can implement multiple ways of rendering it. Do you want a typeahead field? Use type="text" layout="mylib.field.typeahead", etc.

That setting can also be tweaked when preparing forms from models, etc. so that also adds another entry point to programmatically control the layout rendered.

• Thinking in the future and in third part extensions I think we should move also the logic to get the renderer to JFormField with something like:

function getRenderer()
{
    $layout = !empty($this->element['layout']) ? (string) $this->element['layout'] : $this->layout;

    return new JLayoutFile($layout);
}

And it would be consumed in the getInput() method like:

return $this->getRenderer()->render($this->getLayoutData());

That allows us to easily replace the renderer that all our fields use changing 1 single method. It also allows that third part extensons use their favorite renderer instead of JLayout.

This maybe is outside the scope of current PR but I think it's better to start using layouts thinking in the future and making the system as flexible as possible.

@phproberto Since there is a programmed work to be done next week, here in Athens GR, I will not try all these recommendations in this PR. The code sprint should redo the Forms so I guess this input is more than valuable. By the way I can see the simplicity and the flexibility introduced with those few lines.

note, this will not work with repeatable
would be cool if we can fix it ... so will be one problem less for #6882

This PR has received new commits.

CC: @anibalsanchez, @gunjanpatel, @n9iels, @richard67

@Fedik check if this is ok for the repeatable, seems ok here

@dgt41 hm, no not work in repeatable, something missed .. need to check

@Fedik thanks for the code here. There is a minor thing still here, if the modal is closed by esc or clicking outside of the modal then the next time you will reopen you get one more iframe (repeating that procedure makes it even worst…). I think we need a listener for modal.on('hide') or something similar, this might affect also the media field (haven’t checked yet)

Same behavior also for media field

@Fedik Never mind I fixed that ????

I have tested this item successfully on 0723af2

Works good to me. Thanks.

Successful in isis, In Hathor similar to #5654, ...

btw: why is Hathor used?

But Hathor here is still using the mootools modal, so in essence nothing really changed there. Maybe Hathor needs some love or someone kicking it out of Joomla. Both will work...

or someone kicking it out of Joomla.

@dgt41 @mbabker did it allready here: joomla-projects/joomla-pythagoras#56

This PR has received new commits.

CC: @anibalsanchez, @gunjanpatel, @n9iels, @richard67, @zero-24

I have tested this item successfully on 589eff4

Works great. For testing you need aslso apply this: #8248

This PR has received new commits.

CC: @anibalsanchez, @gunjanpatel, @n9iels, @richard67, @zero-24

This is what a I see on Isis. Note the filter overlapping the modal:

I don´t know if thats a local issue? But the patch causes a broken layout...

I think that's a local issue yes @designbengel . Patch works here except that small filter thing.

ok i´ll install a new environment, thanks

I have tested this item successfully on 5077c77

This works without when #5871 is merged

I mean this requires the fixes applied in #5871 that affect all the modal windows

I have tested this item successfully on 5077c77

Thanks RTC now

REGRESSION: see #8669