Recently I came across someone's code. The Alloy Markup is empty with just <Alloy />. In its controller, it adds a view using $.addTopLevelView().
How come I can't find any documentation regarding this function?
Good point. It might be because it's considered private, although it would normally start with _ to indicate that since JS doesn't actually support private methods.
It is also against the very idea of Alloy to not use the XML file for the markup but instead use "classic" Titanium code in the controller together with this method.
However, it might be a good idea to do a PR against the following file to request this to be documented:
https://github.com/appcelerator/alloy/edit/master/Alloy/lib/alloy/controllers/BaseController.js
Related
I am migrating a project from Richfaces to Primefaces and I am having problems getting file download to work again. The original uses a standard h:commandLink which tells the webflow to start the download by calling a function on the controller. The actual downloading is written to the output stream instead of being returned as a file.
Now my problem is the previous code sends a FilterServletResponseWrapper, but after changing the rich tags to prime, it now returns HttpSessionSecurityContextRepository$SaveToSessionResponseWrapper. These wrappers are not specified anywhere and I suspect rich sends such a type internally. So if I want to specify my own wrapper to send, how could I possibly go about that? In particular I want to use Spring's ContentCachingResponseWrapper since I need to use it's .getContentInputStream() method.
P.S. I have intentionally omitted the code, because of NDA, I am hoping this is enough information to represent the problem sufficiently. If not I will be glad to clear out any questions.
Thanks
I am implementing a Wagtail powered blog within a larger (primarily DRF) driven app. I'm attempting to use drf-yasg for my documentation.
Since installing wagtail, the docs are now throwing
'Request' object has no attribute 'wagtailapi_router'
It looks to be related to the introspection that drf-yasg does, and all I can find about excluding views from drf-yasg is done at the code level. Being an installed module obviously I want to avoid that.
Has anyone got these 2 (3) components playing nicely together?
It's been a very long time since you asked this question, but as I found this while looking for an answer myself, I thought I might share what worked for me.
Note that I'm not using drf-yasg, but rather DRF's own schema generator. They do however have a lot in common.
The problem in my case was that the schema generator URL was defined like this:
path(
"schema/",
get_schema_view(title="My API Schema"),
name="openapi-schema",
),
What I needed to add was a patterns= argument that referenced my API specifically, leaving out the other non-API urls (like Wagtail):
path(
"v3/schema/",
get_schema_view(title="My API Schema", patterns=router.urls),
name="openapi-schema",
),
I hope that helps... someone :-D
We decided to give it a spin and we started fresh project using Angular2. So far so good, but at this point we're facing an issue. At this point, what is the proper approach to i18n for Angular2? We've researched a little and found this:
https://github.com/angular/i18n
However last commit is more than 5 months old... Doesn't look like active development.
Anyone tried using angular-translate or angular-gettext? Or maybe with Angular2 it's better to wrap something JS like i18next? Anyone could share their thoughts? Maybe you faced the same problem?
Plunk was updated to Angular 2 Final: https://plnkr.co/edit/4euRQQ. Things seem to work the same as in RC7.
New i18n section has been added to Angular 2 official docs. Basically, it explains in details what happens in the plunkr above.
XLIFF is the only format for translations, no json support.
A translation source file (xliff, xlf) should be created using ng-xi18n tool:
package.json:
"scripts": {
"i18n": "ng-xi18n",
...
}
and
npm run i18n
See the Merge translation section for details about merging a translation into a component template. It's done using SystemJS Text plug-in.
Another example using Gulp http://www.savethecode.com/angular2-i18n-native-support/
Older staff:
Update based on RC7 and links provided by Herman Fransen:
I've made a minimal Plunkr example: https://plnkr.co/edit/4W3LqZYAJWdHjb4Q5EbM
Comments to plunkr:
bootstrap should provide TRANSLATIONS, TRANSLATIONS_FORMAT, LOCALE_ID with values -> setup translations
translatable items in html-templates should use directive i18n
translations are stored in .xlf file. Ties between languages is done through Id, ties with html by a value of <source> tag in xlf
currently xlf files are not used directly; a .ts file is manually created to wrap the content of xlf in an exportable variable. I guess, this should be working automagically in final release (maybe even now).
This is the first officially documented approach I found.
However, it's still barely usable. I see the following issues in the current implementation:
Language is set at bootstrap, unable to change it in run-time. This should be changed in Final.
Id of a translatable item in xlf is generated SHA. Current way to get this id is a bit messy: you create a new translatable item, use it, copy SHA id from error and paste into your i18n.lang.xlf file.
There is a big documentation pull request concerning i18n
Older staff:
Release notes https://github.com/angular/angular/blob/master/CHANGELOG.md have a record
i18n: merge translations 7a8ef1e
A big chunk of i18n was introduced in Angular 2 RC5
Unfortunately, still no documentation available.
Everyone's eager for the official implementation, but this one worked for my use case:
https://github.com/ocombe/ng2-translate
README is fairly thorough, and if you need something real particular (for me it was code-splitting) the code itself isn't too long or hard to read.
Support for i18n is now official in Angular 2 RC6
Official release blog:
https://angularjs.blogspot.nl/2016/09/angular-2-rc6_1.html
A sample of internationalization with Angular 2 RC6
https://github.com/StephenFluin/i18n-sample
More info how the new concept of i18n works in angular2:
https://lingohub.com/blog/2015/03/angular-2-i18n-update-ng-conf-2015
I found another way to implement this using pipe and service
HTML
<!-- should display 'hola mundo' when translate to Spanish -->
<p>{{ 'hello world' | translate }}</p>
TYPESCRIPT
...
// "this.translate" is our translate service
this.translate.use('es'); // use spanish
...
// should display 'hola mundo' when translated to Spanish
this.translatedText = this.translate.instant('hello world');
...
https://scotch.io/tutorials/simple-language-translation-in-angular-2-part-1
https://scotch.io/tutorials/simple-language-translation-in-angular-2-part-2
There is an official support for i18n in Angular.io here:
https://angular.io/docs/ts/latest/cookbook/i18n.html
But! As mentioned in docs:
You need to build and deploy a separate version of the application for
each supported language!
That makes this feature useless in most cases ...
Unless you will use it without CLI as described here:
https://devblog.dymel.pl/2016/11/03/angular2-and-i18n-translate-your-app/
I am putting together a POC and the official documentation is cumbersome to say the least, so I tried ngx-translate http://www.ngx-translate.com/ and I literally had the hello world working in a few minutes, there are few caveats:
I've read of people complaining about performance, because of the pipes, but reading the github issues, it seems that it is getting resolved
It is only for i18n or Translations it does not deal with i10n or Localization
There are few warning errors with Angular4 but it works anyways
long story short I liked ngx-translate if you have a small app and only need translation
I personally wanted Localization, so I am looking at
https://github.com/robisim74/angular-l10n
. It looks pretty good, but I haven't tested, so I'll let you know later, or you guys can go and we all try
First, I have IDE helper, and the php storm plugin. I tried the Gist pre made too. There are some similar questions, but no one seems to get answers. I'll probably poke laracasts and ide helper bug list if I don't get anything here.
So I'm following along to some of the into laracasts, and the guy keeps using methods that are not defined as far as I can tell. Situation:
I created a eloquent model called Article. It extends
Illuminate\Database\Eloquent\Model
So now I have App\Article and I can call any of the methods available to model. For example:
$article = \App\Article::all();
PHPStorm is happy. He keeps pulling stuff like ::find() or ::findOrFail()
It's in the docs
I just don't under stand how that works, I don't see the methods defined in model. If this is what ide helper is supposed to fix, then I'm not certain it's working correctly. I can RTFM, I'm pretty sure I followed the directions to a tee.
Ya know, I just found it. I see this question out and about, so I'll answer it here.
https://github.com/barryvdh/laravel-ide-helper/issues/248#issuecomment-131503475
Fixed find or fail for me. find is still MIA. I'm surprised laravel doesn't support their code base in the forms of plugins or dedicated IDE's bit more. It's all just people out there creating a community and moving the world forward so I can't complain too much.
It works because Model implements __callStatic() which dispatches it to itself on a new instance: __callStatic() implementation on Model
It creates a new instance (new static) of the model in question and dispatches the statically called method on the instance.
Effectively, Model::foo($bar) is the same as (new Model)->foo($bar).
I have created a document-based app that uses Core Data. I created the mac version first, and now that it's working properly, I am moving on to create an iOS version of it.
I just can't get my head around how to maximize code reuse between the iOS/mac versions, with respect to the Core data bit, since they don't use the same classes.
My document class that handles saving and such is a subclass of NSPersistentDocument. My intention is that a well-designed model class should work in both environments, especially since I don't do all that much fancy stuff with regards to Core data.
Now, since NSPersistentDocument isn't available in iOS, I hit a wall. I tried to get around this by using #if TARGET_OS_MAC and TARGET_OS_IPHONE and in that manner make it a subclass of UIManagedDocument in the iOS version. That obviously would have been convenient, but I can't seem to make it work like that. And it's really looks quite messy, since there are a lot of other stuff that has to be conditionalized as well.
I also tried building the classes atop of NSDocument/UIDocument instead, implementing the Core data hooks myself, but it also looks quite messy, leaving me thinking it's not the right way to go.
The question:
To me, it seems like a good idea to reuse the same document class between the iOS/mac versions, but maybe I'm being naive.
What's the best way to do this?
Should I forget about the code sharing and create a separate document class for the iOS version that emulates all the methods present in the mac version?
Am I right that the code you're wanting to share is model-related? I suggest refactoring that code to a separate object, which both an NSDocument and UIDocument contain (as rickster suggested above).
I use a DocumentRoot Core Data entity with its own NSManagedObject subclass, but if there are no properties you want to manage using Core Data, you can just subclass NSObject.
This may sound strange, but NSDocument and UIDocument are actually controller classes. (To be specific, they're part of the model-controller.) Their jobs are to load the model, set up windows, and save the model. If you need to provide an interface for higher-level access to model objects, it could be in a document root or model helper class instead.
Similarly NSPersistentDocument's job is to configure the managed object context and the persistent store and handle loading and saving. It doesn't necessarily need to provide a complete interface for accessing the model.
(Bringing this over from my comment.)
In general, the situation where you have two classes which must inherit from different superclasses but which also want to share a lot of code is composition. Put the shared code in a separate class; your NSDocument and UIDocument subclasses can each keep an instance of that class, and message it whenever they need to invoke that shared code. (Though as #noa mentions, you might want to consider whether all of that code belongs in your document class to begin with.)
Of course, then you might end up writing a bunch of methods that read like:
- (id)doSomething {
return [sharedController doSomething]
}
That can get to be a pain... so you might want to look into Objective-C's message forwarding system.