Hi,
I Don't think that's feasable since quite a few (especially smaller) Shops Don't Do any real deployment other than copying the Files on their ftp Server. Thus depending on a Build System for stylesheet changes doesn't seem the right way. -- ooxi Violetland — An open source cross-platform game similar to Crimsonland — http://violetland.github.com Matthew Setter <[email protected]> schrieb: >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
