how can I use the controllers created at
/administrator/components/com_mycom/controllers/*
in
/components/com_mycom/mycom.php
In detail:
I have a »log« controller with an »add« method, and I would like to use this from the frontend. I one is not logged in in the backend the task is not executed and a 500 error rises. So just would like to include the backend controllerpath in the frontend, so that JController::getInstance( 'Mycom' ) still works.
Greetings…
EDIT:
After a long time of searching I could find a more or less undocumented Parameter of the:
JController::getInstance() method, namely the second one: $config = array(). Going through the source code I found out that there is one key of the »config-array« that is of interest, which is: »base_path«.
The call of:
JController:getInstance( 'Mycom, array('base_path' =>JPATH_ADMINISTRATOR.DS.'components'.DS.'com_mycom')' );
always delivers the backend controller and one can use them safely in the frontend, BUT one must take care that then also the views are taken from the backend side of the component. In my case, I just use it to make ajax-calls so it does not matter, but one needs to be careful with using this method when planning to create »frontend views« with »backend controller«.
Greetings…
I had recently a similar problem where I wanted to use the whole CRUD system form back-end also in front-end.
This is the method that worked for me (and I am not saying that this is recommended or best practice):
I've just modeled the folders / file structure from backend. PHP files contained something like:
require_once JPATH_ADMINISTRATOR . '/components/com_mycom/controllers/log.php';
Related
I need to change short month in moment.
But I can't do it.
I have try to set
localeOutputPath: 'assets/moment-locales'
And call
Ember.$.getScript('/assets/moment-locales/ru.js');
In this case i have ember-mirage error
Your Ember app tried to GET '/assets/moment-locales/ru.js?_=1490191145335',
but there was no route defined to handle this request. Define a route that
matches this path in your mirage/config.js file
Is it simple way to set short months name for moment?
I assume you are using ember-moment addon; and already have configured config/environment.js with
moment: {
// This will output _all_ locale scripts to assets/moment-locales
localeOutputPath: 'assets/moment-locales'
},
as you have mentioned.
Ember.$.getScript('/assets/moment-locales/ru.js');
provides a way to dynamically load moment ru locale on the fly when needed. This means instead of including the related locale to your application's javascript file you prefer to load relevant locale upon some user request in your application. Generally it is best to perform such loading operation within a router's hook methods such as beforeModel or model.
In order to get short month names from moment; you need to first import ES6 moment module via
import moment from 'moment';
and access the short month names with
moment.monthsShort()
As far as I can see; there is a problem with the way you are requesting the locale so you are getting the error you have mentioned. I believe a working code is a better explanation from pure text; hence I have created the following git repository to illustrate how you can change the locale dynamically in a route and how you can display short names retrieved from moment. Please take a look at it by cloning and running in your localhost.
In the application at this repository, application.hbs contains links to 5 sub-routes; each displaying short names of months in different languages. The code that does the trick of dynamically loading the relevant locale is in routes/locale-route.js file's model hook method. If locale is already loaded (note that English is included by default with moment) it simply returns the short names of the months via switching to target locale (moment.locale(localeToLoad);). Otherwise, it performs a remote call to the server and waits for the response (by using a promise) to return the name of months. All routes for 5 different languages extend from this base route. Once, a locale is loaded from the server; you no longer need to load it again once more and the locale-route already handles it as I explained. I hope that helps.
After reading your comment; I updated the source code to include ember-cli-mirage. Mirage is a client-side mock server to develop, test and prototype your application. Once you include it as a dependency it starts intercepting your remote call requests. Hence, in your case mirage intercepts requests for demanding related locale. What you need to do is passing through mirage for locales. In order to do that, you need to add following
this.passthrough('/assets/moment-locales/**');
to mirage/config.js so that mirage will not interfere with demanding moment-locales at the runtime. Please see related file under the git repository I have provided. This will solve your problem for sure.
Creating in-repo-addon in Ember.JS gives a lot of possibilities. Today I've stumbled into a case when I wanted to register all classes in directory (for example my-dir) into Dependency Injector (same way it's done with services by Ember, but I wanted to use some other namespace).
For example I want to allow developer to create multiple classes inside proxy directory, and register all of them in DI under proxy: namespace. So later we can use:
Ember.Component.extend({
myProxy: Ember.inject('proxy:my'),
});
You'll need to do this using an initializer. More details on this here: https://guides.emberjs.com/v2.12.0/applications/dependency-injection/
The hard part may be getting all proxy items in s folder to automatically register ...
Edit
Looks like I didn't spend enough time thinking about this. You should be able to do at least part of this easily. There are two parts to this.
Part 1
Ember currently uses the ember-resolver to handle lookups for various items. If you check the tests for the resolver you'll notice that you should be able to map in anything you want: https://github.com/ember-cli/ember-resolver/blob/master/tests/unit/resolvers/classic/basic-test.js
So in your case, if you do a Ember.getOwner(this).lookup('proxy:main') from within an Ember instantiated class (a route, controller or component for instance) it would look in app/proxy/main.js which your addon could be populating.
Details on the Ember.getOwner lookup are available here: https://emberjs.com/api/classes/Ember.html#method_getOwner
Part 2
So at this point you can lookup proxies (which would be doable in an init method). But if we want to get truly elegant we'd want to allow Ember.inject.proxy('main') syntax.
Doing so would involve calling a private method inside of Ember.inject in an initializer. Because that naming scheme is changing in the new Javascript modules RFC, it may be unwise to try to add this syntactic sugar ...
So I'd advise avoiding touching that private API unless it's really important to your app design.
When using sinatra-r18n to handle internationalisation, the r18n lib exposes a variable t for use within your helpers, routes and templates, as per these instructions.
I have written a simple unit test using rack-unit to confirm that some of my pluralisations work but the test throws an error claiming t is nil.
I've tried referencing it via app.t, MySillyApp.t (where MySillyApp is the name of my Sinatra app), MySillyApp.settings.t etc and none of them give me access to the t I need.
What I am trying to achieve is a confirmation that my translation files include all the keys I need corresponding to plurals of various metric units my app needs to understand. Perhaps there is a more direct way of testing this without going via the Sinatra app itself. I'd welcome any insight here.
I had similar task to check localized strings in my Cucumber scenarios.
I've made working example.
Here you can find how strings got translated.
This file halps to understand how to add R18n support to your testing framework:
require 'r18n-core'
...
class SinCucR18nWorld
...
include R18n::Helpers
end
As you can see instead of rack/unit I'm using RSpec/Cucumber, sorry.
In our company we make news portals for a pretty big number of local newspapers (currently 13, going to 30 next month and more in the future), each with 2k to 100k page views/day. Since we are evolving from a situation where each site was heavily customized to one where each difference is a matter of configuration or custom template, our software is already pretty much the same for all sites. Right now our deployment strategy is one gunicorn instance for each site (with 1-17 workers each, depending on the site traffic), on a 16-core server and 12GB RAM. The problem with this setup is that each worker (regular pre-forked gunicorn) takes 110MB, whether its being used or not. Now with the new sites we would need to add more RAM to serve not that much many requests, so basically it doesn't scale. Also, since we are moving from this model where each site is independent, each site has its own database and I quite like it that way, especially since we are using relational databases (mysql, but migrating to pgsql), so its much easier to shard this way.
I'm doing some research and experimenting with running all sites on one gunicorn instance, so I could use the servers fully and add more servers behind a load balancer when it came to it. The problem is that django assumes in a lot of places that only one site is running per process, so for what I've thought of so far I'd have to implement:
A middleware that takes the HTTP_HOST from the request and places an identifier on a threadlocal variable.
A template loader that uses that variable to load custom templates accordingly.
Monkey patch django.db.model.Model, probably adding a metaclass (not even sure that's possible, but I think I would need it because of the custom managers we sometimes need to use) that would overwrite the managers for one that would first call db_manager(identifier) on the original manager and then call the intended method. I would also need to overwrite the save and delete methods to always include the using=identifier parameter.
I guess I would need to stop using inclusion_tag decorators, not a big problem, but I need to think of other cases like this.
Heavy and ugly patching of urlresolvers if I need custom or extra urls for each site. I don't need them now, but probably will at some point.
And this is just is what I came up with without even implementing it and seeing where it breaks, I'm sure I'd need many more changes for it to work. So I really don't want to do it, especially with the extra maintenance effort I'll need, but I don't see any alternatives and would love to learn that someone already solved this in a better way. Of course I could also stop using django altogether (I already have many reasons to do so) but that would mean a major rewrite and having two maintain two incompatible branches of the software until the new one reached feature parity with the django version, so to me it seems even worse than all the ugly hacks.
I've recently developed an e-commerce system with similar requirements -- many instances running from the same project sharing almost everything. The previous version of the system was a bunch of independent installations (~30) so it was pretty unmaintainable. I'm sure the requirements still differ from yours (for example, all instances shared the same models in my case), but it still might be useful to share my experience.
You are right that Django doesn't help with scenarios like this out of the box, but it's actually surprisingly easy to work it around. Here is a brief description of what I did.
I could see a synergy between what I wanted to achieve and django.contrib.sites. Also because many third-party Django apps out there know how to work with it and use it, for example, to generate absolute URLs to the current site. The major problem with sites is that it wants you to specify the current site id in settings.SITE_ID, which a very naive approach to the multi host problem. What one naturally wants, and what you also mention, is to determine the current site from the Host request header. To fix this problem, I borrowed the hook idea from django-multisite: https://github.com/shestera/django-multisite/blob/master/multisite/threadlocals.py#L19
Next I created an app encapsulating all the functionality related to the multi host aspect of my project. In my case the app was called stores and among other things it featured two important classes: stores.middleware.StoreMiddleware and stores.models.Store.
The model class is a subclass of django.contrib.sites.models.Site. The good thing about subclassing Site is that you can pass a Store to any function where a Site is expected. So you are effectively still just using the old, well documented and tested sites framework. To the Store class I added all the fields needed to configure all the different stores. So it's got fields like urlconf, theme, robots_txt and whatnot.
The middleware class' function was to match the Host header with the corresponding Store instance in the database. Once the matching Store was retrieved, It would patch the SITE_ID in a way similar to https://github.com/shestera/django-multisite/blob/master/multisite/middleware.py. Also, it looked at the store's urlconf and if it was not None, it would set request.urlconf to apply its special URL requirements. After that, the current Store instance was stored in request.store. This has proven to be incredibly useful, because I was able to do things like this in my views:
def homepage(request):
featured = Product.objects.filter(featured=True, store=request.store)
...
request.store became a natural additional dimension of the request object throughout the project for me.
Another thing that was defined on the Store class was a function get_absolute_url whose implementation looked roughly like this:
def get_absolute_url(self, to='/'):
"""
Return an absolute url to this `Store` or to `to` on this store.
The URL includes http:// and the domain name of the store.
`to` can be an object with `get_absolute_url()` or an absolute path as string.
"""
if isinstance(to, basestring):
path = to
elif hasattr(to, 'get_absolute_url'):
path = to.get_absolute_url()
else:
raise ValueError(
'Invalid argument (need a string or an object with get_absolute_url): %s' % to
)
url = 'http://%s%s%s' % (
self.domain,
# This setting allowed for a sane development environment
# where I just set it to ".dev:8000" and configured `dnsmasq`.
# The same value was also removed from the `Host` value in the middleware
# before looking up the `Store` in database.
settings.DOMAIN_SUFFIX,
path
)
return url
So I could easily generate URLs to objects on other than the current store, e.g.:
# Redirect to `product` on `store`.
redirect(store.get_absolute_url(product))
This was basically all I needed to be able to implement a system allowing users to create a new e-shop living on its own domain via the Django admin.
In the beginning we made a project using CodeIgniter and we had some controllers that were used to connect an external NAS to the database via it's web interface, to cut a long story short we had a bunch of URL that required an API key to have access to avoid general hackery from outside sources calling the API.
The API existed for various tasks the NAS had to do (manage orders, upload data/images etc.), so we had a few different controllers (ie. one for Orders, Images, etc.) So the API folder looked something like this:
controllers/apiv1/
orders.php
images.php
...
Something along the lines of this:
class Orders extends ApiController {
function Orders()
{
parent::ApiController();
}
function get_paid()
{
$shop = self::get_shop();
$this->load->model('order');
echo json_encode($this->order->by_status($shop->shop_id, Order::STATUS_PAID));
}
}
Where the ApiController just checked the APIKey against the Shop that it was trying to access.
Now we are moving the project to Django, and I was just wondering the be way to setup this api again. I was thinking of making an API app for the project and importing the models in to the views.py and make some functions for everything, my problem here is there a way to break everything up nicely (into separate files for each of the various things)? Or should I just have the views.py full of everything and worry about it in the urls.
Or is there a better way? If possible I would like to separate the api into versions like (api/v1, api/v2, etc.) so that we can just route the urls to the new api without affecting the old. This may come in handy if we have various NAS's using different versions of the API (Hard to explain why...)
You could try using something like Django Piston or Django-tastypie to quickly get something working. The big advantage over using normal Django views is that you get most of the CRUD and serialization to JSON/Yaml/XML done for you.
Tastypie comes with a built-in shared-secret key authentication mechanism, and it's not difficult to find the equivalent code for Piston.
EDIT: BTW, I've been working with both Piston and Tastypie recently. I find Tastypie is easier to setup and the code base looks cleaner. That said, it lacks some features (coming on 1.0 though) that makes it impossible for me to use it at the moment. Piston is very easy to shoehorn into whatever you need, but the code seems to be growing stagnant, the author doesn't seem to be very responsive about open issues and you'll probably end up having your own fork with the bugfixes you need for your application to work properly. Not an ideal situation.