Hi,
While such an approach is nice for developers it's actually quite Bad for the Site's Performance since each Module could require additional CSS and JavaScript Files. Those Files would have to be loaded separatly by the Client if included in the templates. I therefore suggest implementing a registry where you could define which CSS and JavaScript Files have to be present in which Views and the Core could than automatically combine and compress the Files. Ideally you would differ between synchronous JavaScript Files (to be present on Page load) and asynchronous Files. -- ooxi Violetland — An open source cross-platform game similar to Crimsonland — http://violetland.github.com Daniel Schlichtholz <ad...@mysqldumper.de> schrieb: >Hi Saulius, > > >So I'd propose to do it this way: $oTheme = oxNew('oxTheme'); >$oTheme->getActiveThemeId(); > >Good point! Thanks for your proposal. I already committed this change to >my repo. And this is exactly what I expect from a dev list: to discuss >technical approaches and make code better. *thumbsUp* > > >Also it is possible to use such a solution in template: >[{assign var="oConfig" value=$oView->getConfig()}] >[{$oConfig->getConfigParam('sTheme')}] > >While I'm a big fan of KISS I don't want to carry complexity to >templates. I'd rather go with getter methods that clearly communicate >their purpose via their method name and additionally capsules >functionality at one point. >I've seen templates where many, many object instances are assigned and >this sometimes makes the template harder to understand than the PHP code >in the controller. So I try to avoid it whenever it is possible. > >I don't know how other developers want to deal with this, but for a >general, longtime solution I'd like to have methods like: > >$oWhatEver->getModuleCssUrl('module-id', '[subFolder]/myCss.css') >$oWhatEver->getModuleJsUrl('module-id', '[subFolder]/myJs.js') >$oWhatEver->getModuleImageUrl('module-id', '[subFolder]/myModuleImage.png') > >These methods could have a fallback; if the requested file isn't present >in the actual theme sub folder it could fall back to a general folder >(just like with the lang.php files). This way theme maintainers could >(but are not forced to) style the appearance of a module component by >copying relevant files to modules/module-id/out/theMaintainerTheme/... > >Best regards, > >Daniel Schlichtholz > >Am 27.03.2013 13:30, schrieb Saulius Stasiukaitis: > >> Hi Daniel, >> >> Thanks for this notice! I also think that the shop could have a better >> option to access an active theme from a template file, hope we can resolve >> this issue in one of the next releases. >> >> Just a short note to your solution: >> There is a slightly better, more generic way to do so. Of course your >> solution would work for you but one shall have in mind that a theme might >> depend on another one. In case that there is a parent - child relation >> between the themes, the child theme ID is stored in "sCustomTheme" instead >> of "sTheme". So I'd propose to do it this way: >> $oTheme = oxNew('oxTheme'); >> $oTheme->getActiveThemeId(); >> >> Also it is possible to use such a solution in template: >> [{assign var="oConfig" value=$oView->getConfig()}] >> [{$oConfig->getConfigParam('sTheme')}] >> >> For sure, it's a bit dirty, but as a workaround it will do what expected. >> >> Saulius Stasiukaitis >> OXID Developer >> >> -----Original Message----- >> From: dev-general-boun...@lists.oxidforge.org >> [mailto:dev-general-boun...@lists.oxidforge.org] On Behalf Of Daniel >> Schlichtholz >> Sent: Tuesday, March 26, 2013 1:18 PM >> To: dev-general@lists.oxidforge.org >> Subject: Re: [oxid-dev-general] Images, Javascript and CSS files in modules >> >> Hi Saulius, >> >> that's the way I did it. All module files should be encapsulated in the >> module folder, like you suggested. But additionally it has to respect the >> active theme in order to be able to style frontend components according to >> the theme. >> Meanwhile I found a working solution. As you can see here >> https://github.com/DSB/Oxid-oTranCe-Connector/blob/master/modules/otrance-connector/core/otc_otcViewConfig_oxViewConfig.php >> I created some getters for my module. >> >> But regarding the fact that each module needs to be able to fetch its own >> css/js/image files, my solution feels dirty. When I think of a shop with 20 >> modules and each implements an own way to get files from within its own >> folder .. no, I don't want to think of that. ;) >> >> Are there any ready-to-use getters I haven't found? If not, I'd suggest to >> add something like that to the OXID core. >> >> Best regards, >> >> Daniel Schlichtholz >> >> Am 26.03.2013 10:16, schrieb Saulius Stasiukaitis: >> >>> Hi, >>> >>> There is no strong requirement where to store JS and CSS files. My >>> suggestion would be to keep them inside your module directory. Create >>> out/src/js/ and out/src/css/ directories so it fit Shop structure and would >>> be easier to debug for other people. You can use something like this to >>> include your scripts in to templates: >>> [{oxscript include=$oViewConf->getModuleUrl("{moduleID}", >>> "out/src/js/{js_fle_name}.js")}] >>> >>> Saulius Stasiukaitis >>> OXID Developer >>> >>> -----Original Message----- >>> From: dev-general-boun...@lists.oxidforge.org >>> [mailto:dev-general-boun...@lists.oxidforge.org] On Behalf Of Daniel >>> Schlichtholz >>> Sent: Wednesday, March 20, 2013 3:41 PM >>> To: Oxid Dev-List >>> Subject: [oxid-dev-general] Images, Javascript and CSS files in >>> modules >>> >>> Hi list, >>> >>> I want to create a module in Oxid 4.7.x that needs to add its own >>> CSS-, >>> Javascript- and Image-Files. >>> What is the best practise to do that? >>> >> _______________________________________________ >> dev-general mailing list >> dev-general@lists.oxidforge.org >> http://dir.gmane.org/gmane.comp.php.oxid.general >> _______________________________________________ >> dev-general mailing list >> dev-general@lists.oxidforge.org >> http://dir.gmane.org/gmane.comp.php.oxid.general > >_______________________________________________ >dev-general mailing list >dev-general@lists.oxidforge.org >http://dir.gmane.org/gmane.comp.php.oxid.general _______________________________________________ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
