Post by Qphoria » Fri Nov 12, 2010 8:56 pm

d7a7z7e7d wrote:Please don't do that. There is nothing worse than having to edit your css in a textarea.

All we need is a layout manager. By default, all pages should use layout.tpl. However, a custom layout can be defined and applied on a per-category, per-product or per-information page basis. Think of it as theming on a more specific level.

Or, we all just simply wait and see what sort of changes Daniel has cooked up for 1.5 before we get too far ahead of ourselves.
I believe the return of layout.php is planned. And a plan that most of us are happy about (me included).
I think for css, we can easily make an editor window just like the system error log and have a save button. Just like phpbb does for their template editing. It still saves to the file on the disk

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by SapporoGuy » Fri Nov 12, 2010 10:00 pm

If you're gonna edit the css file then you might as well have the admin section pull up other files out of the directory.
The all files can be edited through a admin window like modx does.
However, I did notice that you will then have the wonderful problem of the server owning the files ... :crazy:

Having spent time years ago on pre-zen (yep, do know and remember how that went down) and creloaded working with a easy to rearrange layout for the end user I ended up adding to page load times and what not only to use the cache for layout extensively...

Why don't some of you template designers offer a few designs that can be added to the cart from the beginning?
I do agree that this will add bonus points when new folks are considering which cart to choose. However, I'd rather have Daniel work on the cart than converting 3-4 designs so that people can change colors in the css.

I am currently working on a relatively changed layout, ie using the left column in the footer and what not, so I do understand the pain of errors popping up due to variables not being declared anymore and what not.

So, maybe a slightly different template engine should be considered?
- allow controller variables to work throughout the XYZ section rather than per template area
- consolidate more of the language files into 1 main file and have a call to pull in new variables for addons/extensions
- still on the fence but maybe a smarty like template enviornment ????

Once again, this goes back a few posts back where I mentioned that maybe oc should become more frame like rather than a zen-bloat cart. ;)

930sc ... because it is fun!


User avatar
Active Member

Posts

Joined
Mon Nov 01, 2010 7:29 pm

Post by Moggin » Fri Nov 12, 2010 10:02 pm

mikex wrote: I guess not many people want to hide or move blocks around the page all day long. Things like these are better done by the theme designer.
Well, that's true! But it's useful to have a box showing, or not showing, when certain conditions are met. Examples:

1. Jay’s ‘Also Bought’ box shows only on the product page, cart page, or both. So it’s dependent on product being viewed or product in basket. Otherwise, it doesn't show.

2. Qphoria’s Paypal Express module only shows up on the cart page, when there are products in the cart (I think). Nothing in the cart = no paypal express box.

Plus - There are some postings on the Zencart forum, or somewhere, which show how to remove a box if under SSL. I tried to pinch the code but couldn’t make it work :-[ ;)

Maybe this would work on a per module basis, rather than globally? But it'd be great to have a small level of control like this - even if controlling the whole template from admin isn't practical.

Active Member

Posts

Joined
Wed May 05, 2010 4:56 am

Post by SapporoGuy » Fri Nov 12, 2010 10:35 pm

Module control could be done by expanding the current setup by adding more configuration settings. Then you need to increase the controller checks per page / per module ect ...

Since the module control section is on the board, why do we have to click to go to the edit page? jquery has a plugin that copies ext-js (or what ever it is called) that let's you edit from the table view layout. lolo, add drop and drag you could take care of order layout at the same time :laugh:

This is something, that was at the end of my to-do list ::)

930sc ... because it is fun!


User avatar
Active Member

Posts

Joined
Mon Nov 01, 2010 7:29 pm

Post by mikex » Sat Nov 13, 2010 4:21 am

Moggin wrote:
mikex wrote: I guess not many people want to hide or move blocks around the page all day long. Things like these are better done by the theme designer.
Well, that's true! But it's useful to have a box showing, or not showing, when certain conditions are met. Examples:
Yeah but wouldn't it be better/simpler to have options for that in the module itself? What I mean is that a wysiwyg editor for page layout is superfluous bloat since you'd rarely ever use it. That's just my opinion.

A built in file editor can be useful if you don't have FTP access but want to make some quick changes to the theme files. Though it's probably another thing you rarely use.

Newbie

Posts

Joined
Thu Sep 24, 2009 6:46 am

Post by Moggin » Sat Nov 13, 2010 5:11 am

mikex wrote:
Moggin wrote:
mikex wrote: I guess not many people want to hide or move blocks around the page all day long. Things like these are better done by the theme designer.
Well, that's true! But it's useful to have a box showing, or not showing, when certain conditions are met. Examples:
Yeah but wouldn't it be better/simpler to have options for that in the module itself? ....
Yes: on reflection, that does sound a much better option.

Active Member

Posts

Joined
Wed May 05, 2010 4:56 am

Post by robster » Sat Nov 13, 2010 7:27 pm

