Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improvements in layouts usage in fields #8248

Merged
merged 8 commits into from
Nov 4, 2015

Conversation

phproberto
Copy link
Contributor

Index

  1. Improvements
    1.1. [imp] Convert JFormField::getInputLayoutData() into JFormField::getLayoutData()
    1.2. [imp] Add a base JFormField::getInput() method that can be inherited
    1.3. [imp] Allow to debug fields rendering
    1.4. [imp] Add support to specify the rendering layout in form's XML
  2. Additional testing information

1. Improvements

1.1. Convert JFormField::getInputLayoutData() into JFormField::getLayoutData()

I think the purpose of that method is that we had different methods to get layout data for the label and for the input of the fields but we only need a single getLayoutData() that can be passed to getLabel() and getInput(). Sometimes frontenders face an issue that involves rendering the label of the field in the field itself. And that's easier if you have everywhere the information required to render anything.

1.2. Add a base JFormField::getInput() method that can be inherited

Now all the fields that extend JFormField can inherit the getInput() method and mostly remove it. Actually that should be our priority because getInput() method is the bigger headache for frontenders now. Removing it clearly sets a line betwee what backenders need to do (populate the required data in the getLayoutData() method) and frontenders need to do (style that data in the layouts).

Note that currently all the fields override the getInput() method so at current state only direct childs of JFormField will inherit getInput(). A good example is JFormFieldCheckboxes that inhertis JFormFieldList. So until the getInput() mehotd of JFormFieldList is not moved to a layout JFormFieldCheckboxes has to keep his own override.

1.3. Allow to debug fields rendering

Now fields that use the new JLayoutFile renderer will allow that developers enable/disable debug mode in the form XML just adding debug="true".

Example:

<field name="lineNumbers" type="radio"
       class="btn-group btn-group-yesno"
       debug="true"
       default="0"
       filter="options"
       description="PLG_CODEMIRROR_FIELD_LINENUMBERS_DESC"
       label="PLG_CODEMIRROR_FIELD_LINENUMBERS_LABEL"
    >
    <option value="1">JON</option>
    <option value="0">JOFF</option>
</field>

When the form is rendered it will show something like:

field-debug

1.4. Add support to specify the rendering layout in form's XML

Now fields also support that the same field can be rendered using different layouts just adding layout="mylibrary.field.name". That increases fields reusability because you can, for example, use a text field to add a currency value, an AJAX field, etc.

Example:

<field name="lineNumbers" type="radio"
       class="btn-group btn-group-yesno"
       default="0"
       layout="mylibrary.field.radio"
       filter="options"
       description="PLG_CODEMIRROR_FIELD_LINENUMBERS_DESC"
       label="PLG_CODEMIRROR_FIELD_LINENUMBERS_LABEL"
    >
    <option value="1">JON</option>
    <option value="0">JOFF</option>
</field>

3. Additional testing information

This PR changes internal behavior of fields. So:

  • Try to edit most common used forms.
  • Particularly check forms that involve type="radio" and type="checkboxes" fields because they have received most of the modifications.

