I have these "containers" which each holds one major section of my code. A page is therefore built up of a few containers, and they all look and behave the same. In my route directory, I have the following architecture
app
/containers
/Main
MainContainer.php
ContainerName1.php
ContainerName2.php
...
/Side
SideContainer.php
ContainerName3.php
ContainerName4.php
...
/Aux
AuxContainer.php
ContainerName5.php
ContainerName6.php
...
BaseContainer.php
So MainContainer.php, SideContainer.php, and AuxContainer.php all extend BaseContainer.php, and each ContainerName#.php extends the appropriate container. I currently have all the HTML/Views done within these containers themselves. But I wanted to move all HTML/Views to a template.
Should I have the templates in the /views folder, or should I keep it in this /containers folder? The reason why I may want to keep it in the /containers folder is because there will be a base.blade.php, and main.blade.php (and side/aux), and then one per ContainerName#. So it may stay cleaner if they are all there?? If I can do this, how do I call it?
I think this is partially a matter of opinion, but I'll toss my opinion in here and I suppose people can downvote me if they disagree.
I think it's better to keep all your views in /views, mostly because that's the appropriate and expected place for them. If anyone other than you were to maintain this project, they'd look for views in /views, and I think they'd be throughly confused if they were stored in some containers.
Here's what my view structure looks like in my project:
views
/layouts
main.blade.php
/includes
analytics.blade.php
navbar.blade.php
flair.blade.php
...
/account
main.blade.php
public-listing.blade.php
public-profile.blade.php
...
/game
listing.blade.php
settings.blade.php
...
about.blade.php
contact.blade.php
help.blade.php
I have my main templates in layouts (which is essentially my stock bootstrap code), I have little bits that I'll include in includes (things that will never be webpages on their own, but make other web pages work), and the rest goes in a sub folder depending on the controller. From each of my "full" views, the top line is #extends('layouts.main') and that makes sure it inherits the correct layout (if there was more than one, although there isn't in my example).
I think something like this could easily work for your project, and would go a long way in making it easier for you and anyone else to maintain.
Related
I'm creating a widget where there will be 2 types of params:
-The one that can change depending on where we call the widget, those one will be defined in the widget call:
<?php $this->widget('ext.myWidget', array(
'someParams' => 'someValues',
)); ?>
-The one that are the same for all the call to the widget (a path to a library, a place to save an image, ...)
I would like to know what is the best way to define the second type of parameters.
I'm hesitating between making the user define it in the params array in the config file or defining it in an array in the Widget file.
The main advantage of the first option is that the user won't have to modify the Widget file so in case of update his modifications won't be overwritten, but this is not a specific user params so putting it in the parmas array in config file might seem strange.
So what would be the best solution? If there is another one better thant the 2 above please tell me!
Edit:
To clarify my thought:
My widget will generate some images that can be stored in a configurable directory. But since this directory has to be the same each time the widget is called I don't see the point of putting this configuration into the widget call!
This is why I was thinking about putting some params into the config file, in the params array like:
params => array(
'myWidget' => array(
'imageDir' => 'images',
)
)
But I don't know if it is a good practice that an extension has some configuration values in the params array.
Another solution would be to have a config.php file in my extension directory where the user can set his own values so he won't have to modify his main config file for the plugin. But the main drawback of this alternative is that if the user update the extension, he'll loose his configuration.
This is why I'm looking for the best practice concerning the configuration of a widget
Maybe what your looking for is more of an application component than a widget. You've got a lot more power within a component that you have with a widget. It can all still live in your extensions directory, under a folder with all the relevant files, and still be easily called from anywhere but the configuration can then be defined in configuration files for each environment.
When your setting the component in your configs, just point the class array parameter to the extensions folder, instead of the components folder.
Update:
If you do want to use a widget because there's not a lot more complexity, you can provide some defaults within application configurations for widgets I believe, I've never used it myself, see here: http://www.yiiframework.com/doc/guide/1.1/en/topics.theming#customizing-widgets-globally.
But I've found with more complex widgets that a component serves me better in the long run as I can call methods and retrieve options on it much easier and cleaner, but still have everything related to the extension within one folder.
We would like to implement A/B (or split) testing on our shopping cart in Magento.
The new design is enough of a departure from the existing one, that we cannot easily create the test using something like Visual Web Optimizer. The only way we would be able to do something with VWO is to create two different URLs for the cart, displaying the original one in the normal /checkout/cart and the new one in /checkout/shoppingcart - or something like that.
Is it possible to do something like this within Magento or am I going to delve deeper into the code?
One possible solution I was looking at was (doing a really dodgy hack) copying the CartController.php and creating a new controller called ShoppingcartController.php. I'm not a fan of this, it's just way to dodgy...but as it's going to be throw away code, I think I'd be able to sleep at night ;)
I'm completely lost as how I could do this. Ultimately, it would be great if I could create two front routes, pointing back to the same controller...but I don't think Magento is that flexible.
One way to accomplish this, is to create two "views" (under one website), and use different URL's for each view, such as: www.site.com www1.site.com.
Once this is set up have Google's A/B testing functionality (or some other JS) direct users to the different views.
Good luck!
I'm fairly new to Joomla (I've been more of a Wordpress guy) and I have a question about module positions.
Can a module know what position it's in. For instance can I do something like this:
if(modulePosition =='left'){
Do this...
}else{
Do that...
}
It seems easy enough, but I've searched for hours and can't find anything that will help me with that. I know there is a countModules function but from what I can tell, that just checks to see if the module is active or not.
Thanks for your help!
I found the answer! Mostly thanks to #Hanny. His idea of using the modules id got me googling for that and I came across the answer. For anyone else that happens to be looking to do something similar here it is.
You use a global variable $module (who'd a thought, right?)
So my code now looks like this:
$class = '';
if($module->position == 'position1'){
$class = 'class1';
}
and so on...
Pretty simple, huh?
To find out what else you can do with the global variable $module just put this in your code and see what info you can use:
echo(print_r($module));
Thanks for all your help!
The short answer is 'yes', you'll assign a module a position based on your template. When it shows up you can have conditionals like that regarding that position (different templates have different naming conventions for positions, so make sure you know what they are before coding).
For example, some use "Position12", others may use "leftcol", etc. You just have to check in the template files to see (you can check the .xml file in the template directory to see the positions listed in the template, or look in the index.php file for the jdoc includes).
In some of my experience, the only time you'll really ever need code like that is in the core layout files of the template (for example, if you have different widths of columns depending on modules being present or not), otherwise there won't really be a time where you 'may or may not' have a module showing up - because you'll explicitly be telling them where to be and when on the back end.
I tried to comment under john's solution but I don't have a enough rep points-- I wanted to add it doesn't matter what you name the module position in your template case-wise the position name you get back from $module->position is always all lowercase regardless of how you named the position in the template... ie. in your template xml somewhere you might have topBar position will be named 'topbar' not 'topBar' when you try to check it with
if($module->position == 'topBar') //always false... use instead
if($module->position == 'topbar') //what you need to use
I'm going to disagree with Hanny. I think the answer is no, not as you describe.
The template knows when it has reached a module position, and it gets a list of modules assigned to that position, then calls for them to be rendered. But it doesn't pass that information on. It's not stored in JApplication or JDocument etc either (like, nothing stores where in the template the rendering is up to or anything).
There are some hacky ways to almost get what you want though. If you know the template positions you need to search (sadly there's no easy method for getting this from the template - otherwise you could parse your template's .XML file for <position> elements...), then you could do something like:
<?php
$positions = array('left', 'right', 'top', 'bottom')
$found_in = false;
foreach ($positions as $cur_position)
{
$module_positions = JModuleHelper::getModules($cur_position);
foreach ($module_positions as $cur_module_in_pos)
{
if ($cur_module_in_pos->module == 'mod_MYMODULE')
{
$found_in = $cur_position;
}
}
}
if ($found_in)
...
Of course, this doesn't work well if your module is included multiple times on the page, but maybe that's an assumption you can make?
Otherwise it'd be up to hacking the core - you could use a JDispatcher::trigger() call before the template calls a module, set some var etc. Unfortunately there's no such event in core to start (a pre_module_render or something).
A module instance is assigned to a single position and this is stored in the database and normally you would style the position in the template. A module instance can only be assigned to one position. So while it's an interesting question, it's not really a practical one.
The exceptions to this are the following:
loadposition ... you might want to know if a module is being loaded using the plugin because this would put it potentially somewhere besides the styled area for the position. THough i would recommend always making a new instance for this precisely so you have more control.
loadmodule ... module loaded by name using the plugin. In this case again you are probably better off making a new instance of the module and styling it. Also I'd put it in a span or div anyway, depending what it is.
jdocinclude:module ... loading a module directly in a template. Again if you are doing this I would wrap it in a span or div. In this case you are also allowed to include a string of inline styles if you like that kind of thing.
Rendering the module to a string and echoing it, again that is basically a very customized solution and you would want to set the styles and options.
I am making a site for a client and decided i would use code igniter.
The site essentially has two backends, one for designers, and one for a sales team. So after logging in, the user will be redirected to either
mysite.com/sales/
mysite.com/design/
The sales team for example can view orders, containers, products, therefore i need a controller for each of these.
mysite.com/sales/orders/
The sales need to be able to view, edit, delete certain orders...
mysite.com/sales/orders/vieworder/235433
Basically my problem is i dont have enough url segments to play with.
My thoughts on solving my problem
removing the orders, containers, products classes and making ALL of their methods as methods of the sales class, although this would mean a large number of methods and loading all models so it seemed kind of pointless.
removing the sales/designer classes and controlling what each kind of user has access to based on a user type stored in session data.
a way of having an extra url segment?
I appreciate any advice, I just dont want to get 3 weeks into the project and realise i started wrong from the beginning!
Use folders.
If you make a subfolder in /application/ called sales you can put different controllers in there:
/application/
/sales/
orders.php /* Controller */
/design/
Then in orders.php you will put your vieworders($id) method and so on, and you will be able to acces it with domain.com/sales/orders/vieworders/id.
You can also make subfolders in the /models/ and /views/ to organize your files.
Now, Access Control is something apart and it depends more in the auth system you are using.
Give the user/designer a privilege, a column in the user table for example, check the permission of the user at the beginning of the function, then prevent or execute it.
This would be the exact way i would do it.
Seems like you should have a look into the routing class. Might be a dirty solution but rerouting the sales/(:any) to something like sales_$1 would mean you'd make controllers with names like sales_orders.
Same for the design part.
(FYI: $routing['sales/(:any)'] = 'sales_$1'; should do the trick; see application/config/routing.php).
I'm developing a plone4 site on which every user have a sortable inventory of items. The ATFolder's folder_content view is ideal for this. The only problem is that instead of an URL like this:
/site/user/inventory
or this
/site/inventory/user
the url should be:
/site/inventory
I've thought in several solution, but each one have its own doubts.
Make the inventory content dynamic, depending on the authenticated user. I don't even know if this is possible on plone.
Somehow to cheat the transversal mechanism, so /site/inventory render /site/inventory/user.
Change the context before rendering the view. Again, don't know if possible.
Make inventory a subclass of ATCTContent, store the inventory data as annotation on the user and develop the ordering code all by myself. This is the option I'm trying to avoid.
What would you do?
Thanks.
Well, it'll be easy to define a inventory view that then uses the Authenticated User to render it's contents, which could be a simple delegation to an ordered folder that is stored at /site/users/user/folder.
The one thing that you have to remember is that user authentication happens after traversal. This means that when a view is instantiated (it's __init__ method is called) there is no user determined yet because that happens during traversal. Look up your user in the view __call__ or from it's template instead.
Having folder contents show contents that are not the contents of the folder is crraaaaAAAAzytalk. :) Don't do it. Either have a folder per user ( /inventory/user ) or make a custom view called inventory.html. You can make /inventory sho /inventory user but that is one step towards trying to make Plone to non-ploneish things, and that way lies a world of pain.
I don't know why you couldn't just call it /inventory/user? Seems easy enough. Then stick an action in the user viewlet, by the dashboard link, and your done! :-)
Plone is a content management system. Use it for that, as it's supposed to be used, and you'll be happy. Trying to force it to do things it doesn't want is like trying to build a sportscar out of a art deco sculpture. It might end up looking awesome, but it won't run very well. :-)