cs-cart have a nice system for box admin. You can not only choose to show boxes or not depending on what page, if logged in or not, by customer group, etc but also choose position on pages (left, right, home, header, footer, etc.) by dragging and dropping in admin.

robster

I know my place...!


User avatar
Active Member

Posts

Joined
Tue Jul 13, 2010 8:08 pm
Location - North Yorkshire, UK

Post by Daniel » Sun Nov 14, 2010 3:55 am

I'mn setting up a layout section in the admin. you set different layouts and you can choose which layout you want to use from the product, category, information pages. each layout can select a different template, modules to load etc..

only problem is that i need to think of some way to have different ones depending on which store or multi store is being used.

OpenCart®
Project Owner & Developer.


User avatar
Administrator

Posts

Joined
Fri Nov 03, 2006 6:57 pm

Post by interwebber » Sun Nov 14, 2010 4:24 am

Daniel wrote:I'mn setting up a layout section in the admin. you set different layouts and you can choose which layout you want to use from the product, category, information pages. each layout can select a different template, modules to load etc..

only problem is that i need to think of some way to have different ones depending on which store or multi store is being used.
I hope you find a way of achieving this. It would allow us the ability to easily provide a mobile web experience for our customers. I was kinda holding out for Drupal 7 / Drupal commerce, but would definitely consider OC if you pulled this off. Good luck and thank you for putting so much effort into this project.

Newbie

Posts

Joined
Fri Nov 05, 2010 10:37 am

Post by gocreative » Sun Nov 14, 2010 6:39 am

Couldn't you just edit the layout, and then when you're done you could choose 'Save layout for all stores' or check boxes next to store names to apply to those as well?

User avatar
Active Member

Posts

Joined
Tue Jan 12, 2010 5:46 pm

Post by jefrey1983 » Sun Nov 14, 2010 11:16 pm

wow 1.5.0 full of feature. keep it up :D

User avatar
Active Member

Posts

Joined
Sat Jan 30, 2010 6:58 pm

Post by SapporoGuy » Tue Nov 16, 2010 1:17 am

I added this in the feature request, but I really think that the way modules are recorded in the db should be re-thought.
Storing information in different tables is probably not the best way to go ... ::)

930sc ... because it is fun!


User avatar
Active Member

Posts

Joined
Mon Nov 01, 2010 7:29 pm

Post by Xsecrets » Tue Nov 16, 2010 1:43 am

SapporoGuy wrote:I added this in the feature request, but I really think that the way modules are recorded in the db should be re-thought.
Storing information in different tables is probably not the best way to go ... ::)
not sure what you mean all the module info is stored in one table. The settings table, so not sure what you mean.

OpenCart commercial mods and development http://spotonsolutions.net
Layered Navigation
Shipment Tracking
Vehicle Year/Make/Model Filter


Guru Member

Posts

Joined
Sun Oct 25, 2009 3:51 am
Location - FL US

Post by celestial » Tue Nov 16, 2010 2:03 am

Daniel, Q or development team please remember this in product page:

previous [1 of 10] next

(is a pain right now move between products in each categories) PLEASE

Celestial - Martín Abel Rosales
WhatsApp: 50671482211
Email: martinrosales2012@hotmail.com
Skype: martin.abel.rosales
San José , Costa Rica


User avatar
Expert Member

Posts

Joined
Sat Mar 20, 2010 4:19 am
Location - Costa Rica

Post by SapporoGuy » Tue Nov 16, 2010 2:25 am

Xsecrets wrote:not sure what you mean all the module info is stored in one table. The settings table, so not sure what you mean.
Here's the link to where I posted my original topic.
http://forum.opencart.com/viewtopic.php?f=110&t=22796

I just came across this today so ...

Basically, worried about how people are hacking the module system to get modules to work the way they want.
I just installed in the "my module" and "bottom description" extensions and noticed a very interesting hack to load information into a html block.

This brought about the thought of db performance and query calls. If this information is going into the cache then it's not really a huge hit but as the current system is I imagine to see more creativity like this occurring down the road.

So, to prevent that I was thinking that module information especially in regards to the cms type, maybe a change should be made to how the positions and information are being stored in the different tables. At the moment you have modules storing information in the settings table and then other information in the extension table.

Maybe, the current way is better for calling the config settings but then we need to consider how to expand extension table or add in another table to store other information. This could be cutting into Q's cms system though ...

lolo, this probably doesn't make real sense since I'm still thinking about how this could be done to provide the most possible scenarios for developers and still maintain db performance.

930sc ... because it is fun!


User avatar
Active Member

Posts

Joined
Mon Nov 01, 2010 7:29 pm

Post by Xsecrets » Tue Nov 16, 2010 3:01 am

