I am wondering how to automatically include helper into to the all models files of the component, that i only need to create object from helpers class in models files?
Avoid using require_once, and use the proper Joomla methods for including helper classes
JLoader::register('ClassName', 'path_to_class');
Put this snippet in the beginning of your component entry controller. Joomla will then autmotically load the class only when it's needed.
By using the regular PHP require_once you will slow down your code, since the file will instantly be loaded into memory, even if it's not needed.
Related
I'd like to customize the style (font, colors, logo, etc) of drf_yasg generated docs.
I see that I can extend drf_yasg/swagger-ui.html with the blocks extra_head, extra_styles, extra_body, extra_scripts, and can even overwrite the other blocks if I need to.
What I am not clear on is how I point to my template that extends swagger-ui.html.
I started with
class MyCustomSwaggerUIRenderer(SwaggerUIRenderer):
template = 'api/custom-swagger-ui.html'
I want to replace SwaggerUIRenderer with MyCustomSwaggerUIRenderer in get_schema_view but do not understand how/where to do it without explicitly trying to enumerate all the other Renderers required too in some subclass of rest_framework.views.APIView and that seems convoluted.
Pointers to docs or examples are appreciated. I've already read https://drf-yasg.readthedocs.io/ without success.
You don't have to create a custom class for this. You just need to create a directory with the name drf-yasg under new or existing app and then place a file with the name swagger-ui.html underneath it with your custom template. For example, if you already have an app with the name api, you can just put it under api/templates/drf-yasg/swagger-ui.html. Make sure the app api is specified before drf-yasg in INSTALLED_APPS.
Reference: https://github.com/axnsan12/drf-yasg/issues/294#issuecomment-464461773
Let's assume we have a very large codebase and want to namespace a group of functionally-related code under a folder structure. Say we have a bunch of files related to Admin so we create an app/models/admin folder and place files like admin.rb and admin_accounts.rb under the models/admin folder.
Questions:
1. Do these classes now need to be wrapped in an admin module or does Rails do this for us automatically?
2. When creating a new admin, is there a way for us to not have to call it like Admin::Admin.rb or Admin::AdminAccount.new. The call sites range in the 100s. Do we have to change each call site to reference the wrapping module now? Or is there a way around this with the autoload feature?
In short, what's best practice? Do we now need to wrap the classes in a module? IF so, does that mean we now need to preface Admin.new and AdminAccount with the module? Is this necessary?
I have just started to create Haxe externs (strictly typed class definitions)
based on the yuidoc output from the ember source.
Now I need help to understand how to implement the kind of mixing architecture special to Ember.
For example the Ember.Object extends the Ember.CoreObject - however I wasn't able to locate any constructor inside the latter - is there any direct call to new Something() in Ember at all?
Then Ember.Object uses Ember.Observable which in turn imports cacheFor from the ember-metal / lib / computed.js module - is this relation reflected inside the data.json output of yuidoc or will I need to parse the sources directly in order to collect all methods into my class definitions?
is there any direct call to new Something() in Ember at all?
For the most part, no. You're supposed to call Class.create() not new Class().
is this relation reflected inside the data.json output of yuidoc or will I need to parse the sources directly in order to collect all methods into my class definitions?
The data.json file should contain most of the documentation written. The problem you'll experience is that not everything is documented (mostly private API).
Where can I find the Container Class API docs?
In the source code.
I have a bunch of functions that I created in some views that must be reused in many other views. Do I need to create a class and put those functions in a class? If yes how exactly has to be done in Django and then how do I call and initiate them in the new views?
Django views are just Python functions. You can call other Python functions from them just as you can from any other Python code. Put your functions into a .py file, import it, and invoke the functions.
Of course, it may make sense for other reasons to create a class to hold the functions, but you certainly don't need to in order to call them from views.
The solution would be to create the myfunctions.py file in your app folder and import it in your views. Your views file would look like:
import myfunctions
def my_view(request):
.....
foo = myfunctions.bar()
....
You look to complicated to Django. Django is just another Python application and lives in the Python world. For example you can create file library.py and import this file where is needed (in modules where the function from library is needed). If you need you library's functions to get data from database, just import models in the library.py and use them.
Django doesn't have such a big think as "module". You creating the architecture, you can define what in your case is module. In general this is just simple directory with init.py file inside to be able to import files from there.
Hope that helped.
From my point of view, if you have a lot of functions that are widely used in your project it make sense put all this in some separate application. I create some module named 'contrib' for this purposes. It can avoid some time for maintaining this code in future
I am working on a Django app and I have a class which reads the contents of a file and returns a Django model. My question is where do I store this class in the file system? All this does is reads the file, populates a Django model and returns it.
Thanks
There is nothing special about a Django application: it's just a Python package. Technically you can put the class anywhere you can import.
With that being said, it's best to keep related code bundled together. It sounds like a good place for this particular class is in the file that declares the Model it returns.
On the other hand it might be logical to throw it into the application's __init__.py file.
You could also make a utils, etc, admin, scripts . . . folder/package to put utility classes and scripts if it's meant to be used for administration and site maintenance.
In the end it's more about how you want to organize your project, but technically it can live just about anywhere.