abstract protected function getInput();
protected function getInput()
{
$layout = $this->getAttribute('layout', $this->layout);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should throw an exception if the layout is null right for b/c?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to be honest it is confuse 😄
I think if element has layout attribute, then it should go as other attributes through the setup() method, and then also available in __get() __set() .. so can be changed/used at runtime easily as $field->layout = 'bla.bla' 😉

@dgrammatiko
Copy link
Contributor

I have tested this item ✅ successfully on ff2f830

Core front end, back end, 3pd components all ok!
Updated the 3 fields PRs to get in-line with this

Thanks @phproberto


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8248.

@phproberto
Copy link
Contributor Author

@dgt41 note that tests fail :D I'll fix it in a couple of hours

@phproberto
Copy link
Contributor Author

I have removed the commit that removes the JLayout HTML comments from here. I will submit a new PR so we can merge it for v3.5

@phproberto
Copy link
Contributor Author

  • Now getInput throws an exception when there is not active layout. Thanks @wilsonge.
  • Now layout is processed in field setup and it can be accessed/modified with magic methods. Thanks @Fedik

Now let's try to get those tests working :P

@phproberto
Copy link
Contributor Author

Tests passed now 💃

'validate' => $this->validate,
'value' => $this->value
'autofocus' => $this->autofocus,
'classes' => explode(' ', $this->class),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why classes and not class? Ok I get that there might be many classes for the attribute, so in essence plural it is correct, but the attribute itself is singular class="whatever whatever_more". I mean in the layout I would expect to write something like this $this->class

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it because here is the array of classes, same for labelClasses 😉

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Fedik I know but we still can declare class in the array and then use $this->class in the layout. It is not a problem or a bug, it’s only that all the other vars are exactly the same as the attributes they are meant for. Basically a naming thing 😃

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree and I use class for my own but classes was already there so I kept it for B/C just in case anybody has already an override for checkboxes or radio fields. I also used labelClasses to be congruent with the solution that already existed.

Maybe I can add both? Not sure if that would be confusing. I can also rename the existing layouts to:

joomla/form/field/radio.php
joomla/form/field/checkboxes.php

Note the singular (field). That's the path I use for my own and renaming the layout will allow that old systems still work. Any old layout that already exist won't be loaded but the fields will work.

Thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although this is a really minor thing, I can see someone in the far future facepalming himself trying to understand why these two vars are plural instead of singular.
As far as I can tell: I don’t like the idea of having both class and classes in the array, but for changing the fields I guess we need a PLT decision. So I guess we are stuck once again with another weird convention 😃

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I vote for moving layouts. It will use the same structure than fields and I don't think there is a lot of people with overrides now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean with this last comment Roberto? Not sure I understand

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move layouts from:
layouts/joomla/form/fields/*
To:
layout/joomla/form/field

That way we can be sure nobody has an override and we can change the layout vars.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't move the ones that are already there - unless you can come up with a b/c fix. But you can move the form fields that we have added for 3.5

@joomla-cms-bot
Copy link

This PR has received new commits.

CC: @dgt41


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8248.

@phproberto
Copy link
Contributor Author

Ok. This is what I did:

  • JFormField will pass class & labelclass to layouts
  • To keep B/C in radio & checkboxes getLayoutData() methods I added the classes value for their layouts

I think this is the best we can do now.

@wilsonge
Copy link
Contributor

wilsonge commented Nov 3, 2015

If the layouts are new we can get away with it. Let me just check but I think they are new for 3.5 - if so then we can get away with it I guess

@dgrammatiko
Copy link
Contributor

Nice now I have to redo the other PRs 😝

@wilsonge
Copy link
Contributor

wilsonge commented Nov 3, 2015

#4022 we merged this october 1st. so no b/c issues with moving the layouts - my bad!

@phproberto
Copy link
Contributor Author

I'm moving layouts to layouts/joomla/form/field then. That doesn't affect you @dgt41 so let's get all together!

@phproberto
Copy link
Contributor Author

yes!

@joomla-cms-bot
Copy link

This PR has received new commits.

CC: @dgt41


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8248.

@phproberto
Copy link
Contributor Author

Is ready for new tests if travis gives the ok.

Being there testing the fields I noticed that codemirror fullScreenMod parameter was not aligned properly so I fixed it (remove 1 line). Just in case somebody see the XML modified.

Before:
before-codemirro

After:
after-codemirror

@zero-24
Copy link
Contributor

zero-24 commented Nov 4, 2015

I have tested this item ✅ successfully on 92225ca

Works good. I have tested this in combination with the other PRs by @dgt41 and can confirm that the radio and checkboxes (codemirror) in Backend still works. Thanks


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8248.

@dgrammatiko
Copy link
Contributor

I have tested this item ✅ successfully on 92225ca


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8248.

@zero-24
Copy link
Contributor

zero-24 commented Nov 4, 2015

RTC. Thanks.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8248.

@joomla-cms-bot joomla-cms-bot added the RTC This Pull Request is Ready To Commit label Nov 4, 2015
wilsonge added a commit that referenced this pull request Nov 4, 2015
Improvements in layouts usage in fields
@wilsonge wilsonge merged commit 922102d into joomla:staging Nov 4, 2015
@joomla-cms-bot joomla-cms-bot removed the RTC This Pull Request is Ready To Commit label Nov 4, 2015
@wilsonge
Copy link
Contributor

wilsonge commented Nov 4, 2015

Merged - thanks guys 😃

@zero-24
Copy link
Contributor

zero-24 commented Nov 4, 2015

A hug thank you goes to @phproberto 👍 That is great stuff!

@phproberto
Copy link
Contributor Author

Thanks to everybody involved in testing, commenting, improving and merging 💃

@phproberto phproberto deleted the jformfield branch November 4, 2015 15:19
@roland-d
Copy link
Contributor

roland-d commented Nov 4, 2015

Thank you @phproberto for your contribution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants