Hi everyone, I created a plugin in order to combine and minify scripts and styles automatically and which uses the oxscript and oxstyle smarty functions (so there is no code to change in templates). It is based on the Minify project (https://code.google.com/p/minify/). You can see it working here : http://www.takeitweb.fr/modules-oxid/ . I didn't want to release it in public for now because i wanted to improve it with others performance optimisations. But if some of you are interested to "beta-test" it in your projects, don't hesitate to send me an email and i will give you the module.
Best regards, Nicolas Hodin www.takeitweb.fr 2013/3/28 Matthew Setter <[email protected]> > 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 >
_______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
