Is yuidoc #namespace relevant with Ember-CLI? - ember-cli

#namespace
The #namespace should not include the "root" or "global" object that
your entire library hangs off of.
Since we have #module which give the js files container.
can some one give me a simplest example possible? or direct me to some link

#namespace is not useful if we are using ES6
instead modules and sub-modules should be used.

Related

TYPO3 10 Viewhelper class not found, Fluid error

There is some small detail I seem to be missing but I just can't find out what it is...
I get this error:
Error: The ViewHelper "<ugh:example>" could not be resolved. Based on your spelling, the system would load the class "TYPO3\Projectname\ViewHelpers\ExampleViewHelper", however this class does not exist.
I have my own extension called sitepackage, which works without issues.
In my ext_localconf.php I wrote
$GLOBALS['TYPO3_CONF_VARS']['SYS']['fluid']['namespaces']['ugh'] = ['TYPO3\\Projectname\\ViewHelpers'];
Then there's the directory ViewHelpers inside Classes with the file ExampleViewHelper.php
<?php
namespace TYPO3\Projectname\ViewHelpers;
use TYPO3Fluid\Fluid\Core\ViewHelper\AbstractViewHelper;
// etc ...
I expect it to use like <ugh:example />
What am I missing? Is there something outside of this that I have to do?
I'm freaking out about this...
Your global configuration works, yet PHP is not able to find your TYPO3\Projectname\ViewHelpers\ExampleViewHelper.
I suspect that you have a spelling error or your autoloading information is out of date (assuming a composer-based installation, composer dump-autoload updates it) or you forgot to add your namespace to composer.json (see composer docs or a TYPO3 extension example here).
That said, the usual approach is to add ViewHelper namespaces to the Fluid template directly. See https://docs.typo3.org/m/typo3/book-extbasefluid/10.4/en-us/8-Fluid/8-developing-a-custom-viewhelper.html#importing-namespaces
Without composer
Use TYPO3 InstallTool "rebuild autoload information" or similar to build the class autoloading information. I think ext_emconf.php needs to contain the autoloading information, too.

Prestashop 1.7 Create new classes for modules and overrided controllers

I started with prestashop and I have an organizational problem in my code. I created several modules and new tables. I also overrided controllers in the myprestashop/override/ folder in which I want to use my tables, so I have to create new classes. But I don't know where to create classes in prestashop for as much access in my modules as in my overrided controllers.
For now I'm calling my classes create in my modules, in my overridded controllers. Although I know it's not the right solution.
require_once _PS_MODULE_DIR_.'my_module/classes/MyNewClass.php'
Would someone have the answer?
Thank you!!
Well your way is acceptable solution as PrestaShop doesn't have any autoloading capabilities for custom classes.
However what I like to do is use Composer in modules and use its autoloading capabilities for my classes and any libraries that the module might need.
Update
An example of composer usage in myexample module:
Module structure
modules/
myexample/
classes/
mynamespace/
myexample.php
composer.json
myexample.php
require_once __DIR__ . '/vendor/autoload.php';
class MyExample extends Module
{
// module code
}
composer.json
{
"autoload": {
"psr-4": {
"mynamespace\\": "classes/mynamespace"
}
}
}
Run composer install from module folder.
Now you can put classes under mynamespace folder (with proper namespace definition of course) and they get autoloaded anywhere your module is used (module controllers, models, hooks etc).
I noticed that below scheme works too in version 1.7.6, but I would ask experienced developers to point if this is correct approach.
I put my custom class file into /override/classes folder:
namespace CustomNamespace;
class CustomClass {
...
}
then in other places I just use the class:
use \CustomNamespace\CustomClass;
and my CustomClass works as expected

TYPO3 Hook not found

