To be honest, my biggest question is "is this really about Django?"
It seems like this proposal could have gone to anybody, or it could be a standalone app. I also would like to know if you have examples of other successful implementations of such a system that incorporate HTML, CSS, *and* JS into one. Striking out into this territory and finding it's a much larger job than expected just means the code branch is more likely to die. I'm particularly concerned about your discussion of javascript being included. Though Django has chosen jQuery for its admin there is no such requirement for the rest of any Django site's codebase. Writing a meta-language for javascript that is framework-agnostic (or framework- independent) is going to be extremely hard. You talk about extensibility, but don't give any examples of how this system would *actually* be extended. How do you propose for your parser to determine the difference between this new WUML markup and non-escaped similar-looking markup in legacy templates? Backwards compatibility is not a simple issue here. Adding dependencies on more external Python libraries also doesn't sit well with me. I don't want to have to install SASS and SHPAML libraries, nor do I want to be reliant upon the development directions of those projects. This proposal is certainly ambitious. I'll give you that. All the best, - Gabriel On Apr 9, 11:14 am, nubela <nub...@gmail.com> 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 django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
