Why #PetiteInject cannot inject service in DecoraManager? - jodd

I have a DecoraManager implementation : AppDecoraManager, and want to inject a service e.g.: FooService as:
#PetiteInject
FooService fooService;
When resolveDecorator() is called I want to use fooService to determine some parameters, but it has null value.
What could be the reason for this, and how could I resolve it?

DecoraManager is created by the servlet container, in DecoraServletFilter.
At the moment, there is no integration with existing Petite IOC, so you have to do the following:
First, you need to have a public static reference to PetiteContainer. Store it during the creation of container, for example.
Override createDecoraManager() in your implementation
Use PetiteContainer.wire(this) in your implementation of DecoraManager.
That is the only way to do so, so far.
The alternative would be this:
Register DecoraManager as #PetiteBean.
Again, get the static reference to PetiteContainer
In createDecoraManager use PetiteContainer.get() to get the instance.
In the first example, DecoraManager gets just wired; in the second example, it gets stored in Petite container, too.

Related

Making changes to functions of protoc generated APIs

Suppose I have a person.proto file-
syntax = "proto3";
/* Class Person */
message Person{
string name = 2;
}
Then, I use protoc to generate the source code in Python, or C++.
Question 1:
Suppose I generated the API code, now what I can do to create an object of Person class, is:
person = person_pb2.Person() # In Python
Person person; // In C++
What I want is, every time I create an object of Person class, the reference to this object is stored with a unique ID inside a map.
Basically, I want to create something like a map, to store the reference of every object of each class that is ever created.
One way to achieve this I thought of is to add a custom line of code (which calls a different function) to the classes' constructor, such that every time an object is created, that function will add reference to it to the map.
Is this approach good? If yes, then how to achieve this- customizing class constructors of protoc generated source code (in every language- C++, Python, Java, etc.). If no, then what could be a better solution?
Question 2: For the fields, we have setters and getters. e.g.
person.name = ... # In Python
person.set_name(...) // In CPP
So, what if I want to add something more to the set_name() function, how can we do that?
Like if I want to call a function inside set_name(), then how to achieve that?
In short, both the questions sum up as "How to make changes to the functions of API that protoc generates (in all the languages)?"
Is there something to do with plugins? Or with descriptor files? Or something else?

removeChild added in an other class

I've got a little problem.
I'm trying to remove a child called in an other class.
I've called "viseur" in my Engine class like that :
private var viseur:Viseur;
viseur = new Viseur(stage);
stage.addChild(viseur);
Now, in my Puzzle.as class I'd like to removeChild(viseur) when my puzzle is complete.
How do I do to do that ?
I've tried :
Engine.viseur.stage.removeChild(viseur);
But it is not working... (and either Engine.viseur.removeChild(viseur) )
Anyone know how could I do that ?
Thank you very much,
There are two issues at play here:
The call Engine.viseur.stage.removeChild(viseur); does not work because the variableviseur is private to the Engine class. If you wish for it to be accessible to other classes, you need to make it public.
However, the other issue with this is that the viseur variable is not a static variable either. So accessing it like this, Engine.viseur.stage.removeChild(viseur); is still incorrect even if you fix the variable to be public. if you wish to access it via another class, you can either 1) pass a reference of the instance of the Engine class to your other class so that it can access the viseur variable or 2) make the viseur variable a static variable, but remember if you do this, that means you can only ever have one Viseur object named viseur.

Actionscript 3 - passing custom class as parameter to custom class where parameter class not constructed

