I'm new to angular and I'm looking for a way to achive more advanced templating that one mentioned in the tutorial here
1.) I would like to have a different template for the login page and another one after you are logined
2.) it would be nice to have a functionality of multiple ng-view-s so you can have diferent pieces of the template filed diferently on every url...is it possible to achive this in angular
3.) is there a beter/easyer templating mechanisem to use, meybe some other js framework?
The ideall would be to use something like facelets but on client.
While it is not possible to have multiple ng-views, you can certainly have more than one routes, each one mapped to a controller and a view. It will help to do further reading on how to use controllers, routes etc. You can also use ng-include one ore more times with static or dynamic template urls mapped to a variable in the controller.
AngularJS is one of the best (if not the best) multi-feature JS UI frameworks available in terms of MVCness, extensibility, fine tuning, testing, data binding, templating etc. You cannot generally go wrong with it, just need to spend some time initially getting used to the patterns, idioms and terminology.
I would suggest looking into ui-router for doing nested views.
Related
I have several unrelated pages that use Layout A, and another set of unrelated pages that use Layout B. It's as simple as that, but I can't figure out how to do this in Ember the DRY way.
I understand that template nesting is equal to route nesting, but I do not want to nest routes because it'd mean the URL will be also nested. I want to nest templates only because the pages are unrelated.
What I want to achieve is essentially template inheritance.
I expected this to work, but Ember throws an error.
// app/routes/samePage.js
import Ember from 'ember';
export default Ember.Route.extend({
renderTemplate(){
this.render('somePage', {
into: 'layoutA'
});
}
});
This is the error I get:
ember.debug.js:18015 Assertion Failed: You attempted to render into 'layoutA' but it was not found
I also get this warning. It tells me to read this link, but I don't think it helps me.
DEPRECATION: Rendering into a {{render}} helper that resolves to an {{outlet}} is deprecated. [deprecation id: ember-routing.top-level-render-helper] See http://emberjs.com/deprecations/v2.x/#toc_rendering-into-a-render-helper-that-resolves-to-an-outlet for more details.
Here is what layoutA.hbs would look like. I know you can't have {{outlet}} multiple times in a same template, but you probably get what I want to achieve.
<div class="header">
{{outlet}}
</div>
<div class="content">
{{outlet}}
</div>
<div class="footer">
{{outlet}}
</div>
How do I go about doing this in Ember? It sounds like such a basic task that needs to be more clear. Do I need to implement a template inheritance helper (like the one shown here) by myself? Or perhaps, there's already an Ember add-on for that?
Unfortunately, there is no such thing as template inheritance in Ember. But there are two features that allows to reuse html-code:
Components is well-known feature of Ember. It allows to have a re-usable template and/or js code to control such template appearance and behaviour. Component has it's own context, so all data should be passed to it via properties. I recommend to use components for custom ui elements or when you need to reuse a part of template with some logic (for example, top navigation with user menu which depends on authentication can be moved to component). There is also a trick that allows to emulate template inheritance with components using multiple {{yield}}. Maybe that's what you want.
Partials seems to be less known (they are not even mentioned in official guide for 2.x) but very useful. This helper ({{partial}}) renders any template in current context. I recommend to use it when you need to break a big template into parts.
These features are enough to reduce an amount of duplicated code. You probably can't reduce duplicated code to zero with them, but in my opinion it's not critical. Just move what you can to partials/components and your templates will be clear enough. Use that trick with component and yield if you want to emulate inheritance.
Update
Couple of words about partials
If you google "ember component vs partial", you can see a few blog posts and answers on SO, in which ppl say "don't use partials". In many cases without explaining why. The main points that I found are:
Components are more isolated, decoupled and testable. And I agree with that.
Partials may be deprecated and removed in future. However, that was first said in year 2015, but at this moment partials are still there and not deprecated.
When I suggest to use partials?
When you have a big template that is hard to maintain and you can't drop that route in parts. It happens if you use some css-framework (like bootstrap or semantic-ui) and need to implement a couple of big 3-4 step forms, or add a couple of modals or display some complex entity. Using components in this case is unneccessary (you will not use them on any other page) and their isolation adds headache (you will need to pass data that you need to display as properties and add some action(s) to get user input in case of forms).
Why I suggest to use partials in this case?
There is no need to reuse such partial, we just want to break template for easier maintenance. For example, to have each step of 3-steps form in it's own .hbs file rather than having one big template.
If partials will be deprecated, it's easy to move that pieces back to one big template.
It sounds to me like your solution is pretty simply just to use Ember components. Ember components have their own template which can nested into your route's template with {{name_of_component}}, however using components does not affect the routing.
Perhaps I am misunderstanding your need, but it seems to me like this is the easy fix. Read about it here. If I am misunderstanding the question, please clarify!
What I want to achieve is similar to using named outlets, so I can output some content into a specific place. However, it seems like Ember's recommend way to do this is to use ember-elsewhere.
The documentation says:
Before named outlets were introduced to Ember the render helper was used to declare slots for this.render in routes. This usage is not common in modern, idiomatic applications and is deprecated. In general, the pattern of named outlets or named render helpers is discouraged. Instead use of ember-elsewhere or another DOM-redirection library should better serve these use cases.
I found this add-on to be easier to understand over partials and components.
This, or using partials/components is probably the best we can get as Handlebars do not have a template inheritance feature.
Or, I should be changing the way I'm creating the app, and use routes to do template nesting. That's probably the Ember way.
My question is a bit generic in that my problem is a broad one. I have been working with django for some time, and I really want to move more into doing very dynamic web pages where actual page reloads aren't common.
I have read about the different popular javascript frameworks available, and I always feel like I am missing part of the puzzle, particularly in templating.
What are some of the best practices for keeping my templating code as non redundant as possible. I get the impression that a lot of templating logic will make it's way into the JS in addition to my django templates. I want to avoid situations where I am writing templating code in two different places.
For a very basic example, let's say I am writing some template code inside Django for an input field that has a set number of attributes. I have then also written in JS that when I click on a button, another input field of the same type is generated with all the appropriate attributes. In practice this could be a form that takes an arbitrary amount of e-mail addresses. The problem I see is that when I want to change something about that input field, I need to do it in two places.
Is there a particular development paradigm or work flow that I am unaware of? How are issues like this generally avoided?
Recommendations on frameworks would be amazing too!
as you mentioned above:
Use Django Template language. Pass the data from view to template dynamically.
Read Django Template Language documentation.
For JS :
its better to write your js in home.html.... use {% include %} tag for other html
This issue has been tormenting me for a while already. I've read about this topic but nothing seems to clear my thoughts. I understand that they call the views templates, and the models models as well, what I don't really get is where the controllers are. What django calls views seem to me more like actions/methods/functions of a controller than a controller itself, but anywhere I read, I find that supposed view-controller equivalency.
I've worked with MVC frameworks before (ASP.NET MVC3, Ruby on Rails, PHP Laravel Framework), and they all define the controllers as the same thing: a bunch of functions related to a specific topic of the site, namely user accounts or something like that. The best equivalency that I find between this description and django features are the apps, but of course I'm wrong due to the huge amount of people and documentation going the other way.
Could anybody help me with this? Does my mindset make any sense? Am I missing something essential here and then I can't get these concepts right?
It's a mistake to think of design patterns like MVC as unbreakable rules. They really aren't: there are all sorts of ways of implementing them, which comply with the description to a greater or lesser extent.
This is especially the case in Python, where one of the guiding principles is "practicality beats purity" - in other words, do what works.
In any case, Django makes no claim to be an MVC framework. On the contrary, the documentation describes it as MTV: model, template, view. After all, outside the world of design patterns everyone calls "an HTML file with syntax for variables and flow control" a template, not a view.
(That FAQ entry also offers a possible answer to your question: the controller is the framework itself. But it goes on to emphasise that it's a mistake to try to shoehorn into these definitions.)
The views.py defines the view functions for your app and your app groups related functions together.
However what I believe you're missing here is the urls.py.
The urls file is the first part of the controller.
The URL patterns inside urls.py dictates what you're allowed to pass in to the view function or view class (depending on what approach you took, either with function based views or class based views) and then routes it to the proper view function.
So there's tight a coupling between the views.py and the urls.py, that makes up for the entire Controller part of MVC.
Comparing it to Rails, would be that the urls.py is a routes.rb and the actual controller class is the views.py function/cbv.
The mismatch of terminology is unfortunate but more or less doing the same thing.
You can read the Django FAQ. It explains the how MVC is implemented in django. Regarding controller Django has an answer as:
.
Where does the “controller” fit in, then? In Django’s case, it’s probably the framework itself: the machinery that sends a request to the appropriate view, according to the Django URL configuration.
Could anybody help me with this? Does my mindset make any sense? Am I missing something essential here and then I can't get these concepts right?
The only well-defined parts of MVC where nearly everyone had some sort of consensus is the M; the V and C means completely different things in different web frameworks, to the point where MVC framework really only means as not having all your code in one spaghetti (ala typical classical PHP code). You just had to accept that MVC isn't a really well defined term.
Django is not strictly speaking MVC.
I found this discussion very enlightening:
Django is not MVC
Realy guys:
DJANGO is MVC!
But word View use for Controller.
And Django is Full MVC, but
Model - Model
View - Template
Comtroller - View
I've found absolutely nothing on Google with regard to A/B testing with a client-side framework such as ember.js.
The goal is to serve up adjusted content (different nav items, header phrasing etc.) in order to A/B test our UI/UX. I should note that nothing significant (i.e. sitemap) is changing, just some minor presentational aspects.
There are several possible approaches, namely using different view templates / helper snippets, or serving up a different stylesheet. Both have advantages and challenges, and ideally the same visitor would always be served the same version. Results would be fed through a service like Mixpanel.
I fear I may have to roll my own solution here, but would love to hear any suggestions / pointers.
At their root, most A/B javascript testing frameworks cookie a user as being in the "A" or "B" group, give you a way to ask if a user is "A" or "B" and report "results" back to a service to measure. This can plug into Ember or other client-side frameworks in a way that is fairly orthogonal to the framework.
I would recommend exposing the "A"- or "B"-ness of the user as a property on your user (in Ember, probably your UserController). Then you can use your framework's standard branching or conditionals to render the "A" UI or the "B" UI.
I have actually built a pretty robust A/B Testing tool using Ember for my startup. We are actually thinking of open sourcing it if there was a demand for it. I can let you know the basic idea of how it works for now though.
I have landingPage objects, that can then have a bunch of A/B tests associated with the, When a user comes to the landing page, they are assigned a cookie, and for each A/B test that are assigned either A or B.
I have used two different approaches within jade to handle A/B testing.
For styling type things, I use something like this
and set the .css property in the view to either test-a or test-b
or if it is for text I will do something like this
{{view view.landingPageText}}
and the landingPageText would be set to either the text for A or the test for B.
This thing also dynamically sets up mixpanel, mailchimp, and uses parse.com and node. You can see the code in action here.
http://golf.nextstudioapps.com/
Lets say I have a website with a small application that lists the 10 newest members, or something dynamic like that. I want this to view on every page, perhaps in a sidebar. How would i go about doing this.
My thoughts on the matter. I might not get the whole django thing just yet, but when I have a url like /foo/ calling a view bar - but what info do I have to send to the template from this view. Does every view have to send the info to the template (just so I can view my app) or is there someway to call this from the template instead.
I have tried to read through the documentation, but its seems I just can't understand this.
The usual way to provide '10 newest members' type of information from other apps is via a template tag. See this article by James Bennett on best practices (although note it's a bit out of date, as it was written before the inclusion_tag and simple_tag shortcuts were available).
Create a template tag that you can call on the page
Create a context processor and inject extra context variables onto each pageload
I'm sure there are other ways of doing this but those are probably the most logical two. The first gives you more power and will waste less processing time (for pages where you don't want to display the data) but a context processor is much more simple to write (you don't have to bend over backwards to please the template_tag gods).
Both are valuable things to know so there you go. Go and learn!
"Does every view have to send the info to the template (just so I can view my app)"
Yes.
"Is there someway to call this from the template instead."
No.
Your views are just functions. Functions can call other functions. That's ordinary good design. You can still do ordinary good design in Django.
You do have the ability to provide a "context". This is still done in the views to provide additional "context" for the templates. See http://docs.djangoproject.com/en/dev/ref/templates/api/#writing-your-own-context-processors for writing your own context processor.
Nothing (well almost nothing) is done in the template except render the objects provided by the view into HTML (or XML).
If you have a page that is an amalgamation of stuff from many small apps, then you have two tiers of apps.
Independent Apps.
Composite Apps that depend on Composite or Independent Apps.
Your composite app can call other app view functions to gather data.
Your composite app template can include other app template elements to present that data.
You have all the power of Python to decompose the independent apps into "data production" functions, view functions, template components and final page templates.
An independent app Page will use a view function and a template. The view function will use the data production functions. The template will use template components.
Decomposition still works, even in Django.