Proposal Title -------------- Web Unifying Markup (templating) Language, or WUML
Background ---------- As a freelance developer having built entire platforms of Django, I find the most time consuming part of web development to be the front end development. Essentially, Javascript, HTML, and CSS. Of course there are tools that might help. For example, SASS for CSS, JQuery for Javascript, and recently, an exciting new library known as the SHPAML surfaced that is pretty similar to HAML, but more pythonic, and definitely more transparent. (http://shpaml.webfactional.com/) However, what does not change is that these components are still distinct. Everytime I have to modify a property of an element, I'd still have to go to my CSS file, or SASS file. Same goes to JS, or HTML. But thats not all, if we were to use SHPAML and SASS, every time we have to test the interface, we have to manually compile, or have a 3rd party script to compile all the relevant files back into its HTML/CSS/ JS components. And that means before every F5, we have to run a mini script. It gets annoying after a while. This is when I hope WUML can come in. Essentially, I hope to have a unified templating language that will coexists with template tags of Django, whereby I can streamline my development into a pythonic element-centric experience. But its better to demonstrate with examples. Examples -------- html body div#header | this is some verbose text inside this div + background-color: {{ backgroundcolor }} + pointer: cursor ^ alert("true"); ^ this.hide(); will be compiled into > A HTML FILE <html> <body> <div id="header">this is some verbose text inside this div</div> </body> </html> > A CSS FILE html body div#header { background-color: #FFF; pointer: cursor; } > A JS FILE (using JQuery) $(document).ready({function(){ $("div#header").live("click",function() { alert("true"); this.hide(); //hide here has to be defined in another js file. }); }); Arguments against WUML (or why it is helpful) --------------------------------------------- Some people might argue that this defeats the purpose of abstraction of different components into its respective components. JS/HTML/CSS existed distinctly for a reason. While I agree strongly with this point, but I hope to point out that WUML is not replacing any of those components. Here are some reasons why WUML might be interesting: 1) A javascript coder, a HTML writer, and a CSS scriptor, can still work on their individual files, no one is stopping them. What WUML does is, it provides a shorthand in an element-centric manner to various of these components in a pythonic sense. The 3 different people can now instead of working on 3 different files, they can work on the same code, and view distinctly what are the relevant details to each element they should take note of. Besides, with the state of the art revision control any decent programmer should use these days, merging will make this much easier. 2) WUML is soooo much shorter. 3) WUML is pythonic, at least syntatically-wise. 4) WUML will greatly boost any frontend developer's lead time. Implementation Details ---------------------- In a gist, I will basically be merging the best components of JS/CSS/ HTML, and providing a markup syntax for them in a pythonic fashion. Details: - Architecture: The WUML layer will live atop the 2 main components, namely SASS and SHPAML. Hopefully, we can use the python-sass library, instead of its generic binary backend for compilation. This way, the WUML layer will interface the 2 pythonic layer, and provide a whole new markup language. The template compiler which I hope will be worked on this GSoC, will live atop WUML layer, and hence compile the WUML compliant template everytime a change is made. - Compilation: I would hope to work with a co-developer who would be working on template compilation, and provide an extension of compilation of WUML into their relevant separate components. This way, compilation can take place dynamically and when needed, instead of manually. Some Notes ---------- - Old templates will still be compliant. - Using SHPAML's principle, all code can still be hardcoded. That means one would be able to mix in generic HTML code, or CSS styles into the SHPAML, and only use WUML when needed. And hence, non intrusive. Deliverables ------------ At the end of the summer, I hope to deliver an entire markup language that will be compilable using Django's default templating language, by which I hope it'll help bolster various of Django's design philosophies: - Less code. - Quick development. - DRY. - Discourage redundancy - Be decoupled from HTML - Assume designer's competency - Extensibility Timeline -------- First half of GSoC: Deliver a working library of WUML that will compile code into its seperate components Second half of GSoC: Work with fellow student in synergising WUML into the template compiler. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
