I've found properties corresponding to each action named like this: MVC.<Controller>.<Action>Params, they contain parameter names for each action. What are they for and how they can be used?
There were some edge scenarios where it was interesting to pass the parameter name as a constant. I can't instantly recall what that person was doing, but I could see this being useful is calls to AddRouteValue. In the end, it's all about never to have to use a literal string that refers to a C# object, whether it's a class, method, or param.
Related
I am trying to call a method of a class that I only know by name as a String. Now therefore I would need a ClassMirror of that class that allowes me to instantiate an instance. However, creating ClassMirrors seems to be only possible by entering a type using reflectClass(Type) or by passing an already existing instance of that class into reflect(dynamic). So these aren`t helping if I only have a String.
In Java you can do this pretty easily, by calling Class.forName(String). Then you would get a Constructor instance, make it accessibly and call it.
Does anyone know if this is even possible in dart? What seems weird is that once you have a ClassMirror you can access fields and methods by passing symbols, which can be created by Strings.
You can put a specific list of strings to map to a specific list of closures to create a new object with specific parameters.
But you can't get a reflection without using dart:mirrors, which is being deprecated, and also had a negative impact on tree shaking to get the payload size down.
In general, you're invited to look at the package:reflectable to achieve most of what you'd want out of dart:mirrors, using source-to-source builders.
I need to call a method from my action object inside the JSP, something like:
var currentStatus = ${getCurrentStatus()};
I cannot call an attribute, and I tried following this answer (How to call an action method using OGNL) and it didn't work.
There are a variety of ways to call methods (on actions, on other objects, or static methods from classes) from OGNL.
In this case, however, I don't see any issue with using a normal accessor. Note that the JavaBean convention is almost (completely?) about naming. A getter named getCurrentStatus(), accessed simply in OGNL via currentStatus, can contain whatever code you want.
This could include the DB access you mention in your question, etc.
In Grails you can declare a controller action like this:
def create(Integer foo, Integer bar) {
}
And if your HTTP request has parameters named foo and bar with values that can be converted to an Integer, the parameters will be assigned these values. I'm wondering how Grails can do this, because my understanding is that at the JVM bytecode level, a method's formal parameter names are not available. Is this witchcraft or am I misunderstanding something?
Basically what happens is that there's an AST transform that adds a new method with no args and the same name. This new method has logic in it to do the data binding based on the declared types of your "real" method, and then call your method. That's why the types are required (otherwise there's no way to do a conversion) and why you cannot have method overloads.
The inability to have overloaded methods is easy to work around though. Say you wanted an action
def foo(String bar)
and another
def foo(String bar, Integer wahoo)
In this scenario just keep the 2nd method and check to see if wahoo is null.
It's also important to use object parameter types and not primitives. If you use int/long/boolean/etc. and there is no provided parameter, you would get a NPE (since zero is not an acceptable conversion from null for numbers, and either is false for booleans).
You can get a decent sense for what's going on if you decompile the class using JD-GUI or another decompiler.
The fact that Grails controllers are Groovy classes helps quite a lot. Looking through the source code for controllers you can see where it makes heavy use of AST transformations, in particular the MethodNode. So, before it becomes bytecode the "witchcraft" is done. :)
I have been using XOM parser in a project that is mostly over. The parser is very good and I find it mostly stable. However today I was parsing an XML element with an attribute called "xml:lang"
The getAttributeValue("xml:lang") returned null instead of "English". I could find a work around to get the value by using getAttribute(int location).getValue()
However, it would be better to use the method getAttributeValue because the attribute's location changes for other elements.
I am not sure whether I am doing something wrong or a small bug lies there in the library method.
The xml:lang attribute is in a namespace.
To get the value of an attribute in a namespace, use the Element.getAttributeValue(String, String) method. The first parameter needs to be the local name of the attribute (after the colon), which is lang in this case. The second parameter needs to be the URI of the namespace, which is usually defined in an ancestor element. The xml namespace, however, is built in and always has the namespace URI http://www.w3.org/XML/1998/namespace.
Therefore, some code like this should do what you want (assuming you have a variable called element pointing to your element):
String lang = element.getAttributeValue("lang", "http://www.w3.org/XML/1998/namespace");
I want to use a custom setter to do some formatting of my fields. In irb if I test the setter like:
o.field_name = "4"
I see that my custom setter is being referred to. But with this it is not:
o[:field_name] = "4"
I understand that in the first case this is a function call and in the second case we are just setting the attribute directly. But I don't completely see how the attribute can be set without going through our custom setter, I thought that was the point.
But my main question is that if var holds my field_name, I don't see how to dynamically refer to a.var and have it be interpreted as a.field_name. All I see to do is a[var] and this bypasses my setter.
Try a.send(var) where var = 'field_name'
That's the equivalent of a.field_name
o[:field_name] is like read_attribute(:field_name), thus is just reads the value as you said. It can be quite important in virtual attributes in order to bypass the stack too deep error. If you do a[:var], you just get its value. A virtual attribute refers to an attribute, if you are setting its value to another variable, you just get its value, not the object.