Get RESTAdapter host - ember-data

RESTAdapter has the possibility to specify a url for the backend:
DS.RESTAdapter.reopen({
url: 'https://api.example.com'
});
How can I access this property programmatically? I mean something like: DS.RESTAdapter.get('url') <-This doesn't work

You're setting the properties on the class not the instance, thats why you can't retrieve the values. There are two possible solutions.
You can get the values from the prototype
DS.RESTAdapter.prototype.url
or you can instantiate the class and get it from there
DS.RESTAdapter.create().url

Quick and dirty ...
NOTE: Please use only for debugging, this API is intern and will cenrtainly change in the future, so don't rely on it.
Assuming you have only one Store in your application:
App.__container__.lookup('store:main').get('adapter.url')
If you are using Chrome Dev Tools you can try to call this from the console, it should print out the url used by the default adapter used by the default Store.
But it's discouraged to be used for other then for debugging.
Hope it helps

Or
DS.defaultStore.adapter.url

Related

Mixin with access-functionality in vue

I have a working VueJs application, and when a user logs in, he gets some rights from the server like administrator, readOnlyUser, worker etc. Based on these privileges, some components/functionality in the application should be or, should not be available to the user. For an example I would like to put a reference to an access-right method on my differenct components/divs:
<MyComponent v-if="hasRights()"></MyComponent>
Or just access this method from the script section.
I am thinking of using mixins, this seem to suit my needs, but is mixin´s the right way to solve this issue? Are there another more patten-like correct way to do it?
My recommendation for architecture:
Create files per rights:
Admin.js
User1.js
User2.js
etc.
Now you can create a function (wherever that takes in the user from your server, and then referes you to the right file. By doing this you can call in . your components: this.$config.get().displaySomething . Where the get() knows which file to go to. Make your config available on bootstrap.
The reason I don't recommend vuex is since it sounds like your config is static and can just be hard coded into file.

Yii load system params from Database using Active Record

I am interested in loading some system params into the Yii::app()->params array from the database using a CActiveRecord extension called SiteSetting.
Unfortunately I couldn't find much advice online for this, but believe I can place a method in SiteSetting called loadSiteSettingsToAppParams and add the setting...
'onBeginRequest'=>array('SiteSetting', 'loadSiteSettingsToAppParams')
...to the config.
I would like to know if I can only add this onBeginRequest to the Yii::app() somewhere within the SiteSetting class (to keep my code modular) and whether this is a sensible approach.
Thanks in advance.
Just re-read your question now and I'd try to provide answers.
To the question "I would like to know if I can only add this onBeginRequest to the Yii::app() somewhere within the SiteSetting class (to keep my code modular)": the answer is, You're not restricted to just a Class. You could (theoretically) place it anywhere within your application and also in the config.php file.
As to whether it's a sensible approach, it depends on the time it would take to request those settings from the database and whether you're prepared to add that time to your HttpRequest response time. The onBeforeRequest is fired before every HttpRequest and if the loadSiteSettingsToAppParams method consumes lots of time, you're adding that time to your HttpRequest response time.
I'd advise that you fetch those settings once after login and then update them only when they change (the settings are updated). This way, you could place the call to loadSiteSettingsToAppParams in the UserIdentity class and call it after a successful login.
That's just how I'd go about doing this though.
Hope I helped.
The easy & nice way to accomplish this by using a comoponent like SettingComoponent and place in the components directory protected/components then pre load this component in the preload section like this preload => array('log', 'setting', ...). That's it and now you can call this component anywhere you want like Yii:app()->setting->whatever.
I hope this is answer can be useful for you.

#ValidateConnection method is failing to be called when using "#Category component"

I have an issue in a new devkit Project where the following #ValidateConnection method is failing to be called (but my #processor methods are called fine when requested in the flows)
#ValidateConnection
public boolean isConnected() {
return isConnected;
}
I thought that the above should be called to check whether to call the #Connect method.
I think it is because I am using a non default category (Components) for the connector
#Category(name = "org.mule.tooling.category.core", description = "Components")
And the resulting Behavoir is different to what I am used to with DevKit in Cloud connector mode.
I guess I will need to do checks in each #processor for now to see if the initialization logic is done, as there doesn't seem to be an easy way to run a one time config.
EDIT_________________
I actually tried porting it back to a cloud connector #cat and the same behaviour, maybe its an issue with devkit -DarchetypeVersion=3.4.0, I used 3.2.x somthing before and things worked a bit better
The #ValidateConnection annotated method in the #Connector is called at the end of the makeObject() method of the generated *ConnectionFactory class. If you look for references of who is calling your isConnected() you should be able to confirm this.
So no, you should not need to perform the checks, it should be done automatically for you.
There must be something else missing... do you have a #ConnectionIdentifier annotated method?
PS. #Category annotation is purely for cosmetic purposes in Studio.

Why is Mage_Persistent breaking /api/wsdl?soap

I get the following error within Magento CE 1.6.1.0
Warning: session_start() [<a href='function.session-start'>function.session-start</a>]: Cannot send session cookie - headers already sent by (output started at /home/dev/env/var/www/user/dev/wdcastaging/lib/Zend/Controller/Response/Abstract.php:586) in /home/dev/env/var/www/user/dev/wdcastaging/app/code/core/Mage/Core/Model/Session/Abstract/Varien.php on line 119
when accessing /api/soap/?wsdl
Apparently, a session_start() is being attempted after the entire contents of the WSDL file have already been output, resulting in the error.
Why is magento attempting to start a session after outputting all the datums? I'm glad you asked. So it looks like controller_front_send_response_after is being hooked by Mage_Persistent in order to call synchronizePersistentInfo(), which in turn ends up getting that session_start() to fire.
The interesting thing is that this wasn't always happening, initially the WSDL loaded just fine for me, initially I racked my brains to try and see what customization may have been made to our install to cause this, but the tracing I've done seems to indicate that this is all happening entirely inside of core.
We have also experienced a tiny bit of (completely unrelated) strangeness with Mage_Persistent which makes me a little more willing to throw my hands up at this point and SO it.
I've done a bit of searching on SO and have found some questions related to the whole "headers already sent" thing in general, but not this specific case.
Any thoughts?
Oh, and the temporary workaround I have in place is simply disabling Mage_Persistent via the persistent/options/enable config data. I also did a little bit of digging as to whether it might be possible to observe an event in order to disable this module only for the WSDL controller (since that seems to be the only one having problems), but it looks like that module relies exclusively on this config flag to determine it's enabled status.
UPDATE: Bug has been reported: http://www.magentocommerce.com/bug-tracking/issue?issue=13370
I'd report this is a bug to the Magento team. The Magento API controllers all route through standard Magento action controller objects, and all these objects inherit from the Mage_Api_Controller_Action class. This class has a preDispatch method
class Mage_Api_Controller_Action extends Mage_Core_Controller_Front_Action
{
public function preDispatch()
{
$this->getLayout()->setArea('adminhtml');
Mage::app()->setCurrentStore('admin');
$this->setFlag('', self::FLAG_NO_START_SESSION, 1); // Do not start standart session
parent::preDispatch();
return $this;
}
//...
}
which includes setting a flag to ensure normal session handling doesn't start for API methods.
$this->setFlag('', self::FLAG_NO_START_SESSION, 1);
So, it sounds like there's code in synchronizePersistentInf that assumes the existence of a session object, and when it uses it the session is initialized, resulting in the error you've seen. Normally, this isn't a problem as every other controller has initialized a session at this point, but the API controllers explicitly turns it off.
As far as fixes go, your best bet (and probably the quick answer you'll get from Magento support) will be to disable the persistant cart feature for the default configuration setting, but then enable it for specific stores that need it. This will let carts
Coming up with a fix on your own is going to be uncharted territory, and I can't think of a way to do it that isn't terribly hacky/unstable. The most straight forward way would be a class rewrite on the synchronizePersistentInf that calls it's parent method unless you've detected this is an API request.
This answer is not meant to replace the existing answer. But I wanted to drop some code in here in case someone runs into this issue, and comments don't really allow for code formatting.
I went with a simple local code pool override of Mage_Persistent_Model_Observer_Session to exit out of the function for any URL routes that are within /api/*
Not expecting this fix to need to be very long-lived or upgrade-friendly, b/c I'm expecting them to fix this in the next release or so.
public function synchronizePersistentInfo(Varien_Event_Observer $observer)
{
...
if ($request->getRouteName() == 'api') {
return;
}
...
}

Is it possible to override the HTTP functions in wxHtmlWindow?

I would like wxHtmlWindow to use libcurl instead of the internal wxHTTP class.
Is there an easy way to do this? If not, can I at least change the useragent wxHtmlWindow sends when it accesses pages?
I would create a class that manage my curl session. Setting a user agent, cookies, server to connect to etc.
Also I would make that class to be able to save the page I get from the internet to a file temp/web.htm
and then I would use something like:
htmlwin->LoadPage("temp/web.htm");
Where htmlwin is a wxHtmlWindow
This is the first thing that comes in my mind, maybe I can think to a better solution.
EDIT 1:
See this link so see a little example of wrapping curl in a C++ class