WebMacro Script and Framework Design Goals
This document records the main things we want to accomplish with this package. Not all of them are present in the current implementation, but even then they do represent the direction we hope to move in.You should also check my Fundamentals of Servlet Design article, which argues for the Model/View/Controller framework which WebMacro embodies.
Here are the simple, direct goals of the WebMacro framework:
- Templates: Make Simple Things Simple
A template should look and feel like an HTML document; the fact that it has some data stuck into it shouldn't obscure its overall appearance.
A template language is not a scripting language. If you want to have advanced scripting features, you should not use a template language to do that--in WebMacro we expect you to open up a block and write a bunch of real programming code when you want to do that.
80% of the time all you want to do is stick some automatically generated output into a web page. WebMacro makes that simple, while still allowing you to use a full fledged standard programming language in those cases where that just won't do.
So taking a page out of the PERL book, we want to make the simple thing simple--and the hard thing not so bad.
- Programming: Use A Standard Language
We want programmers to be able to develop the cool core of their application using a normal programming language. Other tools, such as PHP, try to re-invent the wheel--they create a whole new language that is not as powerful as Java, and you have to learn it.
Why?
There are perfectly good programming languages out there that work great as it is: Java, C++, PERL, etc.--why shouldn't developers use these for the core of their application?
WebMacro is intended to let web developers go back to using standard programming langauges. For starters, Java--but we'll add more languages as time goes by.
- Clean Separation of Form and Function
We want the programmer and the graphics designer to agree on what the page should contain, and then go off and do their separate things. One will write functions that produce the content; the other will write a template that lays it out.
Of course they will have to communicate--the application will demand it. But now they can spend their time together talking about what the application should do, rather than how to get some extra whitespace into table cells--the web designer can do that on their own, and the programmer can get back to implementing cool functionality.
The intent of the WebMacro system is to cleanly separate work that is programming from work that is page design.
One thing we haven't done yet that we hope to do in the future is allow the establishment of a contract: A specification of what automatically generated content will exist so that we can validate templates and programs, proving that they get along before a problem happens. Look for this in verson 1.1 or 1.2.
- Orthagonal to XML
Unlike every other server side language out there, we did not want to violate the XML/HTML language specifications.
Most languages use odd things like <%...%> that are just completely non-standard. Or they embed tags inside of tags in weird ways. Or they make up tags that don't make sense.
Instead we wanted to be independent of XML. We wanted to create a language that would smoothly interoperate with XML, so you could have a document full of our markup and it would ALSO be a valid XML document.
There is a deeper problem here too: If you are trying to generate XML/HTML output, and you are using XML/HTML as your input, and you are also using XML/HTML as your parsing language--well then you are really trying to do three things with the same parse tree, and it is a bloody mess.
api | design | faq | goals | links | license | othertech | quickstart | script | status