I don't manage to override the skeleton views of the generatorBundle.
I've first tried by adding my view in /app/Resources/SensioGeneratorBundle/skeleton/crud/views/index.html.twig
It didn't worked so I tried to create a new Bundle extending SensioGeneratorBundle and copy the my view in its Resources folder.
I already manage to use themes for twig forms, but I need to personalize the views generated by the doctrine:generate:crud command.
First of all: The corresponding skeleton views are located here:
vendor/bundles/Sensio/Bundle/GeneratorBundle/Resources/skeleton/crud
Quick and dirty you should be fine by overriding these view files - but thats not what we want ;)
In:
vendor/bundles/Sensio/Bundle/GeneratorBundle/Command/GenerateDoctrineCrudCommand.php
there is an accessor for the Generator:
protected function getGenerator()
{
if (null === $this->generator) {
$this->generator = new DoctrineCrudGenerator($this->getContainer()->get('filesystem'), __DIR__.'/../Resources/skeleton/crud');
}
return $this->generator;
}
One can try to override this method in your extending Bundle and set a different $skeletonDir in the constructor.
Edit:
Quick example in my test environment how it can be achieved (I only made a quick test ;):
Generate a new bundle for the custom generator: php app/console generate:bundle and follow the instructions. A route is not needed. I chose for this example: Acme/CrudGeneratorBundle (Or use an existing bundle)
Create a folder called "Command" in the newly created bundle directory.
Place a command class in this folder.
<?php
//src/Acme/CrudGeneratorBundle/Command/MyDoctrineCrudCommand.php
namespace Acme\CrudGeneratorBundle\Command;
use Sensio\Bundle\GeneratorBundle\Generator\DoctrineCrudGenerator;
class MyDoctrineCrudCommand extends \Sensio\Bundle\GeneratorBundle\Command\GenerateDoctrineCrudCommand
{
protected function configure()
{
parent::configure();
$this->setName('mydoctrine:generate:crud');
}
protected function getGenerator()
{
$generator = new DoctrineCrudGenerator($this->getContainer()->get('filesystem'), __DIR__.'/../Resources/skeleton/crud');
$this->setGenerator($generator);
return parent::getGenerator();
}
}
Copy the vendor/bundles/Sensio/Bundle/GeneratorBundle/Resources/skeleton/crud to your Resources (in my example "src/Acme/CrudGeneratorBundle/Resources/crud")
This was the best solution for me:
symfony2-how-to-override-core-template
doesn't add a command but modifies the skeleton for that particular bundle.
Related
I'm trying to use Areas in my ASP.NET Core ABP project like so:
Folder Structure
I'm trying to add a single file bundle like this:
<abp-script src="/Areas/Community/Pages/Mentors/Index.js" />
When I try running the page I get the following error:
AbpException: Could not find the bundle file '/Areas/Community/Pages/Mentors/Index.js' from IWebContentFileProvider
The documentation says the files can be located in Pages, Views, Components, and Themes but it seems limiting if it doesn't also support areas. Do I need to add a route somewhere so the virtual file system can find it?
Update:
I found the source code in \Volo.Abp.AspNetCore\Volo\Abp\AspNetCore\VirtualFileSystem\AbpAspNetCoreContentOptions.cs
where it sets the AllowedExtraWebContentFolders list:
AllowedExtraWebContentFolders = new List<string>
{
"/Pages",
"/Views",
"/Themes",
"/Components"
};
Is there any way to add to this list?
You can configure it in the module's ConfigureServices method.
public override void ConfigureServices(ServiceConfigurationContext context)
{
Configure<AbpAspNetCoreContentOptions>(options =>
{
options.AllowedExtraWebContentFolders.Add("/Areas");
});
}
I have a view helper being called in my layout that works fine in the default module, but I get an exception when I am in another module.
I have already changed my app.ini to use the default layout across all modules by setting:
resources.layout.layoutPath = APPLICATION_PATH "/layouts/scripts/"
And searching here and google provided me with another app.ini setting to add the view helper path for all modules:
resources.view.helperPath.Zend_View_Helper = APPLICATION_PATH "/views/helpers"
However instead of fixing the problem, that additional setting causes the Zend Exception to become a WSOD.
Without that second app.ini setting, I see the layout and get this exception:
Plugin by name 'AutoScript' was not found in the registry; used paths: Admin_View_Helper_: /Applications/XAMPP/xamppfiles/htdocs/dad/application/modules/admin/views/helpers/ Zend_View_Helper_: Zend/View/Helper/:./views/helpers/
With the helperPath.Zend_View_Helper ini setting I get a WSOD with the following:
Fatal error: Uncaught exception 'Zend_Loader_PluginLoader_Exception' with message 'Plugin by name 'AutoScript' was not found in the registry; used paths: Zend_View_Helper_: Zend/View/Helper/:./views/helpers/'
It appears the plugin loader is looking in public/views/helpers/ for the AutoScript.php file even though it should be using the APPLICATION_PATH value as a prefix.
My layout invocation looks like this
<?php $this->AutoScript(); ?>
My AutoScript.php file's class is defined in application/views/helpers/
class Zend_View_Helper_AutoScript extends Zend_View_Helper_Abstract {
public function AutoScript() {...}
}
My current fix is to copy the AutoScript.php file from application/views/helpers into modules/admin/views/helpers which fixes the issue, but duplicates a file. What am I missing? Do I have to add this view helper path programmatically by creating an _initView function in my bootstrap?
Typically, you would name your custom view helper with your own prefix, not the Zend_ prefix. Beyond that, there are several choices for where to put and name your view helpers.
If this view-helper is really a single-application helper, then I find it natural for it to reside somewhere in the application folder. Within that possibility space, I would ask if the view-helper will be used in a single module or across multiple modules.
If the view-helper is intended for use in a single module, then I depend upon the build-in resource-autoloader mappings and place my view-helper class Mymodule_View_Helper_Myhelper in the file application/modules/mymodule/views/helpers/Myhelper.php.
If the view-helper is intended for use across multiple modules , I might pull it up a little higher than the modules folder, say Application_View_Helper_Myhelper (assuming an appnamespace of Application) stored in
application/views/helpers/Myhelper.php. In this case, we need to tell the view that there are helpers with prefix Application_View_Helper_ in that directory. This can be done at bootstrap:
protected function _initViewHelperPaths()
{
$this->bootstrap('view');
$view = $this->getResource('view');
$view->addHelperPath(APPLICATION_PATH . '/views/helpers', 'Application_View_Helper_');
}
Sometimes, you need a view-helper in one module that exists in another module and you cannot - in practical terms - move the original one around. In that case, one workaround is to define an empty shell of a view-helper in your consuming module extending your unmovable view-helper. In file application/mymodule/views/helpers/MyHelper.php:
class Mymodule_View_Helper_Myhelper extends Othermodule_View_Helper_Myhelper
{
}
This way, the code for the helper implementation is not duplicated. The module-specific resource-autoloader mappings will allow all those classes to be found when they invoked as view-helpers from a view-script.
Finally, if this view helper is to be used in multiple projects, then there is an argument for placing it outside of application scope, out in in the library folder. So perhaps a class MyLibrary_View_Helper_Myhelper stored in the file library/MyLibrary/View/Helper/Myhelper.php. As before, you would need to inform the view - probably at bootstrap or in a front-controller plugin - of the prefix/path mapping:
$view->addHelperPath(APPLICATON_PATH . '/../library/MyLibrary/View/Helper', 'MyLibrary_View_Helper_');
Note that in all cases above, the invocation of the view-helper functionality itself - say, inside a view-script - is:
<?php echo $this->myhelper($params) ?>
Note, in particular, the casing difference between the classname and the invocation.
I'm working in a Zend Framework based application (Shopware).
I add a template dir in my controller like this:
class Shopware_Controllers_Backend_Pricify extends Shopware_Controllers_Backend_ExtJs
{
public function init()
{
$this->View()->addTemplateDir(dirname(__FILE__) . "/../../Views/backend/");
parent::init();
}
}
But somehow, smarty always looks in the (not existing) part of the controller action:
Unable to load template snippet 'backend/mycontroller/model/main.js' in 'snippet:string:{include file="backend/pricify/model/main.js"} in Smarty/sysplugins/smarty_internal_templatebase.php on line 128
The Controller works over loading via ext js, but I do not see that this is a problem. When I var_dump template directories, the correct dir is included. I debugged the code far into smarty, but never found the part, where the directories are checked.
I'm aware, that this may be a problem within the software stack, but since I do not know where to search, I ask here. If I need to post additional data, please tell me.
I found, that the problem was that shopware extends CamelCase to camel_case folders.
I am learning how to use Zend framework and realise that the action helper is something that would be useful.
I have set up a default installation of Zend on my machine, but I dont know where the helper file needs to go, what I need to put in the bootstrap file and how I use it. Can anyone point me in the right direction please - the ZF user guide is not to clear to me.
Thanks
John
Two thoughts for where to place your custom action-helpers:
In a separate, custom library
In the folder application/controllers/helpers
These ideas are not exclusive. Functionality that is general enough to work in multiple projects should probably be pulled into a separate library. But for functionality that is application-specific, there is an argument that it could be somewhere in the application folder.
#Jurian has already described the "separate-library" approach. For app-specific helpers, you can do as follows:
For a helper called myHelper, create a class Application_Controller_Helper_MyHelper in the file application/controllers/helpers/MyHelper.php. In Bootstrap, you have something like:
protected function _initAutoload()
{
$autoloader = new Zend_Application_Module_Autoloader(array(
'namespace' => 'Application',
'basePath' => APPLICATION_PATH,
));
Zend_Controller_Action_HelperBroker::addPath(
APPLICATION_PATH . '/controllers/helpers',
'Application_Controller_Helper_');
return $autoloader;
}
Then your helper can be invoked in a controller by using:
$this->_helper->myHelper;
As you can see, this presumes you are using appNamespace 'Application'. If not, you can (must!) modify your class names to accommodate your circumstance.
Cheers!
You can place action helpers in your own library. Besides library/Zend where all the Zend stuff is around, you can create a library/MyLibrary folder (MyLibrary is arbitrary chosen) and put the action helpers there.
A good place is the library/MyLibrary/Controller/Action/Helper folder you need to create and place your action helper there (i.e. Navigation.php). In this file, create the class MyLibrary_Controller_Action_Helper_Navigation.
The next step is to add the action helper to the HelperBroker of the Zend Framework during bootstrap. Therefore, create a new method in your Bootstrap.php file and add this function:
protected function _initActionHelpers ()
{
Zend_Controller_Action_HelperBroker::addHelper(
new MyLibrary_Controller_Action_Helper_Navigation()
);
}
One last remark is you need to configure the use of this library by adding this rule to your application.ini:
autoLoaderNameSpaces[] = "MyLibrary_"
You can do this through your application.ini file like so
resources.view[] =
resources.view.helperPath.Default_View_Helper_ = APPLICATION_PATH "/views/helpers/"
Then in your views/helpers path you can create a file like Time.php. This file would contain the following code:
<?php
class Default_View_Helper_Time extends Zend_View_Helper_Abstract
{
public function time()
{
$date = new Zend_Date();
return $date->get(Zend_Date::TIME_MEDIUM);
}
}
?>
To use this in your view scripts you would use
<?=$this->time()?>
Which would display the current time using your new View_Helper
You can avoid having to register your action helper namespace and path within the Bootstrap.php by declaring them in the application.ini instead like so:
resources.frontController.actionHelperPaths.My_Controller_Action_Helper = APPLICATION_PATH "/controllers/helpers"
Simply replace My_Controller_Action_Helper with your desired namespace, and modify the helpers directory path accordingly.
The helper can be initialized the same way:
$this->_helper->myHelper;
As mentioned by the docs, registering the prefix or path of the helpers is usually preferred because helpers would not be initialized until they are called like in the snippet above.
Of course, instantiating and passing helpers to the broker is a bit
time and resource intensive, so two methods exists to automate things
slightly: addPrefix() and addPath().
http://framework.zend.com/manual/1.12/en/zend.loader.pluginloader.html
Adding the config entry to the application.ini follows the same suggested pattern.
I want to use the default XML editor (org.eclipse.wst.xml.ui) of Eclipse in an RCP application. I need to read the DOM of the xml file currently open. The plugin doesn't offer any extension point, so I'm trying to access the internal classes. I am aware that the I should not access the internal classes, but I don't have another option.
My approach is to create a fragment and an extension point to be able to read data from the plugin. I'm trying not to recompile the plugin, that's why I thought that a fragment was necessary. I just want to load it and extract the data at runtime.
So, my question is: is there another way to access the classes of a plugin? if yes, how?
Any tutorial, doc page or useful link for any of the methods is welcome.
Since nobody answered my question and I found the answer after long searches, I will post the answer for others to use if they bump into this problem.
To access a plugin at runtime you must create and extension point and an extension attached to it into the plugin that you are trying to access.
Adding classes to a plugin using a fragment is not recommended if you want to access those classes from outside of the plugin.
So, the best solution for this is to get the plugin source from the CVS Repository and make the modifications directly into the source of the plugin. Add extension points, extensions and the code for functionality.
Tutorials:
Getting the plugin from the CVS Repository:
http://www.eclipse.org/webtools/community/tutorials/DevelopingWTP/DevelopingWTP.html
Creating extensions and extension points and accessing them:
http://www.vogella.de/articles/EclipseExtensionPoint/article.html
http://www.eclipsezone.com/eclipse/forums/t97608.rhtml
I ended up extending XMLMultiPageEditorPart like this:
public class MultiPageEditor extends XMLMultiPageEditorPart implements
IResourceChangeListener {
#Override
public void resourceChanged(IResourceChangeEvent event) {
// TODO Auto-generated method stub
setActivePage(3);
}
public Document getDOM() {
int activePageIndex = getActivePage();
setActivePage(1);
StructuredTextEditor fTextEditor = (StructuredTextEditor) getSelectedPage();
IDocument document = fTextEditor.getDocumentProvider().getDocument(
fTextEditor.getEditorInput());
IStructuredModel model = StructuredModelManager.getModelManager()
.getExistingModelForRead(document);
Document modelDocument = null;
try {
if (model instanceof IDOMModel) {
// cast the structured model to a DOM Model
modelDocument = (Document) (((IDOMModel) model).getDocument());
}
} finally {
if (model != null) {
model.releaseFromRead();
}
}
setActivePage(activePageIndex);
return modelDocument;
}
}
This is not a clean implementation, but it gets the job done.