Id like to see how the base path view helper sets up the base path variable inside the helper class.
This is an internal based questions, as I imagine its being done with a factory behind the scenes.
I needed to replicate it with a custom version but im hardcoding the base path currently: You'll see that even though its extending the basepath viewhelper i cannot configure the basepath variable without this current solution of hardcoding it
class PlutoBasePath extends \Zend\View\Helper\BasePath
{
public function __construct()
{
/**
* #todo
* #var Ambiguous $basePath
*/
$this->basePath = Pluto::registry('prepend_location_url');
}
public function __invoke($file = null)
{
if (null === $this->basePath) {
throw new Exception\RuntimeException('No base path provided');
}
if (null !== $file) {
\Pluto\Stdlib\FilesystemUtils::sanitizeFilePaths($file);
\Pluto\Stdlib\FilesystemUtils::trimLeadingPath($file);
}
return $this->basePath.$file;
}
}
Id rather use a factory but I dont know how to access the base path set logic WHICH SETS UP THE FACTORY BASE PATH FOR THE base path view helper to setup the custom base path correctly
How is it possible for me to see the factory creation of the base path view helper is my base question
I seem to have found where the basepath is set, here Zend\Mvc\Service\ViewHelperManagerFactory::createBasePathHelperFactory().
private function createBasePathHelperFactory(ContainerInterface $services)
{
return function () use ($services) {
$config = $services->has('config') ? $services->get('config') : [];
$helper = new ViewHelper\BasePath;
if (Console::isConsole()
&& isset($config['view_manager']['base_path_console'])
) {
$helper->setBasePath($config['view_manager']['base_path_console']);
return $helper;
}
if (isset($config['view_manager']) && isset($config['view_manager']['base_path'])) {
$helper->setBasePath($config['view_manager']['base_path']);
return $helper;
}
$request = $services->get('Request');
if (is_callable([$request, 'getBasePath'])) {
$helper->setBasePath($request->getBasePath());
}
return $helper;
};
}
I hope this helps
Here is a piece of code that I use in my application and that should answer your question (to be adapted according to the schema of your project)
use Zend\View\Renderer\PhpRenderer;
use Zend\View\Resolver;
...
$stack = new Resolver\TemplatePathStack(
[
'script_paths' => [
__DIR__ . '/../../../view'
]
]);
$resolver = new Resolver\AggregateResolver();
$resolver->attach($stack);
$renderer = new PhpRenderer();
$renderer->setResolver($resolver)
->plugin('basePath')
->setBasePath('/');
Related
How can I migrate this TypoScript condition to be fully compatible with the Symfony Expression Language for conditions in TYPO3 9.5?
[userFunc = TYPO3\CMS\Core\Utility\ExtensionManagementUtility::isLoaded('fluid_styled_content')]
You'd have to provide your own functions at the moment.
There is a tutorial here: https://usetypo3.com/symfony-expression-language-in-typo3.html
But basically you'd have the file yourext/Configuration/ExpressionLanguage.php with content like:
<?php
return [
'typoscript' => [
\Vendor\Yourext\ExpressionLanguage\ConditionProvider::class
]
];
This registers a condition provider for the typoscript context.
For adding simple functions you need to set function provider classes to the expressionLanguageProviders of that class.
Which might look like this:
<?php
namespace Vendor\Yourext\ExpressionLanguage;
use TYPO3\CMS\Core\ExpressionLanguage\AbstractProvider;
class ConditionProvider extends AbstractProvider
{
public function __construct()
{
$this->expressionLanguageProviders = [
UtilitiesConditionFunctionsProvider::class,
SomeOtherConditionFunctionsProvider::class,
AThirdConditionFunctionsProvider::class,
];
}
}
(Maybe even set it on the property directly, instead of using the constructor, but that's what I did).
Those function providers need to implement the \Symfony\Component\ExpressionLanguage\ExpressionFunctionProviderInterface interface, which is basically just a getFunctions method that needs to return an array of \Symfony\Component\ExpressionLanguage\ExpressionFunction instances.
My UtilitiesConditionFunctionsProvider looks like this:
<?php
namespace Vendor\Yourext\ExpressionLanguage;
use Symfony\Component\ExpressionLanguage\ExpressionFunction;
use Symfony\Component\ExpressionLanguage\ExpressionFunctionProviderInterface;
use TYPO3\CMS\Core\Utility\ExtensionManagementUtility;
class UtilitiesConditionFunctionsProvider implements ExpressionFunctionProviderInterface
{
/**
* #return ExpressionFunction[] An array of Function instances
*/
public function getFunctions()
{
return [
$this->getIntersectsFunction(),
$this->getExtensionLoadedFunction(),
];
}
/**
* #return ExpressionFunction
*/
protected function getIntersectsFunction()
{
return new ExpressionFunction('intersects', function () {
// Not implemented, we only use the evaluator
}, function ($arguments, $left, $right) {
return count(array_intersect($left, $right)) > 0;
});
}
protected function getExtensionLoadedFunction()
{
return new ExpressionFunction('loaded', function () {
// Not implemented, we only use the evaluator
}, function ($arguments, $extKey) {
return ExtensionManagementUtility::isLoaded($extKey);
});
}
}
With that it's now possible to use intersects( ... ) and loaded( ... ) in my conditions.
Is there any way to set the circular reference limit in the serializer component of Symfony (not JMSSerializer) with any config or something like that?
I have a REST Application with FOSRestBundle and some Entities that contain other entities which should be serialized too. But I'm running into circular reference errors.
I know how to set it like this:
$encoder = new JsonEncoder();
$normalizer = new ObjectNormalizer();
$normalizer->setCircularReferenceHandler(function ($object) {
return $object->getName();
});
But this has to be done in more than one controller (overhead for me).
I want to set it globally in the config (.yml) e.g. like this:
framework:
serializer:
enabled: true
circular_limit: 5
Found no serializer API reference for this so I wonder is it possible or not?
For a week have I been reading Symfony source and trying some tricks to get it work (on my project and without installing a third party bundle: not for that functionality) and I finally got one. I used CompilerPass (https://symfony.com/doc/current/service_container/compiler_passes.html)... Which works in three steps:
1. Define build method in bundle
I choosed AppBundle because it is my first bundle to load in app/AppKernel.php.
src/AppBundle/AppBundle.php
<?php
namespace AppBundle;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\HttpKernel\Bundle\Bundle;
class AppBundle extends Bundle
{
public function build(ContainerBuilder $container)
{
parent::build($container);
$container->addCompilerPass(new AppCompilerPass());
}
}
2. Write your custom CompilerPass
Symfony serializers are all under the serializer service. So I just fetched it and added to it a configurator option, in order to catch its instanciation.
src/AppBundle/AppCompilerPass.php
<?php
namespace AppBundle;
use Symfony\Component\DependencyInjection\Compiler\CompilerPassInterface;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\Reference;
class AppCompilerPass implements CompilerPassInterface
{
public function process(ContainerBuilder $container)
{
$container
->getDefinition('serializer')
->setConfigurator([
new Reference(AppConfigurer::class), 'configureNormalizer'
]);
}
}
3. Write your configurer...
Here, you create a class following what you wrote in the custom CompilerPass (I choosed AppConfigurer)... A class with an instance method named after what you choosed in the custom compiler pass (I choosed configureNormalizer).
This method will be called when the symfony internal serializer will be created.
The symfony serializer contains normalizers and decoders and such things as private/protected properties. That is why I used PHP's \Closure::bind method to scope the symfony serializer as $this into my lambda-like function (PHP Closure).
Then a loop through the nomalizers ($this->normalizers) help customize their behaviours. Actually, not all of those nomalizers need circular reference handlers (like DateTimeNormalizer): the reason of the condition there.
src/AppBundle/AppConfigurer.php
<?php
namespace AppBundle;
class AppConfigurer
{
public function configureNormalizer($normalizer)
{
\Closure::bind(function () use (&$normalizer)
{
foreach ($this->normalizers as $normalizer)
if (method_exists($normalizer, 'setCircularReferenceHandler'))
$normalizer->setCircularReferenceHandler(function ($object)
{
return $object->getId();
});
}, $normalizer, $normalizer)();
}
}
Conclusion
As said earlier, I did it for my project since I dind't wanted FOSRestBundle nor any third party bundle as I've seen over Internet as a solution: not for that part (may be for security). My controllers now stand as...
<?php
namespace StoreBundle\Controller;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Method;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
class ProductController extends Controller
{
/**
*
* #Route("/products")
*
*/
public function indexAction()
{
$em = $this->getDoctrine()->getManager();
$data = $em->getRepository('StoreBundle:Product')->findAll();
return $this->json(['data' => $data]);
}
/**
*
* #Route("/product")
* #Method("POST")
*
*/
public function newAction()
{
throw new \Exception('Method not yet implemented');
}
/**
*
* #Route("/product/{id}")
*
*/
public function showAction($id)
{
$em = $this->getDoctrine()->getManager();
$data = $em->getRepository('StoreBundle:Product')->findById($id);
return $this->json(['data' => $data]);
}
/**
*
* #Route("/product/{id}/update")
* #Method("PUT")
*
*/
public function updateAction($id)
{
throw new \Exception('Method not yet implemented');
}
/**
*
* #Route("/product/{id}/delete")
* #Method("DELETE")
*
*/
public function deleteAction($id)
{
throw new \Exception('Method not yet implemented');
}
}
The only way I've found is to create your own object normalizer to add the circular reference handler.
A minimal working one can be:
<?php
namespace AppBundle\Serializer\Normalizer;
use Symfony\Component\Serializer\Normalizer\ObjectNormalizer;
use Symfony\Component\PropertyAccess\PropertyAccessorInterface;
use Symfony\Component\PropertyInfo\PropertyTypeExtractorInterface;
use Symfony\Component\Serializer\Mapping\Factory\ClassMetadataFactoryInterface;
use Symfony\Component\Serializer\NameConverter\NameConverterInterface;
class AppObjectNormalizer extends ObjectNormalizer
{
public function __construct(ClassMetadataFactoryInterface $classMetadataFactory = null, NameConverterInterface $nameConverter = null, PropertyAccessorInterface $propertyAccessor = null, PropertyTypeExtractorInterface $propertyTypeExtractor = null)
{
parent::__construct($classMetadataFactory, $nameConverter, $propertyAccessor, $propertyTypeExtractor);
$this->setCircularReferenceHandler(function ($object) {
return $object->getName();
});
}
}
Then declare as a service with a slithly higher priority than the default one (which is -1000):
<service
id="app.serializer.normalizer.object"
class="AppBundle\Serializer\Normalizer\AppObjectNormalizer"
public="false"
parent="serializer.normalizer.object">
<tag name="serializer.normalizer" priority="-500" />
</service>
This normalizer will be used by default everywhere in your project.
How can i get current category in magento2 ?
I want to get category name and category id in custom phtml file.
The above to seem correct, but I think that jumping straight to the Registry is not the best approach. Magento provides a Layer Resolver that already encapsulates that functionality. (See the TopMenu Block in the Catalog Plugins)
I suggest injecting the \Magento\Catalog\Model\Layer\Resolver class and using that to get the current category. Here is the code :
<?php
namespace FooBar\Demo\Block;
class Demo extends \Magento\Framework\View\Element\Template
{
private $layerResolver;
public function __construct(
\Magento\Framework\View\Element\Template\Context $context,
\Magento\Catalog\Model\Layer\Resolver $layerResolver,
array $data = []
) {
parent::__construct($context, $data);
$this->layerResolver = $layerResolver;
}
public function getCurrentCategory()
{
return $this->layerResolver->get()->getCurrentCategory();
}
}
Here is what the actual getCurrentCategory() method does in the Resolver Class.
public function getCurrentCategory()
{
$category = $this->getData('current_category');
if ($category === null) {
$category = $this->registry->registry('current_category');
if ($category) {
$this->setData('current_category', $category);
} else {
$category = $this->categoryRepository->get($this->getCurrentStore()->getRootCategoryId());
$this->setData('current_category', $category);
}
}
return $category;
}
As you can see, it does still use the registry but it provides a fallback in case that fails.
Magento sets registry for categories being accessed. So, to get currenct category, use following method:
/**
* #param \Magento\Framework\Registry $registry
*/
protected $_registry;
public function __construct(
\Magento\Framework\Registry $registry
) {
$this->_registry = $registry;
}
and then use:
$category = $this->_registry->registry('current_category');//get current category
Now you can access the collection and fetch details such as $category->getName()
No need to use the object manager or inject class. You can use a built-in helper class Magento\Catalog\Helper\Data in the following way.
<?php
$catalogHelperData = $this->helper('Magento\Catalog\Helper\Data');
$categoryObject = $catalogHelperData->getCategory();
$categoryId = $categoryObject->getId();
$categoryName = $categoryObject->getName();
?>
This code snippet should work for any phtml (built-in or custom) file which is related to product listing page or product detail page.
Try this code. this will definitely help you.
<?php
$objectManager = \Magento\Framework\App\ObjectManager::getInstance();
$category = $objectManager->get('Magento\Framework\Registry')->registry('current_category');//get current category
echo $category->getId();
echo $category->getName();
?>
In *.phtml files at Category page can get Category data with following snippet:
$currentCategory = $this->helper('Magento\Catalog\Helper\Data')->getCategory();
I'm trying to make a way to disable some view helpers that are inside "application/views/helpers"...
What I really want is to put some options on the application.ini to enable or disable some Helpers.
Example on application.ini:
helpers.Helper1=on
helpers.Helper2=off
Now the problem is that when a Helper is off, I want to rewrite some functions of this helper in order to return a different result on the view. In this way, I don't need to change anything in the view script.
I thought in having 2 different php files for each helper, in different locations. One with the real helper and another with the changed helper (to work when it is off on the application.ini).
The problem is that I don't know how to tell the view which one it shoul load...
Does anyone know how it could be done?
FINAL CODE
Ok, after many tries, I put it to work with the following code:
Bootstrap
protected function _initConfigureHelpers(){
$this->bootstrap('view');
$view = $this->getResource('view');
$view->addHelperPath("./../library/ConfigHelpers","Configurable_Helper");
$viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper(
'ViewRenderer'
);
$viewRenderer->setView($view);
$front = Zend_Controller_Front::getInstance();
$front->registerPlugin(new Application_Plugin_ViewPlugins());
return $view;
}
Application_Plugin_ViewPlugins
class Application_Plugin_ViewPlugins extends Zend_Controller_Plugin_Abstract
{
public function preDispatch(Zend_Controller_Request_Abstract $request){
$front=Zend_Controller_Front::getInstance();
$bootstrap=$front->getParam('bootstrap');
$options=$bootstrap->getOption("helpers");
if (is_array($options)){
$view = $bootstrap->getResource('view');
foreach($options as $option => $value){
$helper=$view->getHelper($option);
if ($helper){
if ($value=="off")
$helper->__disable();
else if ($value!="on")
throw new Exception('The value of helpers.'.$option.' must be "on" or "off" on application.ini.');
} else {
throw new Exception("Inexistent Helper");
}
}
}
}
}
Modified helper example
require_once APPLICATION_HELPERS."CssCrush.php";
class Configurable_Helper_CssCrush extends Zend_View_Helper_CssCrush {
protected $__config_enabled = true;
public function __disable(){
$this->__config_enabled = false;
return $this;
}
public function __enable(){
$this->__config_enabled = true;
return $this;
}
public function cssCrush(){
if ($this->__config_enabled){
return parent::cssCrush();
} else{
return new Modified_CssCrush();
}
}
}
class Modified_CssCrush {
public static function file ( $file, $options = null ) {
return $file;
}
}
APPLICATION_HELPERS is defined on /public/index.php as "../application/views/helpers/".
Now, when I want to add a configurable helper, I put the original helper on "/application/views/helpers/" and then, create a modified version of it on "/library/ConfigHelpers" with the structure of the example above.
What I think you want is Dependency Injection which is coming in zf2, but not available in zf1.
With some tinkering though you can get what you need.
Configuring helpers in the bootstrap
(assumes default project structure)
View helpers paths config : application/configs/application.ini:
resources.view.helperPath.Zf_View_Helper_ = "Zf/View/Helper"
A simple configurable helper, (allows disable/enable but you can obviously add any methods you need (use this as base class for helpers that need the behaviour)
class Zf_View_Helper_Configurable extends Zend_View_Helper_Abstract
{
protected $isEnabled = true;
public function configurable()
{
return $this;
}
public function disable()
{
$this->isEnabled = false;
return $this;
}
public function enable()
{
$this->isEnabled = true;
return $this;
}
public function __toString()
{
if ($this->isEnabled) {
return 'Configurable is enabled';
} else {
return 'Configurable is disabled';
}
}
}
And configure the helpers in the bootstrap:
public function _initConfigureHelpers()
{
$this->bootstrap('view');
$view = $this->getResource('view');
$configurableHelper = $view->configurable();
$configurableHelper->disable();
}
You can add options in the .ini file and grab them in the bootstrap initConfigureHelpers() method.
If you want this behaviour from any default zf helper, do what #Ratzo said and extend those helpers and add the required behaviour and then configure them in your bootstrap.
Please take a look at the following link Zend_View link
Below is an important points you should consider from the Zend docs.
Note: Default Helper Path
The default helper path always points to the Zend Framework view
helpers, i.e., 'Zend/View/Helper/'. Even if you call setHelperPath()
to overwrite the existing paths, this path will be set to ensure the
default helpers work.
This means that you can't really turn off the helpers, unless you want to go about extending the Zend_View object and overwrite the setHelperPath method. This is not the way to go though.
Here is probably what you want to do. First though, here is my assumption.
Assumption : You want to write your own view helper that slightly alters what the current view helpers do by changing a few methods here or there.
Here is what you should do to accomplish that.
First, write your view helper. Make sure the last part of the class name is the same as the view helper you want to 'overwrite'. You don't have to, but this makes sure the original helper can't be used anymore.
class My_View_Helper_BaseUrl extends Zend_View_Helper_BaseUrl
{
private $_enabled = true;
public function setEnabled( $bool ){ $this->_enabled = (boolean) $bool; }
public function baseUrl(){
if( $this->_enabled ){
return 'testUrl'; //other code
}
else return parent::baseUrl();
}
Now that you have that, do the following
$view->setHelperPath('/path/to/my/helpers', 'My_View_Helper'); //1
echo $view->baseUrl(); //2
Excellent. Now you've effectively shadowed the original BaseUrl helper.
The above code will make it so that the view scans your directory
for any helpers before scanning the default zend directory. When it gets to line
2 the view will find YOUR baseUrl helper first and use THAT instead of the
original baseUrl helper. In the above example it should echo
'testurl' instead of the normal baseUrl behavior.
You can make a custom helper that extends the original helper, for example
class My_Helper_Url extends Zend_View_Helper_Url
{}
and rewrite the methods as you need.
So I've created myself a custom form element which has a custom view helper. Now I want to be able to set certain parameters/variables on this form element and be able to access them in my element's view helper. How can I do that?
Here's an example of what I am talking about:
adding the element to the form:
$element = new My_Form_Element_Picker('elementname');
$element->setFoobar('hello');
// or
$form->addElement('Picker', 'elementname', array('foobar' => 'hello'));
form element:
class My_Form_Element_Picker extends Zend_Form_Element_Xhtml
{
public $helper = 'pickerElement';
}
view helper:
class My_View_Helper_PickerElement extends Zend_View_Helper_FormElement
{
public function pickerElement($name, $value = null, $attribs = null)
{
//now I want to check if the 'foobar' option was set, otherwise use a default value
$foobar = 'default';
}
}
There is a fourth optional argument to the view helper that might do the trick for you.
if you define your view helper like this:
public function pickerElement( $name, $value=null, $attribs=null, $options=null ) { }
And then inside your actual form element you define it like this:
class My_Form_Element_Picker extends Zend_Form_Element_Xhtml {
public $helper = 'pickerElement';
public $options = array();
public function setFoobar( $foobar ) {
$this->options['foobar'] = $foobar;
}
}
You will find that the options are passed into the view helper and can be used.
This code is from memory so please forgive any mistakes, this method definitely works for me though.