I have a piece of code that I would like to have show up on several areas... from two different views. Which is to say handled by two different controllers (all the data comes from a helper though) what is the best way to break this up, should these partials be rendered then as lay outs? Though they use the twitter bootstrap modal and I have had huge issues getting those to show correctly when called from a layout (most the reason why I have to break up this code into a partial, one that comes from one index.erb.html and another that comes from a partial of its own _document_header.erb.html good time to ask, can you stuff one partial within another...
so just trying to get some pointers. This code is really common to two views.
(and is not always needing to be rendered or displayed)...so want to do this the best way.
You can reference a partial that is anywhere in your views folder.
It's common to make a "shared" folder in your views and reference the partial like: <%= render 'shared/my_partial' %>
Related
Can somebody give me an eagle eye perspective on Magento blocks, layout and templates and how they relate to each other?
I understood that blocks are the basic building-blocks that a page is made of and that they are kind of mini-controllers.
I also understood that layout brings these blocks somehow together.
But there is still some uncertainty about templates and how they relate to blocks and layouts and vice versa.
What are blocks?
There are basically 4 things you need to know:
There are two types of blocks: those that automatically render their
children and those that don't. Knowing which type you're using will
help you in debugging.
Magento blocks are essentially models that contain logic for your view templates. Mind you - this is not business logic, but it is logic
related to the display of the information you're presenting. This is
by definition presentational logic. If you're familiar with Zend
Framework's Zend_Layout you could draw a comparison between custom
view objects and layout helpers.
The template file assigned to a block object can execute code as if it is local to that object. That is, $this corresponds directly to
the block class.
Layout actions are a thing that people use.
Two types of blocks
There are two types of blocks at the end of the day - those that
render automatically and those that don't. Take notes because this is
on the Magento Certification exam!!
Auto-rendered blocks
When defined in a layout, any block of type core/text_list will
automatically render all its children. While core/text will
automatically render itself it really only should contain text and
therefore is not useful for layout purposes (though some clever things
can be achieved with them).
Other blocks
Any other block type will need to be rendered manually. Provide the
block an alias which can then be passed to getChildHtml, returning the
content which you then echo.
Layouts And Templates
As the name suggests, layout files are useful in rendering front pages
of Magento. Layout files are XML files that reside in in app > design
frontend > your interface > your theme > layout. Here, you can see that there are many layout files for any given module. Each Magento
module has its own layout files much like the customer module has the
customer.xml layout file, catalog module have catalog.xml layout file
etc. These layout files contain structural blocks and content blocks.
read the following blogs. it will clear your concepts for magneto.
http://alanstorm.com/category/magento
http://devdocs.magento.com/guides/m1x/magefordev/mage-for-dev-4.html
http://blog.philwinkle.com/the-most-misunderstood-concept-in-magento/
http://code.tutsplus.com/tutorials/custom-layouts-and-templates-with-magento--cms-21419
Blocks are the building modules of a page. They can be treated as "bricks". Now every block comes inside a layout. Layout is used to define the "shape" of the page. Now templates are used to define the behaviour of a particular block. That means each block or "brick" will have different charateristic depend upon the template it is used.
That is, to construct a magento page, you need to define a layout first that will give you an idea of shape of that page. Now you fill the layout with blocks. Each blocks now concentrate on a particular section of the entire layout. That means depending upon the "nature" of block, each small section will behave differently. To define the unique nature of a particular section, blocks uses templates (templates actually holds the webpage building codes, ie html + js + php)
I hope that will give you a short idea.
Try to google this. I am sure there are lot of lot of tutorials, blogs available about this.
Currently, in our deployment we have a abstract type Component which represents a part of our Page, basically an element such as a Question, which can have multiple choice, a text box or any other form of answering it, or a Video that users can play, basically a shard of a page that is interchangeable, basically, our design was to have a specific area in our website which would be rendered through a list of Components, we tried at first to have each "Page" object have a List of Components, and each Component would have a method render that would return a Spring View, we thought we could iterate over the list and somehow mash the views together.
We also tried using XSTLViews with no more success, it seems to be more of a design problem and our abuse of the way Spring MVC should be used.
We will really be glad to receive any advice/tips/corrections about how to do it right and maybe some corrections about misconceptions we might have.
It sounds like you're more than half way to a design that uses AJAX to build your page. You're trying to mash up a bunch of Components into one request. What if you returned a container page which then requested/inserted a block of html for each URL it was given a render time. Each of these URLs would refer to a single component. It might be a performance hit if you are including a lot of these Components, but it seems to fit the design.
I am writing a helper class to query my Zenfolio feed, return and display the images. Right now this code is split between a viewmodel and code in my controller. I want to pack it up into a helper class. Would all the code go into the helper or do i still split the code among different class with the helper only responible for generating the html? I have googled but not found an answer to my question.
Within the MVC pattern there is a clear separation between Model (data), View (html) and Controller (what gives the Model to the View).
To answer your question, No. Load your models in your Controller. Display them in your View. Html Helpers should only generate html for your view.
You may want to consider using a DisplayTemplate, which allows you use the same View template for every model of a particular type.
I wouldn't do any data access from the view. This sounds like a good use case for an action, and reusing code via the RenderAction method. You can mark the action as a child action using the [ChildActionOnly] attribute, which ensures it can't be invoked directly from the HTTP request, and return a PartialView result.
HTML helpers should really be used to generate HTML tags from data taken from the ViewData or Model (i.e. your view model in this case).
Data access in an HtmlHelper is only pain.
I've had the misfortune to inherit a project that had ad-hoc SQL placed into the HtmlHelpers by the 2nd developer on a project. The HtmlHelpers were beautifully written by the first developer, and the ad-hoc SQL pretty much nullified all of the time and effort put into having an service oriented architecture, having an ORM (the 2nd level cache became worthless), the unit of work pattern(transactions, worthless), and every aspect of design. Eventually, this 2nd developer had to make larger and larger HtmlHelpers so that different elements could share access to the data.
This was originally done for a display mode, and editing was accomplished through a pile of ugly custom javascript. All told, when the page rendered, it made 600 synchronous calls to the database.
How can we render many partials from different controllers into one view?
The local variables of each partial are calculated separately in different and independent controllers.
What I really have to make things more specific, is a home layout, and in that layout that has dynamic content, there's a partial that only handles site wide news announcements, and these are independently updated.
I know a quick hack such like:
render :partial => '/news', :locals=> {#news = News.last}
but I want something more "correct". Like I've been reading about :templates rendering but i'm not sure how it works exactly in Rails 3.1.
Any help would be highly appreciated!
2.2.3 Rendering an Action’s Template from Another Controller
What if you want to render a template from an entirely different controller from the one that contains the action code? You can also do that with render, which accepts the full path (relative to app/views) of the template to render. For example, if you’re running code in an AdminProductsController that lives in app/controllers/admin, you can render the results of an action to a template in app/views/products this way:
render 'products/show'
Rails knows that this view belongs to a different controller because of the embedded slash character in the string. If you want to be explicit, you can use the :template option (which was required on Rails 2.2 and earlier):
render :template => 'products/show'
Sources: http://guides.rubyonrails.org/layouts_and_rendering.html#using-content_for
Should have read in more details.
I've read a couple of articles on using asp.net mvc3 razor (which I am fairly new to). I have a couple of .cshmtl pages which are like shared content (e.g. header). They are basically just html pages with one or two divs etc.
To embed this in my main page, do I just use #renderPage("page address"). Do I also need a call to #renderbody? Do I need to specify the/a page in the layout property?
Thanksa
I would put the common elements in a layout (or perhaps a partial view rendered by the base layout). In fact, that's what I did in an application I am now building and it works quite nicely. The one issue is whether or not you need View Model data populated by the controller and passed to that partial view. I did, so I used a base controller and populated the common elements in the view model (all of those also inherited from a base class that had the common properties) and used sections and then in the sections renderered the partial view or not, depending on the view's need.
You can create a Partial View for each of these and call:
#Html.Partial("ViewName")
Or you can use sections, or this article on sections might help too.
As you may or may not know, ASP.NET accepts HTML tagging.
So why not include your .aspx file with the HTML include tag?
Here's how:
<!-- #include virtual="path to file/include-file.html" -->
Ex:
<!--#include virtual="header.aspx"-->
I do this all of the time when writing an ASP.NET website.
Just place it wherever you want the code, from the included page, to show up.