I cannot properly :extend a class in Gantry framework.
I'm trying to do:
.mybox:extend(.box3) {
/* Customization */
}
but it's not working.
I'm wondering whether it could be a version-related less compiler issue.
I tried defining mybox in template-custom.less and header-light-custom.less (because .box3 is in header-light.less and I'm using the "light" header), with no luck.
Gantry's PHP compiler doesn't support extends. It's planned to include support for extends in lessphp 1.4, https://github.com/leafo/lessphp/issues/426, though whether Rockettheme will update their implementation at that time is another matter.
You could simply disable Gantry's compiler and use your own, which is my preference;
http://internet-inspired.com/wrote/tutorials/disabling-gantrys-less-compiler/
Related
I would like to use Confirm Prompt but currently Confirm Prompt supports only few languages such as en-us, fr-fr etc. I would like to use Confirm Prompt for 2 different languages which are not supported by default. I know I can use fields as confirmChoices and choiceOptions to manually specify confirm choices but that would mean that I have to create 1 ConfirmPrompt for every language which is not included in Confirm Prompt by default.
The easiest way to add support for more languages, which are not included by default, would be to add them to defaultChoiceOptions map. But this map is declared as private static, hence it can not be modified.
So I am thinking about extending ConfirmPrompt class and overriding onPrompt and onRecognize method which will be exactly same as in ConfirmPrompt class but it will use myCustomDefaultChoiceOptions which will be non static and public field in my custom class => problem solved.
But this is hackish solution and I can not understand why this map is not public and non static in Bot Framework SDK.
Hence I am asking, is there any other solution (natively supported by framework) which allows me to add support for different languages in ConfirmPrompt?
This was actually a change pushed out a couple of months ago (by me). You'll need to update your packages.
choiceDefaults is private (and non-static, now), however, it can be updated by passing it into the constructor.
The easiest/best way to do this would be to build your PromptCultureModel for each language/locale/culture (so you can also use it easily with ChoicePrompt), then create the object with those PromptCultureModels that matches ChoiceDefaultsConfirmPrompt, and then pass that into the constructor.
You can see how I did this in it's test here.
Note: When you overwrite choiceDefaults, you lose all of the currently-supported languages. You can easily add them to your PromptCultureModel object via PromptCultureModels.getSupportedCultures().
Note: I've got a to-do to add some additional languages, but it's on the backlog since you can now add your own.
I've followed all the steps from other similar questions, and I'm still stuck.
I need to use the function proc_pidpath in libproc.h to get the path of a BSD process by its PID. However, libproc.h is not a modular header, so I can't include it in my umbrella header:
Fair enough; now I try to include it in my module map:
framework module My_Modular_Framework {
umbrella header "My_Modular_Framework.h"
private header "/usr/include/libproc.h"
export *
module * { export * }
}
Well now I get this error-vomit where it seems like it thinks many system modules/headers are within my project:
I can't figure out what else to do. Like I said, I already tried following all the steps of other similar questions without any success. What can be done here? How can I use proc_pidpath? Is there another, more Swift-in-modular-framework friendly way to get a path from a process ID?
I don't want to enable "Allow Non-modular Includes In Framework Modules" because that defeats the purpose of a modular framework.
Since libproc.h and libproc.c are open-source (APSL 2.0) as a part of Apple's Darwin project, you can just include them (under the terms of the license, of course) in your project. Since neither imports any non-modular headers, you can compile it yourself and the compiler won't complain!
from the official docs
https://laravel.com/docs/5.4/facades
this seems easy to test (the cache class)
public function testBasicExample()
{
Cache::shouldReceive('get')
->with('key')
->andReturn('value');
$this->visit('/cache')
->see('value');
}
as well in the documentation of facades it is written:
When building a third-party package that interacts with Laravel, it's
better to inject Laravel contracts instead of using facades. Since
packages are built outside of Laravel itself, you will not have access
to Laravel's facade testing helpers.
I really don't see how this is true. The package very well will access functions of laravel, so I don't see how it should not work with testing?
now in contracts https://laravel.com/docs/5.4/contracts they go on a little philosophical discussion what to use, facades or contracts. Isn't it better to use them together? Because contracts are nothing else than an interface. Now the idea of an interface is not new at all. I don't really get, what is the point about first of all comparing facades and contracts when:
facades are basically a extended class of laravel adding testing possibilities. They hide the implementation though and make it harder to read what functions are available on the class. E.g. you always first have to figure out what implementation is used of the facade, to see what methods there are.
contracts on the other hand are nothing else than interfaces. Basically the laravel people telling us "use interfaces". I agree, interfaces are great. But I don't see in what way this relates to facades. They are not related. They are not interchangeable neither.
So what is this all about?
why say "use contracts OR facades" they are not related, and should be used together imho.
An example is the Mail facade:
/**
* #see \Illuminate\Mail\Mailer
*/
class Mail extends Facade{...
so accessing Mail:: will return an instance of \Illuminate\Mail\Mailer
lets look at \Illuminate\Mail\Mailer
class Mailer implements MailerContract, MailQueueContract
{
nothing else than a class implementing a contract aka interface.
What exactly are they trying to tell us?
third-party package
is key term here to consider. Not every package is used with Laravel only.
The package very well will access functions of laravel
Is that true if I use CodeIgniter? Nope.
Now if you build a package specifically for Laravel, then by all means, use facades all day.
The whole point of this is to not couple yourself tightly with a single framework.
I am totally new in developing with Xamarin and I try to use the MvvmCross library in a shared project for all platforms. It seems that I succesfully added the libraries in each project, but now I am confused how to start. I tried to follow the documentation, but I think I didnt understand it right. I can use the CreatableTypes Method, but there are no EndingWith or the other Methods from the documentation. The examples that I found are mostly about PCL. I even dont know if this is a version problem or if I missed something important at all. Any hint or link would be helpfull.
First of all be careful what informations you read, always check the date or you will waste your time with some articles which are outdated. The most important ressources are prolly the official sample: https://github.com/MvvmCross/MvvmCross-Samples
Normally you use the PCL for all the background stuffand there should be some class like this https://github.com/MvvmCross/MvvmCross-Samples/blob/master/TipCalc/TipCalc.Core/App.cs . In this class you should be able to register all your services like this for IoC:
public override void Initialize()
{
CreatableTypes().EndingWith("Service").AsInterfaces().RegisterAsSingleton();
And then MVVMCross automatically takes care of initializing it, if you do a constructor injection in the ViewModel as a Example...
public MainViewModel(IPreferenceService preferenceService)
{
// Do Something here with the Service
}
...and you just need to call to show it with it connected view:
ShowViewModel<MainViewModel>();
So basically try to understand the samples first, i think TipCalc is still mostly up to date, atleast it is MVVMCross 4.0 https://github.com/MvvmCross/MvvmCross-Samples/tree/master/TipCalc
I have observed that some validators (Alnum, Alpha, Float, Int and PostCode) are localized into "Zend\I18n\Validator" package instead of "Zend\Validator" how the zend documentation explains.
Somebody knows because it's so.
Can I use these validators without problems?
Yes you can use them without problems. You may have to change your "use" statement or you can refer to them using their full namespace. In my current project I'm using the AnnotationBuilder to validate forms that contain floats using the #Annotation\Validator() syntax. It works quite well.
The only issue I came across was I needed to install/enable the php-intl extension on my server.