John, In my example <div class="<gae:if="field.required" /> would never happen, as that would not be a legal XML construct; also a decision construct would never be exposed up in the HTML/XML of the layout. The intent is to completely remove the logical operations from the interface the designers use to layout what is displayed. I find that when the designers I work with have to deal with managing variables, conditionals and loops, "interface code" ends up copied all over the system and when the interface behavior has to change we end up hunting down tens or hundreds of occurrences of interface logic.
My example is not really very original, it is very much how ASP .Net and JSP custom tags, work. In these systems, there is the Layout, the interface logic, and the business logic. All as separate objects, essentially the Model, View, Container pattern. The templating frame work should read the XML of the page, see the <gae:list of="greetings"> element, and call the list handler, which would retrieve a list of greeting objects, using the HTML found inside the <gae:list> tag as the template used to render each item in the list. As for deciding what HTML to display based on the data passed in, that is exactly what the YAML and WebApp handlers are for. On Jan 2, 3:14 pm, johnwlockwood <johnwlockw...@gmail.com> wrote: > the idea is to separate the business logic from presentation logic, > (here is a nice > articlehttp://www.paragoncorporation.com/ArticleDetail.aspx?ArticleID=21) > not necessarily make everything in a template be xml, which can > sometimes make things more complicated. > You have to introduce namespaces(designer says "name what?"). > Putting an xml tag as an attribute of an html tag can make things > nasty, such as: > <div class="<gae:if="field.required" /><gae:string > name="required_class" /></gae:if>"></div> > vs. > <div class="{% if field.required %}{{ required_class }}{% endif %}"></ > div> > the first is, I believe, ironically, invalid xml, and the second is > valid xml. > > django's template language has relatively simple logic. Just present > the data that is passed to the template. > > In presentation logic, there are many times you have to decide what > html to display depending on the data passed to you. > If each time that was encountered by the designer, they would have to > think about the logic anyway and then ask a programmer to write a > function to return one piece of html if a certain piece of data was > true and another if false, and then pass that to the template. Then > they would have to learn the new xml tag to insert to get that piece > of html. very complicated. > > On Jan 2, 11:40 am, Kelly A <kelly.j.ander...@gmail.com> wrote: > > > > > I have this problem with most templating systems, they talk about > > separating code from HTML but then they define all these programming > > constructs like if, while, for, etc.. For instance given the example > > from the getting started guide: > > > <html> > > <body> > > {% for greeting in greetings %} > > {% if greeting.author %} > > <b>{{ greeting.author.nickname }}</b> wrote: > > {% else %} > > An anonymous person wrote: > > {% endif %} > > <blockquote>{{ greeting.content|escape }}</blockquote> > > {% endfor %} > > > In the above "HTML" there are five lines of code, this is not > > separation of code from HTML in my book. There is no ifs, ands or > > buts about it, that is code, if a designer looked at that they would > > say that is code. If this were HTML separated from code it would look > > more like this: > > > <html> > > <body> > > <gae:list of="greetings"> > > <gae:listItem > > > <div class="name"><gae:field name="author.nickname" /></ > > div> > > <blockquote><gae:field name="content" /></blockquote> > > </gae:listitem> > > </gae:list> > > > The developer/programmer would handle the case statement and the > > iteration back in the code where it belongs. All the designer needs > > to know is that this will display a list and the list item allows the > > designer to layout and style each element in the list. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
