I have some remarks/thoughts. - How does this make code re-use better? For instance, how do you use the same CSS styles along different files. Or am I required to move the re-usable CSS/JS code in a normal file? - Can you give an example on how you see the template tags being used in here?
>From what I've read in the other proposals, your timeline should be divided into weeks. It shows a better understanding of the problem. -- Gert Mobile: +32 498725202 Web: http://gert.selentic.net On Fri, Apr 9, 2010 at 20:14, nubela <[email protected]> wrote: > 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. > > -- 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.
