I have been working with Zend for a few months now and am at a stage where i'd like to add some fields to my form using TinyMce. What i want to achieve is to be able to just create a form extending Zend_form and just be able to say
$element = new TinyMce_Form_Element_Editor('element');
But i just do not have a single clue on how to achieve this. I have of course been looking around before asking this question and most sources just point me towards this site.
Wich seems to be aimed at people with alot of experiance with Zend. 2 months in it's not a big surprise i am not at the level this might have been intended for as i have tried following the instrucutions given and creating the file setup as shown by in the svn repositiry create by the writer of this article.
Aside from heading from one error into another i also do not uderstand what the code is doing exactly, i just have a vague guess at best when i run trough it.
Is there any kind of easy to follow simple tutorial explaining how to enable tinymce in a Zend Form?
Any advice or tips on how to achieve my goal will be well appreciated
Not best solution but you may find it useful:
class My_Form_Element_Tinymce extends Zend_Form_Element_Textarea
{
/**
* Element CSS class name
* #var string
*/
protected $class = 'tinyMCE';
public function init()
{
$this->getView()->headScript()->appendFile('path/to/tinymce.js');
$this->getView()->headScript()->appendFile('path/to/tinymce_config.js');
}
}
and in your tinymce_config.js add selector for tinyMCE class name
tinymce_config.js is your tinyMCE configuration file if you never used tinyMCE goto http://tinymce.com and you will find many examples with what you need.
Related
I've been searching for quite a while but neither solution worked.
I have created a backend module which shall display orders in a table. I achieved creating a table containing the wanted information BUT I need some more functionality and I thought there would be an easy way.
The table should be sortable, filterable and searchable - functions that TYPO3 uses for displaying datasets in the backend already.
I have tried to make use of the DataTables which are already included by the core of TYPO3 and should be easily accessible according to the following links:
https://forum.typo3.org/index.php/t/210780/
https://typo3.com/blog/how-to-use-javascript-in-typo3s-backend/
TYPO3 backend modul DataTable is no function
I added a js-file according to the answer from Philipp Wrann in the first link:
/Resources/Public/JavaScript/OrderingTables.js:
define('TYPO3/CMS/GiPdShop', ['jquery', 'datatables'], function($) {
var OrderingTables = {};
// Initialize dataTables
OrderingTables.initializeDataTables = function() {
$('#orders-table').DataTable();
};
$(document).ready(function() {
// Initialize the view
OrderingTables.initializeDataTables();
});
});
As there are no errors and the file is included if I check in the dev-tools I believe this is not a bad approach. To use the file I added the following to the <f:be.container> in the template:
includeRequireJsModules="{0: 'TYPO3/CMS/GiPdShop/OrderingTables'}"
Yet it doesn't create a DataTable, no added classes to the rows or cells of the table and thus I assume that there is some kind of error, maybe a missing configuration, maybe another option I missed out somehow.
The only other solutions I found so far seem rather complicated and I would love to keep it as simple as possible (I am not a professional in TYPO3 (yet) and the module should already be functional).
Can someone see a mistake I haven't found? Is it even possible to add the wanted functionality in such an easy way?
Any help would be highly appreciated.
It's really a stupid little thing I was missing.
The path 'TYPO3/CMS/GiPdShop' in the definition was missing the module.
So the correct path would be 'TYPO3/CMS/GiPdShop/OrderingTables', the same I have added in the template.
Really stupid but maybe this helps someone someday who gets stuck as well...
#PaulBeck thanks again!
since I'm pretty new to TYPO3 I'd like to know is there a possibility of adding simple text hints / tips below any type of field, something like this, for Nickname input field:
Thank you in advance!
Out of the box, not yet.
We are discussing a generic way to do so as we speak, but right now you'd need to create your own renderType for FormEngine.
Given the amount of PHP knowledge you have this is easy to intermediate.
Here are the steps:
Step 1: add your own formEngine Type class in ext_localconf.php
$GLOBALS['TYPO3_CONF_VARS']['SYS']['formEngine']['nodeRegistry'][1463078603] = array(
'nodeName' => 'ApparelCalculation',
'priority' => 40,
'class' => \T3G\Apparel\FormEngine\ApparelCalculation::class,
);
The number 1463078603 should be unique, so a good idea is to use the current unix-timestamp for that.
Step 2: Instruct your field to use that renderType
Add a TCA override file in YOUR_EXTENSION/Configuration/TCA/Overrides/tt_content.php (in this case we're overriding tt_content, thus the name. If you want to reconfigure another table in TYPO3, use the filename according to the tablename.
Add something along this:
$GLOBALS['TCA']['tt_content']['columns']['header']['config']['renderType'] = 'ApparelCalculation';
See how the renderType name is identical to what we registered in step 1.
Step 3: Render what you like to render
I'll add the configuration of my special case class here, but I will cover the important things later in this post:
It might be helpful for your case to copy from backend/Classes/Form/Element/InputTextElement.php since that seems to be the element you want to put your tip to.
<?php
namespace T3G\Apparel\FormEngine;
use T3G\Apparel\Calculation\Calculation;
use TYPO3\CMS\Backend\Form\Element\AbstractFormElement;
use TYPO3\CMS\Core\Utility\GeneralUtility;
class ApparelCalculation extends AbstractFormElement
{
/**
* Renders the Apparel Calculation Table
*
* #return array
*/
public function render()
{
$resultArray = $this->initializeResultArray();
$calculator = GeneralUtility::makeInstance(Calculation::class);
$resultTable = $calculator->calculateOrder($this->data['databaseRow']['uid']);
$resultArray['html'] = $resultTable;
return $resultArray;
}
}
I won't focus on things outside the render()method, because that's just plain PHP.
It is important to call $this->initializeResultArray(); first, so TYPO3 can work its magic to gather all the data.
From here on I'd suggest to use xdebug to get a grip of what you have available in that class.
The amount of information is very dense, but you will have everything there you need to build even the craziest stuff.
Now that you know how everything plays together you might think about extending backend/Classes/Form/Element/InputTextElement.php with plain PHP, grab the result of the parent render() call and simply add your tip to it.
Enjoy :)
Silverstripe Display Logic works perfectly on forms in the CMS but I cannot get it to work on forms in the front end, specifically Bootstrap forms.
It will hide the element but won't display it when logic is applied.
//If the wetsuit dropdown is equal to custom then show the fins numerical field.
DisplayLogicWrapper::create(NumericField::create("Fins","Fins"))->displayIf("Wetsuit")->isEqualTo('Custom')->end(),
I see it just needs display to change from none to block.
Is there a way to do this so that it will keep the state on page reload as well? The drop down value will be saved as a DB entry.
EDIT: This works in the CMS but doesn't work in the front end - Custom is part of the enum values.
DropdownField::create("Wetsuit","Wetsuit")
->setSource(singleton('DiveEquipment')->dbObject('Wetsuit')->enumValues())
->setEmptyString('Select one'),
NumericField::create('Fins','Fins')
->displayIf('Wetsuit')
->isEqualTo('Custom')
->end(),
EDIT2: Working with SilversTripe 3.5, Bootstrap Forms 1.20 and Display Logic 1.0.8
1.0.8 is very outdated though.
I don't think you need the DisplayLogicWrapper for most fields… It's meant for fields like UploadField.
Have you tried this?
NumericField::create('Fins','Fins')
->displayIf('Wetsuit')
->isEqualTo('Custom')
->end(),
Not the issue here, but it's worth noting that a bug exists in Display Logic 1.3 and lower where the custom templates exist in /templates/ not /templates/forms/, causing precedence issues.
If you're experiencing problems with a FieldGroup not rendering the correct template or whatnot. Upgrading to Display Logic 1.4 will resolve this.
You'll need to include jQuery and jQuery Entwine for this to work on the frontend. This is untested but should resolve your issue.
class Page_Controller extends ContentController {
public function init() {
parent::init();
Requirements::javascript(THIRDPARTY_DIR . '/jquery/jquery.js');
Requirements::javascript(THIRDPARTY_DIR . '/jquery-entwine/dist/jquery.entwine-dist.js');
}
}
I have no idea how I have to improve my listview in the backend module with a search or a filter (for only the records in the folder). That's why I don't have any code to show.
I actually have a list of all records and now I have to optimize this view for the administrator. This means I'd like to search over some columns and a filter to show only the records with the selected categorie from the dropdown.
I hope that someone can give me a hint, link or example how to realize something like that. I think it is a general thing how I can manipulate or integrate own php scripts or whatever.
Thanks for your help guys
Cheers
You can implement an filter method to you repository. Submit the form of filters to your index action an instead of $this->myRepository->fetchAll() make an function with filter: $this->myRepository->fetchByFilter($categorie).
In your repository class it looks something like that:
function fetchByFilter($categorie) {
$query = $this->createQuery();
$matching = [
$query->containts('categories', $categorie)
];
return $query->matching($query->logicalAnd($matching))->execute();
}
There might be such feature soon in the TYPO3 core (version 8.x), however doing such thing is not really easy.
An easier approach would be to use a custom backend module and render the content of the list module there again including the filter. You can take a look how I do it with the TYPO3 extension newssince version 5.0.
The contoller: https://github.com/TYPO3-extensions/news/blob/master/Classes/Controller/AdministrationController.php
Adding the filter for the record list: https://github.com/TYPO3-extensions/news/blob/master/Classes/Hooks/Backend/RecordListQueryHook8.php#L76
Hope that helps!
I want to add some javacsript to a Zend_Form_Element_Text .
At first I thought a decorator would be the best way to do it, but since it is just a script (the markup doesn't change) then maybe a view helper is better? or a view script?
It seems like they are all for the same purpose (regarding a form element).
The javascript I want to add is not an event (e.g. change, click, etc.). I can add it easily with headScript() but I want to make it re-usable , that's why I thought about a decorator/view helper. I'm just not clear about the difference between them.
What is the best practice in this case? advantages?
UPDATE: Seems like the best practice is to use view helpers from view scripts , so decorators would be a better fit?
Thanks.
You could create your own decorator by extending Zend_From_Decorator_Abstract and generate your snippet in it's render() method :
class My_Decorator_FieldInitializer extends Zend_Form_Decorator_Abstract {
public function render($content){
$separator = $this->getSeparator();
$element = $this->getElement();
$output = '<script>'.
//you write your js snippet here, using
//the data you have in $element if you need
.'</script>';
return $content . $separator . $output;
}
}
If you need more details, ask for it in a comment, i'll edit this answer. And I didn't test this code.
Use setAttrib function.
eg:-
$element = new Zend_Form_Element_Text('test');
$element->setAttrib('onclick', 'alert("Test")');
I'm not actually seeing where this needs to be a decorator or a view-helper or a view-script.
If I wanted to attach some client-side behavior to a form element, I'd probably set an attribute with $elt->setAttrib('class', 'someClass') or $elt->setAttrib('id', 'someId'), some hook onto which my script can attach. Then I'd add listeners/handlers to those targeted elements.
For example, for a click handler using jQuery , it would be something like:
(function($){
$(document).ready(function(){
$('.someClass').click(function(e){
// handle the event here
});
});
})(jQuery);
The benefit is that it is unobtrusive, so the markup remains clean. Hopefully, the javascript is an enhancement- not a critical part of the functionality - so it degrades gracefully.
Perhaps you mean that this javascript segment itself needs to be reusable across different element identifiers - someClass, in this example. In this case, you could simply write a view-helper that accepts the CSS class name as the parameter.
"the markup doesn't change", Yap,
but I like to add some javascript function throw ZendForm Element:
$text_f = new Zend_Form_Element_Text("text_id");
$text_f->setAttrib('OnChange', 'someFunction($(this));');
The best way is if you are working with a team, where all of you should use same code standard. For me and my team this is the code above.