I'm upgrading a big 0.3.1 Griffon app into 0.9.4 I'm getting these difficulties:
Startup arguments:
I needed to deal with startup arguments so there was (in previous version) a:
class MyApplication extends SwingApplication
now it seems this can be accomplished in a cleaner way using:
app.getStartupArgs()
where should I put my own code? in Initialize.groovy script perhaps?
Any post or example on how to deal with these arguments?
Thanks in advance.
Accessing app.getStartupArgs() can be done from anywhere you have access to the app variable. Remember that lifecycle scripts are always executed inside the EDT, no exceptions.
Personally I tend to use application events more and more, for example reading the startup args after all startup mvc groups have been created can be done like this (in a file named griffon-app/conf/Events.groovy)
onStartupEnd = { app ->
println app.startupArgs
}
Related
I want to use standard Laravel facades, such as Str and Config, in my PestPHP Feature tests. Is there some concise way I can get PestPHP to do this for all of my tests in my tests/Feature directory?
I thought having uses(Tests\TestCase::class)->in('Feature'); in my Pest.php file would be sufficient, but all I ever get is this error: "A facade root has not been set."
The problem appears to be that Pest does not boot Laravel when it runs your test files, but rather only when you call certain global functions, e.g. the test closure functions test() and it(). So it's not possible to use Pest's "simplified" test script structure to easily initialize class-wide (file wide) values, i.e. attributes. beforeAll() does not work for this. Instead, one has to use beforeEach() in each class where facades will be needed.
See these issues: https://github.com/pestphp/pest/issues/237, https://github.com/pestphp/pest/issues/33#issuecomment-658022624, https://github.com/pestphp/pest/issues/246.
I wrote a small app returning routes with my public transport.
I'd like to package the app and use it via cli like: $ app_name start destination which is than handled by the app etc.
I've used the entry_points option in setup.py by defining an interface file, which is referenced when running the above code from command line.
However, I do not know if that's a best practice to accomplish that (as I have not found it on python.org.
So: What is a best practice to provide a cli?
An example I've seen:
with pytube you can do
$ pytube http://youtube.com/watch?v=9bZkp7q19f0 --itag=22
[EDIT:] thanks for the comments so far; they hint me to rephrase my question
I am basically executing the following luna-send command and trying to get those parameters from applicationManager:
luna-send -n 1 palm://com.palm.power/timeout/set '{"wakeup":true, "key":"myKey",
"uri":"palm://com.palm.applicationManager/launch","params":{"id":"com.my.app",
"params":{"test":true,"test1:true}},"in":"00:00:15"}'
After executing this command, my app gets launched by applicationManager, but I don't know how to get those params in my app. I am using enyo 2.0. I was trying to use onWindowsParamsChange handler, but ApplicationEvents is deprecated for 2.0. Can anyone help me with this?
Thanks
Under Enyo 1.0 it was enyo.windowParams. Under Enyo 2.0 I believe this functionality is gone. These parameters may be available through Cordova, but I'm not positive right now as I don't have the source handy. In any case, this was loaded from PalmSystem.launchParams so you should be able to access that.
If you're handling relaunch then you'll have a little more work to do. I think you'll need to define a Mojo.relaunch on the window object to detect when the launch parameters change.
I have had some experience writing container-bound scripts, but am totally new to web apps.
How do I debug (e.g. look at variable values, step through code etc) a web app? In a container bound script it was easy, because I could set breakpoints, use the apps script debugger - how do I go about this in a web page e.g. when I execute a doPost?
In his excellent book "Google Script", James Ferreira advocates setting up your own development environment with three browser windows; one for the code, one for the live view (in Publish, Deploy as web app, you are provided with a "latest code" link that will update the live view to the latest save when it is refreshed), and one for a spreadsheet that logs errors (using try/catch wrapped around bits of code you want to keep an eye on).
In Web Apps, even the most basic debugging of variables through Logger.log() does not work!
A great solution to have at least simple variable logging available is Peter Herrmann's BetterLog for Apps Script. It allows you to log into a spreadsheet (the same as your working spreadsheet or a separate one).
Installation is very simple - just add an external resource (see the Github readme) and a single line of code to override the standard Logger object:
Logger = BetterLog.useSpreadsheet('your-spreadsheet-key-goes-here');
Remember, that the spreedsheet that you give here as a parameter will be used for the logging output and thus must be writable by anybody!
BetterLog will create a new sheet called "Log" in the given spreadsheet and will write each log call into a separate row of that sheet.
So, for me, I debug the front-end using inspector, I haven't found a way to step through code yet, but you can use 'debugger' in your javascript (along with console.log) to stop the code and check variables.
to debug the backend, what I've been doing is to write my functions like
function test_doSomething(){
payload = "{item1: 100, item2: 200}" //<- copy paste from log file
backend_doSomething(payload)
}
function backend_doSomething(payload){
Logger.log(payload)
params = JSON.parse(payload)
...
}
Then after refreshing your project on the backend, you can look at executions, grab the payload from the log file, and paste it into your test_doSomething() function.
From there, you are re-creating the call that you want to debug and you can run that, stepping through the backend code as usual.
I was hoping to make a Rails app usable both as an Engine and as a standalone Application.
Specifically, I have a nascent app which I'd like to plug in to a customer's site, but ideally, I'd like to just as easily use the app as a standalone system. However, if config/environments/*.rb exist in the enginified version of my app, I get an Uninitialized Constant error at the time the app that I'm having take a dependency on my engine starts up; Rails complains that the MyEngineModule::Application constant can't be found in development.rb, which I think is simply a load order issue, since this does NOT occur when I run the app standalone. If I delete development.rb, the original initializers that reference my MyEngineModule::Application complain, so then I tried to delete those, and all is well.
Great, except that the original app doesn't work, since its configuration is gone.
Is there some tweak I can make to the initialization load order (or load paths, in the Engine < Rails::Engine class definition) that would prevent the original configs and initializers from being loaded when in an engine context, and allow me to leave them in place for the app context?
The simpler answer is probably this, but I'm feeling stubborn, and would like to know what it would take to make my original goal possible:
extract the code for MyEngine into an engine, remove the config/environments/* files and config/initializers/* files, and make the client app depend on this.
Make a "new" minimalist app depend on MyEngine, and move the environment files and initializers to NewApp.
Assuming I feel some unnatural compulsion to keep my original application runnable as it was, if I want to prevent the "engine" from loading the "application" configuration, what's the best way to handle that? I presume this is only really a problem during development, because I can prevent the environments/*.rb files from being pulled into the gem itself, but I like being able to test locally while I'm developing the engine and its client app.
Continuing my tradition of answering my own esoteric questions, it seems like one passable alternative is to include a guard clause in the engine's environments/*.rb and the initializers that goes something like this:
if defined? CuteEngine::Application
CuteEngine::Application.configure do
config.whatever = something
end
end
This gets around the problem of having two Rails::Application objects at a relatively small cost. Not very happy about it, but I'll live.
Bumping this for new comers.
Rails 3.1 comes with mountable engines, which sounds like exactly what you are describing. The docs aren't great for converting existing code, but it looks like this will do what you want:
module CuteEngine
class Engine < ::Rails::Engine
isolate_namespace CuteEngine
end
end
In your other app's routes.rb file, you'll add:
mount CuteEngine::Engine, at: "/cuteness"
http://edgeguides.rubyonrails.org/engines.html#mounting-the-engine
http://railscasts.com/episodes/277-mountable-engines