button apply between elements or order button apply

[Bauer]

...Or you can just do it all with javascript/jQuery and css - and avoid having to make changes to any of the Fabrik core code, templates, or layouts.

Examples of code included in the form_xx.js file...

If the form is new, hide Submit button and fix the border radius of the remaining apply button...

if (jQuery("tablename___id").val()==""){
    jQuery("button[name='Submit']").hide();
    jQuery("button[name='apply']").css({"border-top-left-radius":"4px","border-bottom-left-radius":"4px"});
}

Hide apply button and fix the border radius of the Submit button...

jQuery("button[name='apply']").hide();
jQuery("button[name='Submit']").css({"border-top-right-radius":"4px","border-bottom-right-radius":"4px"});

Switch the order of the Submit/apply buttons (it looks like Fabrik will take care of the border radius so long as both Apply and Submit is shown)...

jQuery("button[name='Submit']").insertAfter(jQuery("button[name='apply']"));

Insert a button after the control-group div of an element

jQuery("div.fb_el_tablename___elementname").after('<button type="button" class="btn button" onclick="parent.location='https://www.yourdomain.com/page-alias'" name="TestButton">ButtonLabel</button>');

Change the HTML of the Goback button to redirect to a certain page...

jQuery("button[name='Goback']").closest("div").html('<button type="button" class="btn button" onclick="parent.location='https://www.yourdomain.com/page-alias'" name="Goback"><i data-isicon="true" class="back"></i>&nbsp;Cancel/Go back</button>');

Add a class to a button for css styling...

jQuery("button[name='apply']").addClass("isnew");

button.isnew {
    background: darkgreen;
}

If you use the php form plugin for post processing, you can add a certain value to a button to help identify code that needs to be run in a certain situation, or where to redirect.

jQuery("button[name='Submit']").prop("value","toList");

You will know which 'submit' button was clicked because it will be a key name included in the form $data. For example, if apply was clicked there will be a $data['apply']-> and if Submit was clicked there will be a $data['Submit']->
(or if the last example was used you will see $data['Submit']->toList )

The general rule is the apply button submits the form and returns to the same form/page (unless changes to certain watch elements apply/'kick in' access restrictions which prevent that, in which case the view is changed to details rather than edit) - while the Submit button saves the form and returns to the list view (unless redirected).

 

[cheesegrits]

Yes - but when you do that, then you become responsible for maintaining it. So if I were to write code that changed the way (say) view.html.php and default_actions.php worked then the new functionality wouldn't get carried across to the override file. So to use a real example of my PR for class support for buttons - you might find that classes made it to the back end settings page, but then didn't display and you would be left scratching your head wondering why because you had forgotten that you had implemented the default_actions.php override.

So IMO my comment stands - try as much as possible to stick with the way Fabrik does things and only change them with overrides if absolutely necessary.

Then you might as well just say "don't use any layout or template or language overrides anywhere in Joomla because you might forget you did it". Which would drastically restrict the ability to customize. That's the whole point of overrides, so you CAN change the way the CMS or 3rd party extensions renders things, and you don't have to restrict yourself to "the way X does things".

I pretty strongly disagree with advice that says "don't use overrides for overriding things", alhough I do agree that there is an maintenance overhead, in that if what you overrode changes, you need to keep your override up to date. But I wouldn't have suggested this if it was in anything a) complex / difficult to maintain, or b) prone to frequent, backward compat breaking changes. I think we've changed that template file a handful of times since it was written, and only one (the dynamic grid naming) might have had an effect on future compat changes.

https://github.com/Fabrik/fabrik/co...views/form/tmpl/bootstrap/default_actions.php

-- hugh

 

[cheesegrits]

On a related note, "one of these days" I'm going to add some debug code to insert the path of the template / layout file being used into an HTML comment, so it's obvious from the page source where any given markup is coming from, which would go a long way to making maintaining overrides easier, as at least you'd have an easy way of seeing which file needs attention, by appending &fabrikdebug=1 and checking the page source.

-- hugh

 

[albertotactik]

bon day,
thanks for the reply.
I have been a week with fever.
thanks!