Migrating from an MVC-pre-Core project to a Core 2 version I'm shocked to find #Scripts & #Styles are removed. I had relied on being able to use #Scripts.Render("~/bundles/myApp") as a short cut that imported a half dozen files on any page that needed them. Now I have to spell all those files on each page that needs them?
Any way to replicate the behavior. Have glanced at Gulp but seems more like exclusively a processor for deployments.
The Scripts.Render and Styles.Render methods don't actually do anything other than add a simple tag to the generated HTML. The meat of what you're talking about - having a bunch of script/styles rolled up in one call - is the bundling provided by MVC. In ASP.NET Core, the method of creating those bundles has simply changed; that is all.
Now, you have bundleconfig.json, instead of BundleConfig.cs. Instead of calling Scripts.Render to include the bundle, you simply reference the bundled script directly. Likewise with your style.
By default, there is a single bundle for each site.js and site.css that are "bundled" (and minified) into site.min.js and site.min.css, respectively. So, you'd just do:
<environment names="Staging,Production">
<script src="~/js/site.min.js" asp-append-version="true"></script>
</environment>
The environment tags simply determine when this HTML will be included in the output. Here, that's only when the enviroment is Staging or Production. The script tag is a hard-reference to the "bundle". This is functionality equivalent to what you would have achieved with something like:
#Scripts.Render("~/bundles/site")
Which, itself, would only have rendered the following script tag:
<script src="~/bundles/site?v=abc123"></script>
In other words, you don't need the Scripts.Render and Styles.Render methods, since they're pretty useless actually. Even in previous versions of MVC, you could have avoided them and just created tags directly pointing to your bundles.
For more information on how bundling and minification works in ASP.NET Core, see the documentation.
Related
I am using in my Nativescript Angular app the nativescript-google-maps-sdk plugin which works great.
My issue is that I want to use cached images to display in a custom InfoWindow. For this purpose I am using the nativescript-web-image-cache plugin app-wide. When I use the regular <WebImage> tag in the infoWindow it complains that it is not a registered component:
Module 'ui/web-image' not found for element 'WebImage'
Everywhere else in the app it works just fine. In this issue is it suggested that:
that InfoWindowTemplate content is parsed as Vanilla NativeScript XML, not as Angular XML thus it is not able to find custom Angular Component you created
So the question is how can I still use this plugin? Is there a way I can somehow register the <WebImage> component so it will work in the custom InfoWindow?
Just to make sure there is not another issue, I added the nativescript-web-image-cache plugin to the plain NativesScript nativescript-google-maps-sdk demo project and then the <WebImage> tag works just fine.
Any pointers are highly appreciated!
Anything registered in Angular is not available in Core the same way; so if you have to create a core template; you must also pass in the xmlns:blah="ns-blah" as part of the core template, so that it is registered properly in that core template. The angular registerElement does not do anything for Core. Now you can easily do <IC:WebImage xmlns:IC="nativescript-web-image-cache" ...> and then it is valid in the template. However, I would recommend you put the xmlns:IC on the topmost element you can; as it makes reading the code a lot simpler. But in cases you don't have a parent wrapping element around the item, this is valid code to register it on the same element using it.
NS-Core templates are different than NS-Angular templates; if you attempt to use things that work in Angular like <IC:WebImage [param]="value" (param)="value"/> both the [param] and (param) will totally break template parsing in core. NS-Core's parser is like HTML, nothing is supposed to surround the param and the value should be in quotes. The value can have {{ boundvalue }} to bind a dynamic value into the template.
Normally when passing a NS-Core template into whatever function you need; you want to pass in just the minimal parts; you rarely need to use things like <Page>, <Frame> or any other top level elements. In fact this can cause problems. You normally need just the piece of the layout you are going to have it view. So in this case <StackLayout xmlns:IC=...><IC:WebImage...></StackLayout>
Finally when troubleshooting using Core features in Angular; I highly recommend you put fixed Width/Height and Background colors on each element. This can sometimes show you what is failing.
As InfoWindowTemplate content is parsed as Vanilla NativeScript XML, you could add xmlns:IC="nativescript-web-image-cache" to the root / parent element of your component. Also use <IC:WebImage> instead of WebImage.
I want to make an extension that injects videos on product pages.
I already read a lot of documentation in Magento website but, sincerely, I have no clue where to start. What's the difference between Magento Extensions and Widgets? Can I develop my extension using only JavaScript? Do I really need to use PHP to develop one?
So many questions, can't find a focus. Can you please share a simple follow trough for me to read on? Thanks.
Credits : Marius
https://magento.stackexchange.com/questions/8344/how-to-write-a-custom-extension/8345#8345
Here is what I usually do:
Always develop with error_reporting on.
Always develop with isDeveloperMode set to true. Just add SetEnv MAGE_IS_DEVELOPER_MODE 1 to your httpd.conf file (or corresponding file for nginx or something else)
If the extension is linked to a core functionality add the
dependency in the declaration file <depends><Mage_Catalog /></depend>
If the module is for community use, use community as codepool to
give the developers the chance to override some classes without
modifying the code directly
Put your frontend design files in app/design/frontend/base/default
to make them available for all themes.
Put your admin design files in
app/design/adminhtml/default/default and do not change the admin
theme. I may want to change it in one of my modules.
Prefix your layout file names and template folder name with the
company name to make it easier to isolate them.
easylife_articles.xml and app/design/.../easylife_articles
Put your static resources (js, css, images) in a similar folder as
the template files easylife_articles/images/doh.png
Attach a simple text file with how to uninstall the extension: What
files need to be removed, what tables need to be dropped, what
config settings need to be removed from core_config_data table.
Do not write queries directly in models, blocks or helpers, use a
resource model for that.
Do not write queries using the table names directly Select * from
sales_flat_order where .... Use a Zend_Select and transform the
table names using ->getTable('sales/order').
Use the base url to include js files in template. Wrong
<script type="text/javascript" src="../js/some.js"></script>.
Right <script type="text/javascript" src="<?php echo Mage::getBaseUrl('js').'some.js'?>"></script>
Do not rewrite classes unless is necessary. Use observers and if
it's not possible use helper methods that receive as parameter and
instance of a class that you wanted to override. Wrong:
Override Mage_Catalog_Model_Product to add the method
getProductArticles(). Right. In your helper add
getProductArticles(Mage_Catalog_Model_Product $product)
If you override classes put a list of them in a readme.txt file
Use the default admin path for the admin section of your module.
Wrong admin url articles/adminhtml_articles/index. Right admin url admin/articles/index
Add ACL for your admin sections. I may want to restrict access to
some of the admins.
Do not add an other js framework (jquery, mootools, ...) if it's not
necessary. Write you code in prototype.
Make you template html W3C valid (this is for OCD developers like myself).
Do not put images in the media folder. Use skin. The media
folder usually is not versioned and this makes it harder to move the
website on different environments.
Test you extension with flat catalog on and off. In order not to double the development time use Chaos Monkey
Test your extension with cache on and cache off.
Avoid using uppercase letter in the module and class names. If not
properly tested this may cause issues on different OS. This is more a recommendation, not a 'must'.
Dispatch events in your code to make it easier for developers to
alter the functionality.
Follow the same coding standards that Magento uses and comment your code.
[Edited] Do not use php short tags (<? $this->doSomething() ?>). Use full tags (<?php $this->doSomething()?>). Also don't use short echo tags, yet. (<?="D'oh";?>). Use (<?php echo "D'oh";?>)
Translate your texts using $this->__ and add the locale translation file with your texts (app/local/en_US/Easylife_Articles.csv) at least for en_US language. Not all
websites are build in English and the identification of texts to
translate is time consuming.
If you sell an extension offer at least basic support. Or at least
answer the support e-mails you receive.
Do not make constant calls to your servers through your extension for licence validation. Once, at installation is more than enough (I don't like this approach either, but it's better than to make calls all the time).
(Inspired by this question)
Develop with the log activated and from time to time take a look at
the var/log/system.log file. The errors listed here are not shown
even with developer mode on. If there is at least one error you end
up with a large log file after a few months of running the extension.
If your extension affects the checkout process or the orders in
some way, make sure it works with multi-shipping, or if it
shouldn't work with multi-shipping, make sure it doesn't affect it.
Do not replace the default Admin Notification bar (or feed URL). If
I'm interested on what you have to offer I will subscribe to your
newsletter. Let me see what Magento has to say. It's more important
to me.
If you encrypt your code files with Ioncube (or something
else)...well...I just hate you and I hope your business goes bankrupt
That's what have so far. I will add more as soon as I think of something else.
You will definitely need XML and PHP, because this is mainly what Magento is built on.
Additionally to the official documents, there are a lot of helpful and very diverse tutorials out there that explain the mechanics of Magento. A web search helps, and I can recommend everything by Alan Storm, for example this litte module: http://alanstorm.com/magento_list_module
As soon as creating an extension works for you, you will also find a lot of tutorials on how to alter the product-view, or you can then post a more specific question here or on magento.stackexchange.com.
I am looking to use Backbone Marionette in my application with RequireJS. It looks very promising,especially the Views and Regions. I would like to use them in my application but use some of the existing features already present in my application.
For example,I would like to use my existing Event Aggregator instead of Backbone.Wreqr. Can I do that? Is Backbone.Wreqr hard dependency for Marionette or can Marionette work without it?
Also I would not like to include pieces of Marionette that I do not plan to use in my application, like modules, templateCache, etc.
Is it possible to have a trimmed version of Marionette?
Thanks
Chintan
Currently, Marionette has hard dependencies on multiple libraries. From it's documentation:
Prerequisites
Marionette relies on Underscore, Backbone, jQuery, and various other libraries as its foundation.
JSON2.js
jQuery (v1.7, v1.8, v1.9)
Underscore.js (v1.4.4)
Backbone.js (v1.0.0)
backbone.wreqr.js
backbone.babysitter.js
As far as picking and choosing features, Marionette's code is split up nicely with each main feature in it's own file. You might be able to copy the repo and do one of the following:
AMDify each feature to use with requirejs
Piece together the files/features that you want and amdify the resulting combined file
Rip out the features that you don't want from the generated amdified file.
With any of the routes, be sure to get the dependencies between the features lined up correctly (i.e. Layout depends on ItemView, which depends on View, so you'll need to keep View and ItemView if you intend to use Layout).
I have an annoying problem with my new grails app. I'm trying to mock up a design for a site that I will be making but whenever I do changes in my css it won't affect the running application. No matter how big changes I do I have to stop the application and then run it again.
This is very frustrating, I've turned of cache in Chrome and even if I go to the specific document the resource is still the old. What can I do to solve this problem? I can make changes in my gsp files and the changes will appear but not in my css.
I am currently loading the resource within a layout file like this:
<link rel="stylesheet" href="${resource(dir: 'css', file: 'app.css')}" type="text/css">
If you need me to provide any more information, please just ask. I am using grails 2.2.0.
Add this to your Config.groovy (probably just for development)
grails.resources.debug = true
Read the docs for more info.
It looks like Gregg's answer doesn't work for 1.3.7 (maybe that is something added in 2.x?). A method I found that makes quick CSS updates possible is to include a separate GSP as a template in the page header.
That is, create a file called "_css.gsp" (underscore prefix is required) in the same directory as your view files, fill it with standard css surrounded by html style tags, and then include the following in your layout header or page:
<g:render template="css" />
With that in place, the content of _css.gsp is injected into the page. And I can make changes to _css.gsp and they are immediately reflected after page refresh without having to restart Grails. Hope this helps someone in Grails pre-2.x!
I have an action with
def new
#test_var = 'i want this to show'
end
All I want to do is inject that into the javascript called for that page. For example:
#app/assets/javascript/my_model.js.coffee.erb
$ ->
console.log('<%= #test_var %>')
I'm guessing this doesn't work because that the coffeescript/erb is compiled before the controller is accessed...so, if I wanted to inject controller variables into a JavaScript file (client side - NOT accessed via ajax) in 3.1, how should I go about doing it?
I believe the problem is that you're thinking about the asset pipeline all wrong...
asset being the operative word.
It's not a view pipeline. Other things which are assets? images & css files, things which can be preprocessed and then served as-is. The erb/preprocessing of your assets doesn't occur on each pageload/request, rather it occurs on startup/filechange so in production said assets can be optimised, cached and served statically.
You could probably figure out a way to achieve it using Live Compilation (see section 4.2 of http://guides.rubyonrails.org/asset_pipeline.html) but as the docs say:
This mode uses more memory and is lower performance than the default. It is not recommended.
The bad answer would be 'inject the javascript into your view', but decoupling your javascript from your rails controllers/views is a good idea.
A better answer would be to have an asset folder containing all of your controller javascripts, and use some "what page am I on?" javascript to determine whether to run the code or not.
Here's some answers that explain various approaches to this:
Rails 3.1 asset pipeline: how to load controller-specific scripts?
Using Rails 3.1, where do you put your "page specific" javascript code?