Would like to get some thoughts on how to best organize session vars within a scala / lift application.
I've read over a number of scala materials online and have found generally the following paradigm in all examples that introduce session vars:
declare an object that extends the SessionVar class
put that object into a file that contains a snippet (or any file)
access that object from anywhere in the codebase (lift will take care of the session var's lifecycle based on the lifetime of the user's http session)
Perhaps I'm not understanding something, but I'm concerned that this approach would lead to a whole bunch of these objects in various files all over the place. Its not such a big deal if its a small app, but when a project gets larger this could lead to chaos.
For those who have worked on larger scala projects, is there a generally accepted better approach? (even if its something simple like putting all of these objects into a common file?)
Thanks.
This is a bit subjective, but I'll give it a try. I think it depends on the scope the session var has in your project.
If you need the session var only in one snippet, you should make it a private member of that class.
If you need it in several but not all snippets, put those snippets in a package and make the object private to that package. If you have a lot of them, you could create an extra file to hold them.
If you need it globally, put it into a central location, maybe inside a package object.
If possible, avoid using SessionVars completely.
SessionVars should be used sparingly in your application. They are similar to Servlet Session Variables, except they are type safe.
How many session variables do you need? Personally, I have a session variable for the primary key of the current user and maybe one or two more. The rest of the state of the application should be stored in closures (because functions associated with GUIDs close over scope).
Related
I am working with a legacy scala codebase, and as is always the case modifying the code is quite difficult without touching different parts.
One of my new requirement in to make several decisions based on some input parameters. Problem is that these decisions are to be made at various points along the execution. So either I encapsulate all those parameters in a case class instance and pass it along. But it means I would have to modify multiple methods signatures, and I want to avoid this approach as much as possible.
Another approach can be to create a global object containing all those input parameters and accessible from different points in the execution. Is it a good approach in Scala?
No, using global mutable variables to pass “hidden” parameters is not a good idea, not in Scala and not in any other programming language. It makes the code hard to understand and modify, because a function's behaviour will now depend on which functions were invoked earlier. And it's extremely fragile, because you might forget setting one of those global parameters before invoking the function, which means that it will use whatever value was stored there before. This is the kind of thing that can appear to work for years, and then break when you modify a completely unrelated part of the program.
I can't stress this enough: do not use global mutable variables, period. The solution is to man up and change those method signatures. Depending on the details, dependency injection may or may not help in your particular case.
We can expose an object of a class by two methods like:
ClassName obj=Classname(); or obj=Provider.of<ClassName>(context);
is there any difference between them , or is there anyone of them better method.
ClassName obj = Classname();
This is creating a new instance of Classname. In Dart, you can omit the new keyword (since v2.0), older versions and most other languages actually force you to spell it out:
ClassName obj = new Classname();
It will call the constructor of the class and create a new instance. Alternatives would be named constructors that could look like this:
ClassName obj = Classname.fromInt(42);
That said, what exactly is this and what is the difference:
obj = Provider.of(context);
A provider is a form of state management. State management is a complex way of saying "where do I actually call my constructors so that the instances are known to the program at the place and time I need them? Sometimes I want a new instance, sometimes I want the instance I used before."
A provider may create a new instance for you. It may also decide it already has the instance you are looking for. You decide that by configuring it.
The only way to create a new instance of a class is through one of it's constructors. Very likely (but configurable), a provider is using a class constructor to create the instance of a class that it is then providing to multiple layers of your program so you don't have to keep track of that variable yourself.
Keeping track of all your variables and their lifetimes by yourself gets complicated really fast the bigger your program gets.
My personal recommendation to everyone learning programming is: try it the way you already know (in this case: constructors). Then you will experience for yourself what the problem is and you will know why packages like provider or bloc were created. This is a much better learning experience than just believing a random person on the internet (me or someone else) who says they know it's "better". Because then you will understand the problem instead of being railroaded into some cargo cult of "use this, it's good for you".
welcome to the StackOverflow.
You can do both of them, but if you are using the Provider package, you have some benefits:
It is much easier to transfer state to another level (or even really far level) inside your app's tree.
It is really suitable for a large scale app to manage their state (but it's also suitable for the small app).
If you are passing a state or an object directly, you'll be completely in a mess when your app complexity grows (based on my experience).
I hope it will be helpful.
listening is not possible with normal object creation where as with provider it is possible.
obj=Provider.of(context, listen:true);
In my iPhone development, I've always used global variables for lots of stuff. The style guide in my new job says we should use context parameters instead. So I need to figure out what that means and how to do that.
Can anyone explain in more detail what this means -- or point me to some code that works this way?
Thanks
It sounds like there may be a clash in nomenclature. From this definition of Context Parameters, they seem to be concerned storing global state for the duration of a session. Perhaps, you could use a 'contextParameters' NSDictionary within NSUserDefaults to store your globals. To the extent that your globals might need to be exported in their entirety (for debugging, for state saving) this might be useful in the long run.
The style guide might just be generically saying to keep your variables scoped based on the context of their usage. For example if you have a variable that you need for the lifetime of a class instance then make it a member variable of that class. If it is something that you need for the lifetime of the app then put it in an application wide object (but not a global variable).
If you use a global object (which could mostly be a big C struct containing all your former global variables) instead of individual naked global variables, you might be able to copy the object, serialize it to save it or create a unified core dump, eventually add setters/listeners, etc.
If you break the global object up, based on the shared scope or the required context of groupings of instance/struct variables, then the fractional objects might end up being good candidates for the M portion of an MVC repartitioning of your code for better reuse, extensibility, etc.
I'm in the process of designing an application that is part of a larger piece of work, depending on other people to build an API that the app can make use of to retrieve data.
While I was thinking about how to setup this project and design the architecture around it, something occurred to me, and I'm sure many people have been in similar situations.
Since my work is depending on other people to complete their tasks, and a test server, this slows work down at my end.
So the question is:
What's the best practice for creating test repositories and classes, implementing them, and not having to depend on altering several places in the code to swap between the test classes and the actual repositories / proper api calls.
Contemplate the following scenario:
GetDataFromApiCommand *getDataCommand = [[GetDataFromApiCommand alloc]init];
getDataCommand.delegate = self;
[getDataCommand getData];
Once the data is available via the API, "GetDataFromApiCommand" could use the actual API, but until then a set of mock data could be returned upon the call of [getDataCommand getData]
There might be multiple instances of this, in various places in the code, so replacing all of them wherever they are, is a slow and painful process which inevitably leads to one or two being overlooked.
In strongly typed languages we could use dependency injection and just alter one place.
In objective-c a factory pattern could be implemented, but is that the best route to go for this?
GetDataFromApiCommand *getDataCommand = [GetDataFromApiCommandFactory buildGetDataFromApiCommand];
getDataCommand.delegate = self;
[getDataCommand getData];
What is the best practices to achieve this result?
Since this would be most useful, even if you have the actual API available, to run tests, or work off-line, the ApiCommands would not necessarily have to be replaced permanently, but the option to select "Do I want to use TestApiCommand or ApiCommand".
It is more interesting to have the option to switch between:
All commands are test
and
All command use the live API,
rather than selecting them one by one, however that would also be useful to do for testing one or two actual API commands, mixing them with test data.
EDIT
The way I have chosen to go with this is to use the factory pattern.
I set up the factory as follows:
#implementation ApiCommandFactory
+ (ApiCommand *)newApiCommand
{
// return [[ApiCommand alloc]init];
return [[ApiCommandMock alloc]init];
}
#end
And anywhere I want to use the ApiCommand class:
GetDataFromApiCommand *getDataCommand = [ApiCommandFactory newApiCommand];
When the actual API call is required, the comments can be removed and the mock can be commented out.
Using new in the message name implies that who ever uses the factory to get an object, is responsible for releasing it (since we want to avoid autorelease on the iPhone).
If additional parameters are required, the factory needs to take these into consideration
i.e:
[ApiCommandFactory newSecondApiCommand:#"param1"];
This will work quite well with repositories as well.
Using new in the message name implies that who ever uses the factory to get an object, is responsible for releasing it (since we want to avoid autorelease on the iPhone).
You don't have to be obsessive about not autoreleasing. It really only applies if you happen to be creating lots of autoreleased objects within one iteration of the event loop. If this object is intended to live long enough that you would otherwise retain it outside of the factory method, giving back an autoreleased object will cost you only a reference in the autorelease pool.
Anyway, to answer your question, your choice is pretty much exactly what I would do. Consider also creating a Objective-C protocol that matches the API and that your APICommandMock and APICommand must conform to. That will document the API and provide some discipline for both you and the other team. For instance, it'll nail down things like method names and parameter types.
I have an extremely hard time figurering out how classes needs to communicate with eachother. In a current project I am doing, many classes have become so deeprooted that I have begun to make Singletons and static fields to get around(from what I get this is a bad idea).
Its hard to express my problem and its like other programmers dont have this problem.
Here is a image of a part of the program:
Class diagram
ex1. When I create a Destination object it needs information from Infopanel. How to do that without making a static getter in InfoPanel?
ex2. DestinationRouting is used in everybranch. Do I really have to make it in starter and then pass it down in all the branches?
Not sure if this makes sense to anybody :)
Its a problem that is reacurring in every project.
After looking at your class diagram, I think you are applying a procedural mind set to an OO problem. Your singletons appear to contain all of the behavior which operate on the records in your domain model and the records have very little behavior.
In order to get a better understanding of your object model, I'd try and categorize the relationships (lines) in your class diagram as one of "is-a", "has-a", etc. so that you can better see what you have.
Destination needs some information from InfoPanel, but not likely all information. Is it possible to pass only the needed information to Destination instead of InfoPanel?
What state is being captured in the DestinationRouting class that forces it to be a singleton? Does that information belong elsewhere?
There's just too little information here. For example, I am not even sure if MapPanel and InfoPanel should be the way they are. I'd be tempted to give the decorator pattern a try for what it's worth. I don't know why a Listener is a child of a Panel either. We need to know what these objects are and what system this is.