I am attempting to use the Exhibit pattern in a padrino application but to do so properly I need to access the rendering context. That is, I need to have some object context such that calling something along the lines of context.render('accounts/index') will produce identical output to when render 'accounts/index' is called from inside a controller (assuming that all variables are set the same and that app/views/accounts/index.erb is a template file).
I can't find anything that does this within the padrino public API, so I attempted to dig deeper. The existing render method in the controller wraps sinatra's render method, which is a private instance method. So it's not obviously not defined on the class MyApp (i.e. the Padrino::Application subclass). MyApp.new results in an instance of Rack::Session::Cookie rather than of itself, and none of the padrino methods that I can find return the existing instance of the app, which would be a suitable candidate for the context object if I called its private render method.
Is this something that's just inherently too difficult to bother with given sinatra's and padrino's designs, or is there something that I'm missing here?
I realise that the answer was in the Objects on Rails book if only I'd kept reading. I needed to pass the context explicitly from within the template: exhibit(object, self) inside the template causes the template's rendering context to be passed as the second argument. Of course.
I guess this really wasn't specific to padrino after all and I was looking for something complicated when the answer was very simple.
Related
when creating custom method, I implements TemplateMethodModelEx and returns SimpleSequence object.
according to the API, I should use this constructor:
SimpleSequence(ObjectWrapper wrapper)
since I am setting incompatibleImprovements as 2.3.24, the doc said I can simply use Configuration instance's getObjectWrapper(). My problem is when implementing TemplateMethodModelEx, I have no access to the current config unless I pass cfg to the method's constuctor. then the root.put would look like:
root.put("getMeList", new GetMeListMethod(cfg));
this looks odd to me, i wonder whats the right to construct this kind of SimpleSquence model and whats the right way to get the default object wrapper.
Thanks a lot
You should pass in the ObjectWrapper as the constructor parameter. (It's unrelated to incompatibleImprovements 2.3.24.) Any TemplateModel that creates other TemplateModel-s (like TemplteSequenceModel-s, TemplateHashModel-s, TemplateMethodModel-s) used to work like that. This is normally not apparent because they are created by an ObjectWrapper. If you do the TemplateModel-s manually however (which is fine), then you will face this fact.
I know early versions of Grails used prototype scope for controllers because actions were all closures at that time.
I know that the current version documentation recommends singleton scoped controllers for controllers that use methods as actions.
From the following post it seems that methods and singleton scope are more desirable or recommended, but it's not clear why.
ttp://grails.1312388.n4.nabble.com/Default-scope-for-controllers-doc-td4657986.html
We have a large project that uses prototype scoped controllers with actions as methods. Changing to the recommended controller scope involves risk and retesting, and removing any non-singleton friendly state from existing controllers.
I'd like to know why does Grails recommend singleton scope for method as actions controllers? Is it just because that's more common and similar to Spring MVC, and avoids confusion, or is there an opportunity for performance improvement, or what? What do I gain if I make the switch to singleton controllers? What is the cost if I don't make the switch?
I haven't worked much with Rails, but (at least in the versions I played with, things may be different now) the controller is the model, containing the data to be rendered by the view. During request handling you store values in controller instance fields before handing off processing to view renderers. So there it makes sense to create a new controller instance for each request so they're distinct.
Grails was inspired by Rails and uses several of its conventions, most famously convention-over-configuration. But the ability to use the controller as the model was also added as a feature, although it wasn't well documented and I doubt many used it.
The typical way a controller action works when using a GSP to render the response (as opposed to forwarding or redirecting, or rendering directly in the controller, e.g. with render foo as JSON) is to return a Map with one or more key/value pairs from the action, and often the return keyword is omitted since it's optional in Groovy:
class MyController {
def someAction() {
def theUser = ...
def theOtherObject = ...
[user: theUser, other: theOtherObject]
}
}
Here the model map has two entries, one keyed by user and the other keyed by other, and those will be the variable names used in the GSP to access the data.
But what most people don't know is that you could also do it like this:
class MyController {
def user
def other
def someAction() {
user = ...
other = ...
}
}
In this case a model map isn't returned from the action, so Grails would populate the model from all properties of the controller class, and in this case the same GSP would work for both approaches since the variable names in the second approach are the same as the map keys in the first.
The option to make controllers singletons was added in 2.0 (technically 1.4 before it was renamed to 2.0, see this JIRA issue) and we also added support for methods as actions in addition to retaining support for closures. The original assumption was that using closures would enable some interesting features, but that never happened. Using methods is more natural since you can override them in subclasses, unlike closures which are just class-scope fields.
As part of the 2.0 rework we removed that Rails-inspired feature on the assumption that since it was essentially undocumented, that the impact on the few odd apps that used the feature wouldn't be significant. I don't recall anyone ever complaining about the loss of that feature.
Although controller classes are typically readily garbage-collectible and creating an instance per request doesn't affect much, it's rare to need per-request state in a controller, so singletons usually make more sense. The default prototype scope was left for backwards compatibility but it's easy to change the default with a Config.groovy property (and the file generated by the create-app script does this).
Although each request does get a new request and response, and if sessions are used each user will have their own, but those are not instance fields of the controllers. They look like they are because we can access request, response, session, params, etc. inside of actions, but those are actually the property access forms of the getRequest(), getResponse(), getSession(), and getParams() methods that are mixed into all controllers during compilation by AST transforms. The methods access their objects not as class fields but via ThreadLocals, so there is per-request state but it's not stored in the controller instance.
I don't remember if there was much in the way of benchmarking to compare using methods versus closures, but Lari Hotari probably did some. If there was a difference it was probably not significant. You could test this in your own application by converting just one or a few controllers and doing before and after tests. If the performance, scaling, and memory differences aren't significant between the two approaches you'll probably be safe staying with prototype score and/or closures. If there is a difference and you don't have instance fields in your controllers, then it'll probably be worth the effort to convert to singletons and methods.
If you do have instance fields they can probably be converted to request attributes - request.foo = 42 is a metaclass shortcut for request.setAttribute('foo', 42), so you could store per-request data safely there instead.
I've been looking around for best practices on where to put some helper methods that do all this calculation / sorting for me but I haven't found a definitive answer yet and was wondering if someone had some good insight for me.
Basically I have an action method that takes a string user input, finds similar words to that string, does a bunch of string manipulation, and then ordering to return an array.
I don't know whether I should have module in /lib, make a controller helper module, ... Where I'm looking for some feedback!
But essentially I just want to:
POST a word to a controller action method
Call a helper method or execute some logic on the word outside of the controller
Have that helper method or wherever that logic will be, return to me the result
Just put that method in your application helper, wherever it is called from it will return the resulting values after processing your logic, you should not over complicate things so the good old application helper is a good place to put the common method used in views and in your controllers
I wouldn't call a helper method from your controller. Personally I would use either a module/plain old ruby object or a concern to handle calculations. The controller stores the object in an instance variable so it can be used througout your views.
Also worth noting are decorators, you should take a look at draper: https://github.com/drapergem/draper
Can someone explain to me when methods are called in WD4A applications? Particularly methods that are defined in the application controller (and not the view (controllers)).
I'm looking at some sample codes and there's this supply_unit method in the componentcontroller which basically reads a few values from a table and puts these in the controller context so they are available in view_2, based on a context node that was assigned a value by the user on view_1.
But I don't see at which point this method actually get's called (the application actually has more than only these two views) and how the application knows that it needs to be called so everything can be shown in view_2
SAP's standard documentation for WebDynpro is pretty good, and goes through all of this. This page (and the pages below it) describe programming controller methods in general. I would suggest taking a couple days and working through all of the WebDynpro for ABAP documentation, coding examples as you go. You'll have a much more complete understanding that way.
Methods should be implemented in the component controller (as opposed to the view controller) when the logic of that method is used (or may be used) across multiple views. For example, if you have a context node thats displayed in multiple nodes (like a list of units of measure), it makes sense to program it's supply method once in the controller, instead of in each view.
Your question seemed to be more about supply functions (SUPPLY_UNIT sounds like the name of a supply function). These are methods that are called automatically by the system the first time a context node is read. They are used to initialize contents of the node. More info can be found here.
I'm interested in simply slowing down the evaluation of ruby code. Of course I know about using sleep(), but that does not solve my problem.
Rather, I want to slow down every single object instantiation and destruction that happens in the VM.
Why? So I can learn about how particular procedures in ruby work by watching them being carried out. I recently learned about ObjectSpace and the ability to see/inspect all the objects currently living in a Ruby VM. It seems that building a simple realtime display of the objects and properties of those objects within the ObjectSpace and then slowing down the evaluation would achieve this.
I realize there may be ways of viewing in realtime more detailed logs of what is happening inside the ruby process, including many procedures that are implemented at low-level, below the level of actual ruby code. But I think simply seeing the creation and destruction of objects and their properties in realtime would be more edifying and easier to follow.
You could be interested in the answer to this question: getting in-out from ruby methods
With small edits to the code reported there, you could add a sleep to each method call and follow the code execution.
If you want to output some information every time an object is instantiated, you could do that by overriding Class#new. Here's an example:
class Class
alias old_new new
def new(*args)
puts "Creating: #{self.inspect}"
sleep 0.1
old_new(*args)
end
end
class Point
end
class Circle
end
The alias old_new new line creates a backup new method, so we can have the old behaviour. Then, we override the new method and put some code to inspect the subject class and sleep for just a bit for the sake of better readability. Now, if you invoke Point.new, you'll see "Creating: Point". Circle.new will display a "Creating: Circle" and so on. Any objects that are created will be logged, or at least their classes, with a small delay.
The example is a modified version of the one from here.
As for destruction of objects, I'm not sure if there's a sensible way to do it. You could try to override some method in the GC module, but garbage collection is only initiated when it's necessary (as far as I'm aware), so you could easily play with ruby for a while without it ever happening. It probably wouldn't be very useful anyway.
I think the problem is not that ruby is too fast.
In your case you should use some software architecture, for example Model-View-Controller.
It could be in this way. In View you can show options at which speed the Controller should show information for you or you're able to slow down or increase the speed of showing information. Then Controller evaluate small steps (calling methods in Model) and rendered the results of evaluation in the View.
The View is not always the browser or window application, it could be also just a simple terminal.