I've tried with netbeans and eclipse, with no luck... (coudn't try IntelliJ idea)
I gave a quick look ant the code
http://kickjava.com/src/groovy/servlet/TemplateServlet.java.htm
and it gives me the impression that .gsp pages are translated to .groovy servlets (groovlets) in memory (I might be wrong)...
so perhaps it's not so easy to debug gsp as I though...
so, can anybody tell me how to do it?
pd: By debugging I mean things like browsing the code step-by-step, inspecting variables, adding watches, and all those sort of things, obviously. Not the (not so) good old printf approach...
Most of the logic in your GSPs should be encapsulated in TagLibs, and you can debug them (with IntelliJ at least), just as easily as any other Groovy code.
If you do have a lot of scriptlet code in your GSPs (which you shouldn't), and you want to debug into it, you can't do much more than println. One other possibility is to view the source of the Groovy code generated for your GSP. This can be done by appending a showSource parameter to the URL, as described here.
I use a hack: add a method to any controller, like static def debugme(def param) { def a = param }, and call it from gsp code: <% ThisController.debugme(this) %>, or <% ThisController.debugme(params) %>
(you do know you don't have to restart application after editing a controller or view, right?)
I also don't think that all the logic should be in taglibs: page-specific logic should be clearly visible in a controller or a view. We have most of the logic in controllers or domain classes.
Add a setting to Config.groovy and the generated gsp-files will be written to a directory: grails.views.gsp.keepgenerateddir='/some/existing/directory'
(the target directory has to exists and be writable)
More information:
http://jira.codehaus.org/browse/GRAILS-4422
It should be possible to debug the generated groovy code with a standard Java debugger.
It was a long time ago when I did that (when I created the patch to grails) and I think I used jswat (http://code.google.com/p/jswat/) to debug gsps. I couldn't get eclipse to find the source files, but that's probably working in Spring Tool Suite Eclipse nowadays.
You have to debug groovy code step-by-step/step-into and use filters, otherwise you might lose the step point (because of closures?). That's already another story...
Related
We are having too many issues around all this extra code for every database field with regard to
if(databaseObj.getName() != null)
builder.setName(databaseObj.getName());
and I read square wired into protobuf adding setOrClear methods in java. How do we do this when we generate as well using gradle?
We are using the gradle code from this page right now..
https://github.com/grpc/grpc-java
thanks,
Dean
You can accomplish that via protoc_insertion_points. When you generate the Java code you will see comments like // ##protoc_insertion_point(...). That is where the insertion will occur.
While appearing useful, this approach has serious drawbacks for .protos used in multiple projects. All projects using the same .proto and in the same language should use the same plugins, otherwise it causes the diamond dependency problem. This is why gRPC did not use this approach and instead generates its classes in separate files from the normal message generation. I strongly discourage against this approach, as it paints you into a corner and you don't know when you will need to "pay the piper."
To insert into a point, your plugin needs to run in the same protoc command-line invocation as the java builtin. Your plugin would then need to set CodeGeneratorResponse.file.insertion_point and content for each file you want to inject code.
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
I have a controller that is only built in Debug (using #if DEBUG) that I use to house some test methods that I don't want on the production server.
The problem I'm running into is that using T4MVC I get a derived class based on the controller with overloads of all the methods. As soon as I try to build in Release mode that base class and virtual action methods are no longer present and I get build errors.
Ideally I would like to be able to exclude the controller from T4MVC but I can't see a way to do that in the settings file and the answer to this question: T4MVC How to Exclude Individual Files suggests its not possible.
Anyone know of a way to do it or can think of a good work around?
Use the T4MVC Attribute on your controller
[T4MVC(false)]
public Controller ControllerToIgnore //...
Worked for my purposes (to exclude a specific controller from being generated).
From the T4MVC documentation
Consider separating your test methods and controllers into a separate project that depends on your production code. This way you would not need to have #if Debug stuff. I'm not sure what is your set up, but you can try using NonActionAttribute that is wrapped inside #if !Debug clause. So your production code would not run the methods as actions on your controllers. But this stinks with the wrong layout of the project.
Short description
I'm getting used to CakePHP right now and am wondering about how to get more debug-information about what is happening inside the framework.
Let me please explain my situation a little more detailed
As you know CakePHP does a lot for you without putting you into the need to write additional code. One example is the handling of models.
I just created a model User and added validation-rules (no other methods). As described in the API methods like save will just work.
After that I created the needed controller and view to add a new user. When I try to add a user from the view I just receive the flash-message The user could not be created. Please, try again. No validation-violations are flashed.
I also did set the debug-level to 2: Configure::write('debug', 2); but do not receive any errors. The error.log inside \tmp\logs is also empty.
I really do want to learn how to solve those issues in the future.
So what else can I do to debug / display inner processes of cake?
Thank you very much for your help!
DebugKit is an official plugin that gives you lots of information on the request, queries and variables produced by Cake:
https://github.com/cakephp/debug_kit
You can also use trace() and other methods in the Debugger to show what is being executed in the background:
http://book.cakephp.org/2.0/en/development/debugging.html
Use a PHP IDE with an integrated debugger. That will allow you to follow execution line by line as it is executed and even inspect variable values as you go. Netbeans is a free one.
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