actually I had forgotten about the extentions table I would say 99.9% of mod makers will never have to worry about that table it's all automatic and simply tracks which modules/extensions are installed and what type they are. The only time you have to worry about that is if you are doing something that needs to gather that information like the put the modules in the footer thing you mentioned. So I would say that is pretty much a non issue. The module settings are stored in the settings table these are the values set in the edit page for the module in the admin. If your module is bigger and needs it's own database tables like information where you have to track language then you create tables for that. I don't really see a problem with the system, and I think it would get very messy very quickly if you tried to combine all that into a single table somehow. Of course if you have a well though out alternative I'm sure the devs would at least take the time to look at it.

OpenCart commercial mods and development http://spotonsolutions.net
Layered Navigation
Shipment Tracking
Vehicle Year/Make/Model Filter


Guru Member

Posts

Joined
Sun Oct 25, 2009 3:51 am
Location - FL US

Post by SapporoGuy » Tue Nov 16, 2010 3:47 am

To some extent I agree that this is trivial but I was thinking that if the module system was built a little more dynamically allowing table_to_table integration it would allow more possibilities.

I do agree that putting everything into 1 table would make no sense.
I'm thinking 3 at the moment:
- keep setting for module position
- keep extension for main module information, could add in information for version etc ...
- table for more extensive data like html, blobs and such
(-) possibly a 4th for table_to_table reference for performance issues


here is sample of what I'm seeing:

Code: Select all

(1484,	'information',	'information_status',	'1'),
(1483,	'information',	'information_position',	'footer'),
(779,	'manufacturer',	'manufacturer_sort_order',	'2'),
(778,	'manufacturer',	'manufacturer_status',	'0'),
(765,	'bestseller',	'bestseller_sort_order',	'3'),
(764,	'bestseller',	'bestseller_status',	'0'),
(763,	'bestseller',	'bestseller_position',	'right'),
(762,	'bestseller',	'bestseller_limit',	'10'),
(774,	'featured',	'featured_position',	'right'),
(775,	'featured',	'featured_status',	'0'),
(787,	'category',	'category_position',	'right'),
(1525,	'bottomdes',	'bottom_des_status',	'1'),
(1526,	'bottomdes',	'bottom_des_sort_order',	'2'),
(1523,	'bottomdes',	'bottom_des_code',	'This is the bottom description mod'),
(1494,	'mymodule',	'mymodule_position',	'footer'),
(1493,	'mymodule',	'mymodule_code1',	'<p>\r\n	this is the my module mod</p>\r\n'),
(1492,	'mymodule',	'mymodule_header',	'0'),
(1524,	'bottomdes',	'bottom_des_position',	'footer'),
(1522,	'bottomdes',	'bottom_des_title',	'Bottom Description'),
(1491,	'mymodule',	'mymodule_title1',	'My Module Mod'),
(1485,	'information',	'information_sort_order',	'1'),
(1495,	'mymodule',	'mymodule_status',	'1'),
(1496,	'mymodule',	'mymodule_sort_order',	'3');
I do realize that I used a 3rd party extension and will probably re-write to use a setup similar to the information module but I really do wonder if this is the best way to go for database design.

930sc ... because it is fun!


User avatar
Active Member

Posts

Joined
Mon Nov 01, 2010 7:29 pm

Post by Xsecrets » Tue Nov 16, 2010 4:01 am

the biggest question is what are you going to do differently for the table for more extensive data like html, blobs and such? wouldn't you simply be needlessly moving one field out of the settings table and creating a new table for it? If it's not just going to be a general field like in the settings table then what is it going to be how many are you going to have. No matter what you do you'll never be able to accommodate every possible need and mods will still need their own tables anyways.

I guess the big thing I'm not understanding is why you are wanting to move some of the settings out into another database table? are you trying to increase performance? I'm pretty sure that on the vast majority of stores the settings table is going to be the least concern for performance. you're only talking a couple of hundred records even with a bunch of mods installed I don't see that being an issue really.

OpenCart commercial mods and development http://spotonsolutions.net
Layered Navigation
Shipment Tracking
Vehicle Year/Make/Model Filter


Guru Member

Posts

Joined
Sun Oct 25, 2009 3:51 am
Location - FL US

Post by SapporoGuy » Tue Nov 16, 2010 4:30 am

I guess I am going to agree with you on your points.

lolo, I gotta throw in a "however". I do still like the idea of separately if not just for the fact that this would another layer of ease of coding and organization.

Maybe, I'm just a clean freak and like to keep things orderly thereby not allowing a "settings" table turn into a bin collector. ;)

930sc ... because it is fun!


User avatar
Active Member

Posts

Joined
Mon Nov 01, 2010 7:29 pm

Post by Qphoria » Tue Nov 16, 2010 5:06 am

The extension table is only to determine which modules get loaded. All the settings are loaded from the setting table. So there is only 2 queries. The index loads ALL settings from the setting table to the config object. This is the biggest call of ALL settings and its one of the first things called.

The extension table is only called then to get a list of modules that are installed. So it is called once from column left, column right, and home for the type of extension of "module". Then grabs the data for each of those from the previously queried data that the config object now holds.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am
Who is online

Users browsing this forum: No registered users and 12 guests