Hi and thanks in advance,
I have a custom class being constructed from my main class. In the custom class it has another custom class that is passed in as a parameter. I would like to strictly type the parameter variable but when I do, 'the type is not a compile type constant etc'.
This, I understand, is because the custom class used as a parameter has not yet been constructed.
It all works when I use the variable type ( * ) to type the parameter.
I suspect this is a design flaw, in that I am using an incorrect design pattern. It is actually hand-me-down code, having received a large project from someone else who is not entirely familiar with oop concepts and design patterns.
I have considered using a dummy constructor for the parametered class in my main class but the passed in class also takes a custom class (itself with a parametered constructor). I am considering using ... (rest) so that the custom classes' parameters are optional.
Is there any other way to control the order of construction of classes? Would the rest variables work?
Thanks
(edit)
in main.as within the constructor or another function
var parameter1:customclass2;
customclass1(parameter1);
in customclass1 constructor:
public function customclass1(parameter1:customclass2)
{
....
Flash complains that the compiled type cannot be found when I use the data type customclass 2 in the paramater. It does not complain when I use the variable data type * or leave out the data type (which then defaults to * anyway). I reason that this is because customclass2 has not yet been constructed and is therefore not available to the compiler.
Alternatively, I have not added the path of customclass2 to the compiler but I am fairly certain I have ruled this out.
There are over 10,000 lines of code and the whole thing works very well. I am rewriting simply to optimise for the compiler - strict data typing, error handling, etc. If I find a situation where inheritance etc is available as an option then I'll use it but it is already divided into classes (at least in the main part). It is simply for my own peace of mind and to maintain a policy of strict data typing so that compiler optimization works more efficiently.
thnx
I have not added the path of customclass2 to the compiler but I am fairly certain I have ruled this out.
So if you don't have the class written anywhere what can the compiler do ? It is going to choke of course. You either have to write the CustomClass class file or just use "thing:Object" or "thing:Asteriks". It's not going to complain when you use the "*" class type because it could be anything an array, string, a previously declared class. But when you specify something that doesn't exists it will just choke, regardless of the order the parameters are declared in.

Map/Dictionary which limit entries size in ActionScript 3

In Java, this can be done with LinkedHashMap by removing eldest entry/oldest accessed entry. Any equivalent class in ActionScript 3?
Thanks.
No, unfortunately not. You could easily implement one, if I were going to implement it I would extend the Proxy object It'll give you a fair bit of flexibility.
UPDATE:
This update is to clarify on the question in the comment by the OP. Comment was "It will be a new class extends Proxy and not Dictionary/etc?"
Yes, you would want to extend Proxy, the reason for this is that it allows you to override several magic methods to accomplish your goal. Particularly in your case, you can override setProperty(name:*, value:*):void. This method will be called every time a property is set on your class (its up to you to supply the set implementation) so you can count the number of values that are set at a given time. If you extend Object or dictionary, you do not have access to this, and have know way of knowing when a new property is set.
If you extended object instead, you would need to rely on an interface to to acheive your goal, requiring user to set properties through method calls.
A Proxy implementation would allow you still set properties like this:
myObj.foo = 'bar';
myObj["foo"] = 'bar';
A method implementation (extending Object) would look like this:
myObject.setVal("name", "val");

Why do static Create methods exist?

I was wondering, why do static Create methods exist?
For instance, why use this code:
System.Xml.XmlReader reader = System.Xml.XmlReader.Create(inputUri);
over this code:
System.Xml.XmlReader reader = new System.Xml.XmlReader(inputUri);
I cannot find the rationale for using one over the other, and can't find any relation between classes who use this construct over the other.
Can anyone shed some light on this?
XmlReader is an abstract class. You cannot instantiate it.
Providing a Create method is an instance of the factory pattern. Depending on the specified arguments a different implementation of XmlReader is chosen and returned. For example, there are validating and non-validating XmlReader implementations in the .NET framework.
A more general answer...
The reason people like these kinds of methods, known as "static factory methods", is because you can give them a name (as opposed to constructors). So if you need three different constructors, you can instead create static factory methods which have names relevant to their use.
Another reason is that a factory method doesn't really need to create new objects - it can return the same one over and over if need be.
Because it can actually create and object of derived type that you have no access to or return an abstract class (as dtb answered). This is factory method pattern.
A constructor can only be used to create instances of one specific class, while a static Create method can create an instance of different classes depending on the input.
In the case of the XmlReader class the Create method will return an XmlDictionaryReader, XmlTextReader, XmlValidatingReader or XmlNodeReader, depending on which overload you use and what parameters you send to it.
This pattern allows the XmlReader class to provide you with instances of derived classes tailored to the parameters you passed to Create. Note in particular the overloads that accept an XmlReaderSettings object. A different XmlReader subclass can be returned to you depending on your settings.
A better example is WebRequest.Create(url). Depending on the URL you pass, you may receive an HttpWebRequest, an FtpWebRequest, etc.
Because you don't have to commit to the exact class of object you get. Constructors can only construct objects from exactly one class.
Because you can give the method a meaningful name, e.g. BigInt.probablePrime(). Constructors can only have the same name as the class.
Because you can have more than one factory method for the same parameter type combination, e.g. Point.fromPolarCoords(int, int) and Point.fromCartesianCoords(int, int), but there can be only one constructor Point(int, int).
(A much more detailed answer is given in Bloch's 'Effective Java'.)
Sometimes they exist as a form of self-documentation. I have a db access component that I can instantiate either with a connection string or the name of the connection in the config file. Both of these methods take strings as a parameter so they cannot be differentiated by arguments alone. So I created a FromConnectionString(string) factory method and a FromConnectionName(string) factory method. This nuance would entirely be lost by a new Foo(bool, string) line.
The idea is that this way they can change the implementation of XmlReader and not break any user code (e.g. they can change the actual type that is returned from the Create method).
I personally don't like this approach, because it creates an inverse relationship in the XmlReader class hierarchy. Maybe they thought that the Factory pattern is an overkill?
To encapsulate object creation.