I know this question has been asked before, but I am struggling to find an answer that fits my needs, or is for the most up to date version of Laravel.
Basically, I have a load of variables that will be created using data from the Route and the database. For example, I need to use the Route to set a variable called "current_page" which extracts details from the "pages" table using the unique url column. ($current_page = Page::where('url', <url-taken-from-route>)->first();)
$current_page will need to contain several relationships. There are also other global variables such as $current_site (this is a kind of multi-site environment with one home page and nested microsites) etc.
I feel the configuration files are not the right place to create these variables as a) the value of the variables can be nested and complicated and b) they are not constants but data retrieved from a database.
View Composers obviously only work with views, and a Helper class just feels too generic considering we are dealing with pages, sites, and possibly other global variables.
I gather global variables are frowned upon, but these truly are global. The values will always be the same (albeit dynamic) on every occasion, and will be required by most views and controllers.
I have also thought about putting methods in my already existing Page and Site controllers so I can call Page::current(), but am not sure putting static methods in a mostly non-static controller is the right thing to do. Also, this would make a database call every time I called Page::current() rather than having the current page stored in memory somewhere.
For now, I have created a BaseController which all other controllers extend from. I have put these variables in the constructor and manually passed them to the view in each method. (I know that is messy and doesn't work for models).
So what is the best solution here? Where to declare a global variable that can be used anywhere, but doesn't feel hacky?
Thanks
Related
It seems like I can declare computed properties in the model and in the controller. I'm getting to the point where I'm not sure which one to look in for a given property.
What dictates whether a property should be placed in the controller vs the model?
Typically, place in the controller if the property is presentational in nature (e.g. display, labels, formatting), and place in the model if the property is inherent to the record itself (e.g. calculations, associations)
In practical terms though:
Model if the property
needs to be accessed by other models, since models don't have access to their controllers
needs to be accessed in routes before controllers are setup
needs to persist across controllers (e.g. order.subtotal is used in OrderNewController and OrderController)
Controller if the property
only needs to be accessed by the view or template
only needs to be accessed by other controllers
You can probably go with putting most properties in the controller, until you run into situations where you need to access the property from other models, or if you find yourself writing {{controllers.modelName.property}} too many times.
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 have this idea of generating an array of user-links that will depend on user-roles.
The user can be a student or an admin.
What I have in mind is use a foreach loop to generate a list of links that is only available for certain users.
My problem is, I created a helper class called Navigation, but I am so certain that I MUST NOT hard-code the links in there, instead I want that helper class to just read an object sent from somewhere, and then will return the desired navigation array to a page.
Follow up questions, where do you think should i keep the links that will only be available for students, for admins. Should i just keep them in a text-file?
or if it is possible to create a controller that passes an array of links, for example
a method in nav_controller class -> studentLinks(){} that will send an array of links to the helper class, the the helper class will then send it to the view..
Sorry if I'm quite crazy at explaining. Do you have any related resources?
From your description it seems that you are building some education-related system. It would make sense to create implementation in such way, that you can later expand the project. Seems reasonable to expect addition of "lectors" as a role later.
Then again .. I am not sure how extensive your knowledge about MVC design pattern is.
That said, in this situation I would consider two ways to solve this:
View requests current user's status from model layer and, based on the response, requests additional data. Then view uses either admin or user templates and creates the response.
You can either hardcode the specific navigation items in the templates, from which you build the response, or the lit of available navigation items can be a part of the additional information that you requested from model layer.
The downside for this method is, that every time you need, when you need to add another group, you will have to rewrite some (if not all) view classes.
Wrap the structures from model layer in a containment object (the basis of implementation available in this post), which would let you restrict, what data is returned.
When using this approach, the views aways request all the available information from model layer, but some of it will return null, in which case the template would not be applied. To implement this, the list of available navigation items would have to be provided by model layer.
P.S. As you might have noticed from this description, view is not a template and model is not a class.
It really depends on what you're already using and the scale of your project. If you're using a db - stick it there. If you're using xml/json/yaml/whatever - store it in a file with corresponding format. If you have neither - hardcode it. What I mean - avoid using multiple technologies to store data. Also, if the links won't be updated frequently and the users won't be able to customize them I'd hardcode them. There's no point in creating something very complex for the sake of dynamics if the app will be mostly static.
Note that this question doesn't quite fit in stackoverflow. programmers.stackexchange.com would probably be a better fit
I have an dropdown attribute that I am creating during my module setup.
I want to pre-populate this attribute with some values while my module is installing. I can do this no problem, currently by simply storing the values in an array and then creating adding the options to the attribute in the install script.
Where would be the correct place to store these values - in a model? If so would it be a source model utilizing the toOptionArray method? This is technically used for forms so it doesnt seem right. But neither does just storing the values in the setup script.
Any ideas?
Yes, the toOptionArray method would be in line with standard Magento practices.
Typically the toOptionArray() is found in Helpers, if that is what you are asking. Helpers extend far fewer classes, and therefore inherit far fewer methods than models. This makes them much lighter weight for simple tasks like setting up an array of options, provided that they are static.
If the values are stored in a new DB table, and can be expanded upon by the user, it may make more sense to put this in a Model that has direct access to your DB table.
I'm building a simple login system for the CI based site and I I'm unsure of where to place my function:
is_logged_in()
// check if session logged in stuff exists
// if not check for cookie and reset from that
// return true or false
To start with I need to call this from some public pages so they they can display 'You're logged in as [blah]. Continue to members area'.
Would it make sense to put this in my login model, call it from my controller(s) and then simply pass the result (logged_in: true/false) to my views?
Mostly.
This might be a Model or it might be a Library issue. The question becomes how you are storing whether they are logged in. Personally, I generally put it in a Library which calls a specific Model, it seems less elegant at first, but realistically, I don't want my Model to know anything about my $_SESSION or my $this->session, one of which would be necessary if I wanted to have a good authentication system.
As to how to communicate with the view, there are a couple of ways:
Have it as a special variable passed to the view:
Bonus: It is the most obvious.
Detriment: You will need to place it into every single call to view. This means either you override your loader or you update all of your controls (might be gross).
Have it defined as a constant:
Bonus:By far the easiest if you have logic in the view.
Detriment:Constants are rarely the way to go, they are hard to debug, and it is not a very CodeIgniter way of doing things.
Have a helper function (literally a "helper" function)
Bonus:Universally accessible value which is relatively easy to debug.
Detriment:Requires a helper to know about a Library and/or Model (this is actually true of the built in form_helper, but it still opens up a proverbial can of worms) and it will probably be a one-function helper file.
Conditionally include a view from the controller
Bonus:It removes all logic from your view.
Detriment:You still need to make your controllers aware of the logic.
Personally, I am most likely to use #'s 3 & 4, but each has its advantages.