Can somebody give me an eagle eye perspective on Magento blocks, layout and templates? - magento

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.

Related

How to deal with code duplication when natural templating (e.g. Thymeleaf)?

Thymeleaf puts a large emphasis on "natural templating", which means that all templates are already valid XHTML files. I always thought that is a great step forward that I can generate fragments in my templates e.g. in JSP I'd write
<tagfile:layout title="MyPageTitle">
<jsp:body>
Main content goes here
</jsp:body>
</tagfile:layout>
My "Layout"-Tagfile contains all the header-tags (title, link to stylesheets,...), the menu and justs inserts title text and body at the right point. I don't need to know anything about stylesheets menus or the like when designing my html fragement.
This is in contrast to the idea of Thymeleaf which encourages me to create full html pages (including a sample menu and all the headers). While the manual of Thymeleaf continues to emphasise how great this is, it never deals with duplication of code concerns:
I have one template that generates a menu and all my other templates (could be many) include a copy&pasted dummy menu just so that I can view the template in a browser without the server side generation mechanism. If I have 100 templates that means that prossibly the exact same dummy menu exists 100x (in each and every template). If I change the look of the menu it's not done with creating a new dummy menu, but I need to copy&paste the new dummy menu into 100 templates.
Even if I decide to do something as simple as renaming my CSS file I need to touch all my templates as well.
There is always the danger that my template looks just fine in my browser, but the generated output is broken because... well... I broke it (could be as simple as a misspelled variable name). Thus I will need to test the output with the actual generation anyway.
Did I misunderstand something there? Or is this indeed a trade-off? How do you minimize the impact of code duplication?
Natural Templates are just an option in Thymeleaf. As you can read here http://www.thymeleaf.org/layouts.html there are many options, including a hierarchical layout approach like the one you seem to prefer (I recommend you to have a look at the Layout Dialect).
However, Natural Templates are the preferred and most explained layout option because Thymeleaf was thought from the ground up to allow you to do static prototyping (in contrast to most other template engines). But it doesn't force you to.
So.. how are Natural Templates applied in the real world to avoid code duplication becoming an issue? That depends on the scenario, but one pattern we see repeated a lot is people creating full document, natural templates for 3-4 or maybe even a dozen of their application's templates, only those that are more likely to take a part in the design process --exchanged with designers, with customers...--, and simply not apply that header and footer duplication in the rest of the application's templates, making their creation and maintenance much simpler.
That way you can have the best of both worlds: a means to exchange fully displayable pages between programmers, designers and customers for the pages that this is really relevant; and also a reduced amount of duplicated code.
What's more, thanks to libraries like Thymol (referenced in the article linked above) you can even avoid code duplication completely, allowing your fragments to be dynamically inserted via JavaScript when you open your templates directly in your browser without running the application.
Hope this helps.
Disclaimer, per StackOverflow rules: I'm thymeleaf's author.

Joomla - How can I opt one from various modules to display in a position

I am willing to create a logic in which If I can fetch only desirable module in a particular position.
As we know that Joomla displays the module on basis of positions given to modules created, hence there could be several modules for a single position.
Now what If I only want a single module from those modules who has the position, say "positon-1".
Thanks
Each module can be told to be shown only on specific pages. Look in the module settings at the "Menu Assignment" part. There you can set it to show on
all pages
No pages
Only on the pages selected
On all pages except those selected
So you can set a module to show on the homepage in position-1, but on all other pages there is a different module shown on the same position.
Don't position names like position-1, although the example templates shipped with Joomla! do so. Use semantic names for the module positions. Then, within your template, you define, where these positions live.
Now what If I only want a single module from those modules who has ... [a certain] position
That will never happen then. You're going to have a position called search where the serach field is located, and maybe another one called navigation, where you publish your navigational menus. You get a lot more positions, but also much more flexibility. So if you have a module that needs its own position as in your question, let's have it that.

Joomla 3 Article alternative layout

I've created an alternative layout for one of my articles which can be applied successfully, but as has been highlighted in various forums: if you view the article using the Single Article menu type the alternative layout doesn't get applied because of an XML override.
I have a Joomla site that is setup for Sales and Support where the article info such as date, hits etc is useful but on the marketing side none of that is needed, hence an alternative layout would work well.
I want to know how to enable my alternative layout using the Single Article menu type - I've already got the layout how I want it (testing it by having it overwrite default.php) but want to set it up as marketing.php instead and only have it applied to what is needed.
You're probably not going to like this answer because you have already written you're alternate view. If you were rewriting it to begin with, why would you not write in a way that the side bar parameters (date, hits, ect) are within a container that is only loaded conditionally. This way you would only have one view to worry about and a lot less headaches.

magento - include core functionality in custom module

I've recently made my first couple of simple modules for magento. Basically just trying out making a module that printed 'hi'. Then one that included the site design, and finally one that inserted it's own block into the content area to print some stuff.
Now, what I really want with this module is to be able to list products (using the same layout as normal product listing) but based on ID's. Like from cookies or as an example, static array of product ID's.
How would I go about to reuse the product listing code as much as possible and retaining the theming for it? Also if there is some small detail I wanted to change in the layout - how could i make a small template adjustment on the fly/programmatically?
Is this even the right way to go about it, to create a new module and somehow include existing functionality in it? Or should I just try to recreate the product listing and mimic the design?
Lots of questions I know, but it's hard to find relevant information beyond the very simplest modules. TIA.

Magento xml layouts - before="-" not working in 1.4.2

I have some custom extensions. They're shown in the right sidebar, and I previously had them appearing directly underneath the sidebar cart, which appears at the top, as it has before="-" in the checkout.xml file.
Since upgrading to 1.4.2, my custom extensions now appear at the top of the sidebar. I've added after="cart_sidebar" to the extensions xml layouts, but they still appear above the sidebar cart regardless.
Changing the order of the extensions, they only move amongst themselves, always at the top - for example, if I add after="-" to any of them, they just appear after the other custom extensions, but still at the top above the cart and other default sidebar items.
Anyone any idea why?
UPDATE:
I turned on the "Template Path Hints", and for my custom sidebar blocks, the red text showing the template paths appears further down the sidebar, where the block should be showing, but the actual html of the block is appearing at the top of the sidebar still!
Before trying to find out what's happening in here you should notice following:
All Magento modules and extensions are loaded in such an order that they meet their declaration section requirements (xmls in app/etc/modules/). So that modules that depend on other modules are loaded only after them.
If modules are equal by their needs, then priority goes to 'Mage' namespace, then to custom modules namespaces. Inside namespaces priority is given by alphabetical order.
Module layout configuration is created during module load. So result of "before" and "after" instructions depends on blocks already added by previously loaded modules. I.e. when some block has 'before="-"' instruction - it places block first, but later other blocks from next modules can use their instructions to be attached before this block.
Now let's return to your case. Your problem can have multiple reasons heavily depending on your Magento configuration.
First of all I recommend to
Turn off whole cache - so that you'll see all changes instantly
Turn off all your extensions and test things only with one of them
Turn on default Magento CE theme and skin ("default" package)
Then check following cases:
Maybe your layout scheme is modified and your extension not referencing correct block (same as "cart_sidebar" uses) to put self in.
Maybe some extension deletes original cart_sidebar block and then puts it last in queue of blocks.
Maybe some CSS or JS rules place block only visually before other blocks (check blocks order in original html source)
Maybe some extension is modifying layout composition rules. Try to turn only one of them. Then try to turn only other one and check result.

Resources