What about integrating Grunt (gruntjs.com) into Oxid? Matt ________________________________________ From: [email protected] on behalf of Kristian Hempel - D³ Data Development Sent: 28 March 2013 09:38 To: [email protected] Subject: Re: [oxid-dev-general] Images, Javascript and CSS files in modules
But a developer needs a "develope/debug mode", which don't minify and combine theese files. Best regards Kris -------- Original Message -------- Subject: Re: [oxid-dev-general] Images, Javascript and CSS files in modules (27-Mrz-2013 20:07) From: Kai Gazmaga <[email protected]> To: [email protected] > +1 for this approach! It would be nice to have automatic combination and > minifying of JS and CSS in the core anyway! Regards, Kai ----- > Ursprüngliche Nachricht----- Von: [email protected] [ > mailto:[email protected]] Im Auftrag von ooxi > Gesendet: Mittwoch, 27. März 2013 19:55 An: [email protected] > Betreff: Re: [oxid-dev-general] Images, Javascript and CSS files in modules > 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 <[email protected]> > 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- > [email protected] >> [mailto:[email protected]. > org] On Behalf Of Daniel >> Schlichtholz >> Sent: Tuesday, March 26, 2013 > 1:18 PM >> To: [email protected] >> 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/otr >> > ance-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: [email protected] >>> > [mailto:[email protected]] 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 >> [email protected]. > 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 > > [email protected] >http://dir.gmane.org/gmane.comp.php.oxid. > general _______________________________________________ dev-general mailing > list [email protected] http://dir.gmane.org/gmane.comp.php. > oxid.general _______________________________________________ dev-general > mailing list [email protected] http://dir.gmane.org/gmane. > comp.php.oxid. > general _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
