I'm creating a multi-step form with pagination that will show a Next and Previous button depending on which step you are on. In order to display the buttons correctly, I need to store the total number of steps in a variable somewhere.
Do I store this in the Request scope e.g. REQUEST.TotalSteps = 5 or Application scope e.g. APPLICATION.TotalSteps = 5? The number of steps will rarely change so I'm thinking that Application scope is better suited, but I want to minimize the use of RAM because I have a lot of stuff stored in the SESSION scope for each other.
What would be the ideal option?
Depends on how you're gonna be using it really, and what framework you're using, how you're architecting your app and all that sort of thing. You only need the value in memory during the request(s) that need it, so TBH I'd just put it in the variables scope, making sure that the code that sets that variable is loaded for the requests that need it.
You'd not want to put it in session because it's not value specific to the visitor, nor does it have any relevance to the session: it's all just about that form.
Similarly it would not belong in the application scope (well: that has caveats, but given the low level of detail you give us as to how you've built you're app, let's assume this to be the case) because - again - it's not something the entire app needs; just the pages actually interested in how many pages that form has.
If you can give us more information regarding your architecture, I can possibly fine-tune this answer, but based on the info given: this is pretty much how you need to approach it, all things being equal.
The session scope is used to store information for the specific user. The application scope is used to store information that is available to the entire application. The request scope stores information during the course of the request. You want SESSION scope.
Related
Just curious if there is a best practice when wanting to use global variables across an APEX application. Do people use APEX's APPLICATION_ITEMS or just add PAGE_ITEMS to the Global Page (Page 0)? My initial thought is to use APPLICATION_ITEMS since that is their intended purpose, but using Page 0 gets around the small extra step when having to reference an APPLICATION_ITEM from JavaScript.
Any performance issues or potential caveats I may hit either way that I may not be aware of?
The way I see it, Page 0 items are useful if you want to display the same contents on different pages so that you wouldn't have to maintain many items everywhere, but only on Page 0. If you want to use them as "invisible" global variables, you'd then have to hide them using a server-side condition or dynamic action. But, why would you then use Page 0 items? Use application items instead!
Application items are true global variables; they aren't displayed anywhere in the application, but contain values you use wherever you need them. Not that you can't display their values - you can, but that's not the issue we're discussing here.
I haven't noticed any performance issues while using any of these.
Context:
I was going through various guides, tutorials and also posts here in the stackoverflow.
I need to handle process, e.g., - “pick topic —> show author list —> delete all —> ask confirmation —> show result —> go back to author list”
The obvious (and simplistic) approach is to create sets of views for each process.
And save process state in session variables or pass via URL-s (however, I discovered this method can be very brittle if too many information is passed). Also I need to tell each view where to go next, and this mushrooms into a bulky chain of instructions repeated for each URL request.
Instead, I want two extra things:
encapsulate a process at single place
re-use views, e.g. to re-use Topic List view to pick a single topic. That is, to work in “picker mode”. (btw, if I try to do this with multiple view classes, the next view class needs to know what to do and where to return…)
I also checked django workflow libs, and so on. and still not convinced.
Question:
if I create global object to encapsulate process and reference it from the current session - is this a good idea? My main concern is that - as sessions come and go, who will be cleaning up this global object?
is it possible to somehow make this clean up automatic? that is, when session goes away, some method is called where I can clean up or help GC to collect unneeded object? Like C++ destructors?
after working further with code, it occured to me that if I add global object to the session (and nowhere else) - it must be garbage collected in due course, because session itself is managed by Django.....
also, reading https://docs.djangoproject.com/en/3.1/topics/class-based-views/intro/ in my 3rd pass, found that Django's as_view() instatiates a new instance of class based views on each HTTP request.
so, everything is per request basis, and data will be transient. So only way to maintain state across HTTP requests is to either persist in the database or use sessions (or keep passing "state" from each request to request via URL parameters, but it is bulky, unsafe. my understanding is that this is a fallback mechanism if cookies are not allowed and session can be simulated via this way, e.g. PHP does it).
I have got an architectural question. Where should I check user permissions for certain operations?
For example:
1) In a controller, I get parameters from view and start a process in the intermediate model.
2) Intermediate model decide which parameter should be converted and transformed in any way and modify or create data through Models
3) Model communicate directly with DataBase
Where do You think is the right place in that "architecture" to check privileges to for example save sth to database?
I would actually put the authorization check before the controller is being called, kinda like described here (I really need to update that old post). Preferably as a decorator around the controller instance, which would give you a fine-grained control over what operation user is permitted to do, based on controller+method pair.
Another point where you might think about is "authorization lookup" helper function for use in your templates, because you might need to show or hide some UI elements from users, who should not be able to perform the associated operations. The controller+method check, before execution would still work as the actual safeguard then, but it tends to be a quality-of-life improvement.
You should not put the authorization checks inside the each controller or (even worse) model layer, because that tends to promote an excessive amount of copy-paste, which in turn can cause mistakes and becomes a huge problem, when you want to alter the mechanics of your authorization system.
I'm building a magento (1.9CE) store which needs to interface with another system and I could use some guidance.
Although not particularly relevant, I'm communicating with the 'other' system using web services (it's on another server) but what I need help with is finding the places where I need to put in code to do what I want.
There are three major functions that I need to implement:-
When a user clicks on the product detail page I need to make a call to check the stock levels on the other system, update the magento stock levels and THEN display the product detail page.
When a sale is completed, I need to send details of that sale to the other system.
When a new product is added I need to communicate with the other system. This may be a bit more complex because there are a few checks I need to do during the 'add product' process, for example, check the SKU is valid, that tghe product doesn't already exists, etc. I think until I start coding this I shan't realise the full extent of this functionality!
Any guidance gratefully received!
Even though this might (and probably will) dramatically slow down your store, if you want real-time information, I guess the easiest way would be with observers.
You can use catalog_controller_product_init_before: This will trigger when the product detail page is starting loading, so you should be able to upload the stock at this point, before the page has finished loading, so that if there is no stock it will not be buyable, which I guess that's what you want.
You can use sales_order_place_after: This will be triggered after a new order has been placed and saved in the database.
You can use catalog_product_new_action or catalog_product_save_after: Depending on how you create your products the first one might not be triggered. The second one will always be triggered once a product (new or existing) has been saved, so at this point you will need to check if the product is new or existing, and do your stuff depending on that.
For an example of how to create an extension and usage of observer events, check this out.
I hope it helps!
I am looking to return a random number between 0 and 4 in a Django view, which is repeatedly called. The number is limited in that it can't be the same as the number that was called previously. It would be fine if the number loops rather than being random, it just can't be the same as what was returned before.
I tried using a variable outside of the view, and incrementing it within the function, but that wouldn't save between each call to the view.
I hope that explanation works, I am brand new to Django.
What you are looking for are sessions.
Using sessions in django: http://docs.djangoproject.com/en/dev/topics/http/sessions/
General explanation of sessions: http://en.wikipedia.org/wiki/Session_(computer_science)
In a nutshell: store things in request.session, use it like any old dictionary.
It isn't clear from your question in what context you want to be sure the value doesn't repeat. For example, do you mean the same browser shouldn't see repeats, or globally, the same URL shouldn't repeat no matter who hits it?
For browsers, use sessions. They are persisted dictionaries identified by browser cookies. If you need it to be global, then you'll have to use the database or a global cache like memcache.