I am currently trying to write a Hook to add extra fields to a Flexform. Therefore I followed this tutorial: https://docs.typo3.org/typo3cms/extensions/news/DeveloperManual/ExtendNews/ExtendFlexforms/Index.html?fref=gc&dti=250938618364487#extend-flexforms-with-custom-fields
But when I go to a page in the backend that contains an options from a Flexform I get the following Error:
Class 'ID\SearchBarAdditional\Hooks\FlexFormHook' not found.
I register the Hook in the ext_localconf like this:
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][\TYPO3\CMS\Core\Configuration\FlexForm\FlexFormTools::class]['flexParsing'][] = \ID\SearchBarAdditional\Hooks\FlexFormHook::class;
and my Hook-file is here: typo3conf/ext/search_bar_additional/Classes/Hooks
and is initialized that way:
namespace ID\SearchBarAdditional\Hooks;
class FlexFormHook { /* ... */
So in my opinion everything is in the right place and should work, but I do still get the error that TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance("ID\SearchBarAdditional\Hooks\FlexFormHook") fails.
Do you guys have any ideas, what could be wrong? Do I have to register the Hook in \TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin( or something similar (as the posted code is really the only thing I've done)?
This is a typical class loading error. Check that you added your PHP namespaces to composer autoloading and/or ext_emconf.php and make sure your filenames are correctly named according to PSR-4. If in doubt you can inspect the class loading map files generated by composer in vendor/composer (if you use composer for class loading, which you definitely should do).
I found the mistake: My Hook does indeed not get loaded. I tried to 'include' it in the ext_localconf.php and it is working now.
But as this is of course an extremely ugly solution I posted a second question, how to load a hook here: Typo3 8.X - autoload Hook
Thank you for your help!!!

Ember-cli non ember function

I already worked with emberjs before it used ember-cli but now I am not sure how I can do that.
I need to create some functions to manage my cookies and some other thing, but I don't know where I should put them in the project so they will be available from anywhere (controller, routes, views...). I looked at the emberjs guide/doc but I can't find anything relevant about that unfortunatelly..
Is there is a specific place I can put my functions ? or I have to copy/paste them everywhere ?
Should I put my scripts inside the vendor folder ?
Thanks.
You can place it in a util script. To create one, type in ember generate util foo
Take note that it uses ES6 syntax with the export default and stuff.
Once you have the util script you can import it in your controller, route, etc.

Zend Framework: Can you do ACL without the plugins directory?

I am having trouble understanding the rules to ACL in ZF and the docs aren't clear. I am using a common Zend library for all websites. So far no problem but now every demo or example says that you should place the ACL class (acl.php) in the libraries directory as a plugin. Zend/Library/My/Controller/Plugin/.
I don't want to do this because it defeats the purpose for sharing a common framework directory.
Has anyone done or have any ideas about how to accomplish ACL using individual acl.php class files for each website/web application?
Thanks
You don't have to place the acl.php in the libraries directory as a plugin. The autoloader will load the class just fine, the trick to Zend_Acl is just priming an instance of the class with your roles and resources.
It's been a little while since I touched Zend Framwork but I'll try to steer you in the right direction.
In your bootstrap, create the Zend_Acl object
$acl = new Zend_Acl();
//see documentation on how to add roles and resources
Now create a Plugin folder inside your Controller directory, this will allow you authenticate with your acl.
Inside there create new class that extends Zend_Controller_Plugin_Abstract give it the correct class name to be picked up by the autoloader.
Store the acl you create in the registry and in your plugin override the preDispatch method, from here you have access to the request and the acl (from the zend registry) you can validate as needed. (Some people have controller/action as resources others models. It's quite freeform.
Register your plugin with the front controller.
$frontController->registerPlugin(new My_Controller_Plugin_Acl());
This is probably what the other tutorials are suggesting (or variants of this), it can just be a little confusing sometimes.
You should never add files to your Zend library directory - do you have any links to tutorials recommending this? The files should either go in the library directory under your application's namespace, giving you a structure like:
application/
library/
Zend/
(ZF files)
Foo/
Controller/
Plugin/
...
or in application/plugins, application/controller/helpers or somewhere else depending on the approach you are taking.
Edit: it sounds like a controller plugin is what the tutorial is recommending, in which case you'll want a class like Yourapp_Plugin_Acl (replace 'Yourapp' with your app's namespace) which would live at application/plugins/Acl.php.
Ultimately, you can place it anywhere you want as long as your autoloader is sufficiently configured to find it. And precisely how you use it depends upon what resources and privileges you are trying to protect.
But think you are confusing instantiating your ACL and querying your ACL.
You will most likely instantiate/populate your ACL object during bootstrap and store it in the Bootstrap registry or in the Zend_Registry singleton.
If your resources are controllers and your privileges are actions, then it is common to intercept the dispatch cycle with a preDispatch() plugin that queries your ACL object.
So, we are really looking at two different classes/objects:
One is the ACL itself, extending Zend_Acl. This one could be named Application_Model_Acl and placed in the file application/models/Acl.php.
The other is the front controller plugin. This one could be named Application_Plugin_Acl and stored in the file application/plugins/Acl.php
[Note that both of these presume that we are using an application namespace Application. Also, note that both of these are project-specific.]
Of course, the plugin as described needs to be given the ACL object in order to do its job, so your Bootstrap might have a method like this:
protected _initAclPlugin()
{
$acl = new Application_Model_Acl();
$plugin = new Application_Plugin_Acl($acl);
Zend_Controller_Front::getInstance()->registerPlugin($plugin);
}
But remember, this is only one way to use your ACL. In some cases, your ACL might not be limited to just controllers/actions. In that case, you might need to pass your ACL object to other models/services that query it, as well. In that case, you might have a separate method in your Bootstrap to create your ACL object and store it in the Bootstrap registry. Then your controllers - or even a dependency injection system - can grab it from there and pass it through to whatever downstream models/services might need it.
[You know, looking at my answer, it's not really different from that of #linead. Same idea, different words, but he totally got in first.]