Daniel Fagerstrom wrote:<snip/>
I as well. In addition, I think that the optimum template language would be as close to the appearance of the output document as possible. (Yet another reason I don't personally care for explicit forEach, if and chose elements; they make it harder to see at a glance how it will look after processing.)
Tend to agree, I use XSLT (2.0) for all kind of things, and am happy whith many aspects of it, but sometimes it is a little bit of "write only", i.e. it easy to expres things in it (once you get used), but it's verbosity can hide the message, when you try to understand your or others code.
<snip/>
I'm a big fan of namespacing the attribute for reasons of versioning as well as clearly marking which directives belong to which processor -- both for the processor and for the template author.
Agree, no idea why Tapestry don't use name space for marking directives.
A problem with "attribute name as directive" is that xml attributes are unordered. So in the case you need e.g. a double loop over an element, test if you want to perform a loop or do a loop and test each element, a mechanism for deciding the order is needed. TAL uses a predetermined order for the directives. That is far to implicit for my taste and it doesn't solve the double loop. I would prefer to do something more explicit like:
<p tal:define-1="x /a/long/path/from/the/root" tal:condition-2="x" tal:content-3="x/txt" tal:attributes-4="class x/class">Ex Text</p>
Sounds good on paper, sounds like a royal PITA in practice. Determining whether attribute A should be set before the first condition but after the second condition which determines the content... Complexity can rise dramatically and quickly with this. I'd say the template should lose the ability to do a small set of corner cases if, 95% of the time, the simpler syntax has noticeably lower complexity.
Might be, I have not used TAL. When I read about the default ordering I thought that in most cases I will only use one directive, so in the cases where I use several I will need to check the manual anyway. As I want to avoid "to much magic" being explicit seemed better. But maybe the default order is so natural so that you learn it at once?
I think the desire for this comes from the desire to make HTML-oriented templates from the template directives. Is this correct and is this the correct focus?
Stefano's focus seem to be on HTML. My focus is lost long time ago ;) Designing a attribute driven template language seemed like a fun thing to do.
Is it the correct focus? If we find an efficient and easy to understand way of writing HTML templates, it will work well for numerous other XML formats that have similar structure, so it should be important enough. I don't know if the concept of "correct focus" is that relevant in open source development. Things will be done by people who have a itch to scratch, if it seem fun and interesting enough, if it gets enough attention, if influencial people says that it is important and by numerous other reasons.
If the template language is focused on producing semantic XML -- where the XML reflects the structure of the problem at hand and not its presentational form -- simpler syntaxes are much more useful. As is the case with Plone, the focus on HTML output mandates more complex processing options than is otherwise necessary.
I think that having complicated processing options only is a problem if they make simple things complicated. As long as you can resist spending to much time talking about complicated corner cases when you teach the technology, it will work well even for those who are less comfortable with complicated constructs.
If HTML output is a primary design concern and HTML templates are made so much easier/possible, will anyone on a deadline keep SoC firmly in their heads?
Do they now?
IMO HTML already gives you god SoC in many cases. As long as you write for modern browsers, HTML is an excelent language for describing content in a rather wide area. Then you put all styling in CSS.
In more complex use cases or when you have regularity along dimensions that not is covered by the HTML-template/CSS solution, a solution with more layers might be better. But it all depends on the task, excecive layering for simple tasks is IMO an anti pattern.
Once this happens, what advantage does Cocoon have over JSP w/ taglibs? I'm honestly curious.
Cocoon had the advantage that you can put all your side effects in the flow layer, and let the pipeline be completely declarative. Which reduces complexity and make things easier to test and understand. You can in a simple way choose how in how many step you will handle your output based on the SoC you find best for the problem at hand. Also you will get standard components for everything that people find important enough to invest time in it.
If HTML-oriented templates are the norm, and the pipelines would consist of the successor to JXTG and an HTML serializer, what's the point? I don't mean to invoke a slippery-slope fallacy as I think this is a real possibility.
I just can't see this as a problem, If people can solve simple things in a simple way, isn't that much better.
In my webapps I use short pipelines for some stuff and long for other, it all depends on what problem decomposition I found reasonable and wortwhile.
I doubt that the people who constructed pipelines in UNIX consider it a failure that UNIX have so many well designed commands for simple tasks, that most of the time the commands are executed without being in a pipeline.
When the XML and the logical data structure are intimately related, things tend to fall into place with a minimum of decision making. Then transform. Then serialize.
In many cases yes, in many other cases no ;)
<snip/>
So much for avoiding the complexity of a general programming language. Simpler may leave fewer options, but that's not always a bad thing. If all options need to be handled, you're looking back at XSP, the ultimate in this area.
It doesn't have side effects and it have quite limited access to data in Cocoon, thats important differences.
Several directives ------------------
So, how do we handle multiple directives for one element? We could handle the TAL example above like:
<p do="let(x=/a/long/path/from/the/root;if(x);content(x/txt);attributes(class=x/class)">
Ex Text </p>
Yeah, that's what I thought. I pity the template writer that much content with someone else's templates.
No one forces you to use it, it will not hurt you as long as you don't use it, as the syntax is simple for simple cases. The example was taken from the TAL manual for illustrating a mechanism, not for being a realistic example.
I still think macros should be handled in transformations rather than Java code, but there it is.
Macros are written in the template language it self, no need for Java or a foreign transformation language. Basic directives like if are written in Java.
/Daniel
