Fw: [New post] daml 0.1.4 Release
Steve Howell
----- Forwarded Message ----
From: All Things Related <no-r...@wordpress.com>
To: show...@yahoo.com
Sent: Wed, December 22, 2010 2:09:06 PM
Subject: [New post] daml 0.1.4 Release
daml 0.1.4 Release
dasacc22 | December 22, 2010 at 6:08 pm | Tags: daml, haml, Linux, Python, software development, web development | Categories: DAML, HAML, Linux, Python, Windows 7 | URL: http://wp.me/piHZk-29Since my initial post outlining daml as a haml-for-python, a lot has changed. Now it has become something more and plays a new role in a bigger project I am working on. Let's look at some of the new syntax changes.
CSS Selector Style Attributes
Declaring attributes now follows css selectors appended to a tag hash. For example,
%html %body #content.main[attr=val][apples=yes] some contentInlining Tag Hashes
One can now inline tag hashes. The functionality is still being worked on and is broken beyond a single tier. The intent is to handle use cases such as,
%html %body %ul#nav %li %a[href=/] Home %li %a[href=/contact] Contact #wrapper #container #top #contentImplicit Python Declaration
Since my last post, all python code had to be preceded with a colon (:). Now, this is only necessary when embedding a function call in plain text (or calling a filter). For Example,
def greet(s): return 'Hello, {0}.'.format(s) nav = ['www', 'www2', 'www3'] %html %body %p A greeting for you. :greet('Daniel') %ul for x in nav: %li {x}The trade off to the above is explicit line breaks for multiline text as similarly done in python,
%html %body This is some text \ that spans multiple \ lines.I am still putting alot of thought into this portion of the syntax and it will most likely see some changes in a number of months. Explicit line breaks can become rather confusing when handling complex mixed contents, but again, tools such as daml aren't particularly suited for writing page content, but rather establishing layout.
New Filters
I added two new filters as a test, these may be removed in future releases (and migrated to my personal set of daml extensions). They are for declaring css and js files. I think the syntax speaks for itself in function,
%html %head :css /css/ main.css extra.css lib/that_lib.css :js /js/lib/ utils.js js.js jquery.min.js etc.js %body %h1 I do enjoy filters!I think such filters could be upgraded to support appending additional files, but again, I dont really have a place for such things that aren't a necessity to a fully featured template engine.
In Summary
This release requires cython >= 0.13 and lxml. I use this regularly on Windows 7 x64 and linux. The 0.1.4 release can be found on pypi, http://pypi.python.org/pypi/DAML/0.1.4 and you can follow development at github, https://github.com/dasacc22/daml
WordPress.com | Thanks for flying with WordPress!
Manage Subscriptions | Unsubscribe | Publish text, photos, music, and videos by email using our Post by Email feature.Trouble clicking? Copy and paste this URL into your browser: http://subscribe.wordpress.com
dasacc22
it's just been me and my ideas based on my reading of filters from
haml documentation long ago. I'd be curious to see what kind of ideas
come up here for shpaml.
Just for a quick reference, the way filters work currently are
:myfilter some text
and more and more etc
and it gets translated into a python call that looks like
myfilter("""some text\n and more and more etc""")
where myfilter is in a seperate py file and the function is loaded
into the sandbox extensions manually after import
On Dec 22, 4:47 pm, Steve Howell <showel...@yahoo.com> wrote:
> FYI, I'm not sure if any folks are tracking daml, but I thought I'd forward this
> along. It has some interesting ideas, and it's a little more ambitious than
> shpaml in what it's trying to achieve.
>
> http://dasacc22.wordpress.com/2010/12/22/daml-0-1-4-release/
>
> Two of the main goals for shpaml are that I want minimal syntax and to not try
> to be a templating language. Daml obviously serves a different niche.
>
> The one feature I'm really starting to warm up toward is filter support. It
> would be nice to have a plugin model that daml, shpaml, and other tools all
> support in the same way.
>
>
>
>
>
>
>
>
>
> >----- Forwarded Message ----
> >From: All Things Related <no-re...@wordpress.com>
> >To: showel...@yahoo.com
> >Sent: Wed, December 22, 2010 2:09:06 PM
> >Subject: [New post] daml 0.1.4 Release
>
Steve Howell
At the time, there was some consensus that you would rely on the outer
templating language to provide filtering capability, not shpaml.
The mechanism you have sounds simple and sensible, though, and there's a use
case for shpaml where you're mostly using it to generate static HTML content,
but you might want some additional sugar for the JS and CSS parts of your
document.
dasacc22
needless redundancy in my templates and things that were generally
just an eye sore. This is the function for the js filter for example,
def js(s):
s = s.splitlines()
n = s[0]
s = s[1:]
return ['%script[src={0}{1}]'.format(n, x) for x in s]
the css filter is the same. This could easily be expanded so that s[0]
could be split and take additional params like script-type, and theres
really all kinds of sillyness possible. There's different problems
with this here as well but its aside the point.
The original intention for filters was to handle things like reST or
MarkDown blocks. Then it became more generalized as a way to pass
multiline blocks of code to a python function. So for example, passing
more daml to a filter, the function could work like
def block(s):
s = s.splitlines()
n = s[0]
s = s[1:]
s = _pre_parse(s)
s = _py_parse(s)
# ...
and then do whatever else, in this case, it manages blocks by a name
given on the first line. So my original intention for filters is
probably outside the scope of shpaml, and while I do agree about
having some nice syntactic sugar as seen for the bits like js and css,
I'm not really sure what the starting point is for something like this
in shpaml. I'd be curious to hear some more ideas for needed sugar,
but beyond js and css? Do you start by making an extensible filter
system or do you write specific extensions for each specific task to
reduce redundancy? I can only imagine a handful of html related
extensions that could possibly be needed if thats the only focus.
Essentially designing some kind of tag repeater of sorts..
On Dec 22, 5:33 pm, Steve Howell <showel...@yahoo.com> wrote:
> The last major discussion on filters came up here:
>
Steve Howell
hook in whatever they want. The most obvious use cases are other markup
languages, JS, and CSS, but I'm sure other users have more exotic use cases.
----- Original Message ----
> From: dasacc22 <dasa...@gmail.com>
> To: shpaml <shp...@googlegroups.com>
dasacc22
bitbucket is shpaml_website. Wheres the repo for the latest source? Or
is the download link with the source displayed already the latest?
Steve Howell
https://bitbucket.org/showell/shpaml_website/src/tip/shpaml.py
dasacc22
http://vizi.dasa.cc/shpaml_exts.patch
It's not meant to be incorporated into the repo, just to demonstrate
some ideas (and was curious to get a feel for shpaml codebase).
Basically what I'm noting is that one might want to consider looping
over possible branch_methods (similar to line_methods) instead of
defaulting to html_block_tag, and reorganizing the codebase to fit
that paradigm. So the patch isn't very well organized b/c of current
placement of functions.
I dropped in a quick bit on templates/base.shpaml to test.
>
> read more »
dasacc22
http://vizi.dasa.cc/shpaml_exts_organized.patch
Thanks for any thoughts regarding implementation, The first thing that
comes to mind is a speed hit for needing to do a regex on each block
now
>
> read more »
Steve Howell
pretty oblivious now to the actual content of the document. Indent_lines is
very lightly coupled to the HTML-ish parts of SHPAML now, which means in theory
it could process arbitrary indented languages. So I'd consider going back to
having indent_lines just accept a single branch_method that you pass in. Then
the method you passed in would dispatch to either EXT_BLOCK or HTML_BLOCK_TAG.
(So you'd change convert_shpaml_tree on the calling side).
Then the next challenge would be to pass in your own list of extensions from the
outside. I think in daml, you just use convention, not configuration, right?
The extension mechanism just uses the name after the colon to determine which
module to load? Without getting too elaborate, I could see something like this:
1) look for a method in shpaml.py
2) look for a method in shpaml_extensions.py
3) look for a module with the appropriate name and call extend() on it
Steve Howell
https://github.com/p/shpaml-jinja/blob/master/src/aml_jinja.py
It's a pretty elegant extension of shpaml. It takes advantage of the
"consenting adults" features of Python, hooking directly into LINE_METHODS and
overwriting html_block_tag.
I think the author was subscribed to this list at one point, so maybe he can
chime in.
dasacc22
> pretty oblivious now to the actual content of the document. Indent_lines is
> very lightly coupled to the HTML-ish parts of SHPAML now, which means in theory
> it could process arbitrary indented languages.
was similar to how I started off with daml. One of the reasons I'm
playing around with the shpaml code base right now is I'm going to be
doing a hard rewrite of daml pretty soon and want to revisit old ideas
and look into new ones.
> So I'd consider going back to
> having indent_lines just accept a single branch_method that you pass in. Then
> the method you passed in would dispatch to either EXT_BLOCK or HTML_BLOCK_TAG.
> (So you'd change convert_shpaml_tree on the calling side).
accompany convert_line) seems like the best way to go, leaving the
original structure of your code intact. Personally, I'm not a fan of
either of these functions simply b/c of the execution overhead of
calling a function that many times that contains very little code. But
maybe this isn't a big deal for shpaml and it sounds like you might
have more intentions down the road for the library as it grows.
> Then the next challenge would be to pass in your own list of extensions from the
> outside. I think in daml, you just use convention, not configuration, right?
python eval takes place only once with a single sandbox environment
(which is contained in a dict) and so for now. During a parse call, a
copy of the environment is made, and that copy is updated with builtin
exts (another dict). And so currently one would update this ext dict
however they please so there is no convention in place here. But I
favor both and would like to make a simplistic convention that can be
followed easily or let ppl hack their exts in however they please if
they so wish
> The extension mechanism just uses the name after the colon to determine which
> module to load?
this is how it started. There is a preparser before getting passed to
the python eval that handles a couple things like missing colons (a
feature now!) and these colons get stripped for the eval and the
preparser transforms ":somepythonfunc first line\n second line"
into "somepythonfunc('''first line\n second line''')" which gets
appended to the python eval getting ready to take place, and where
"somepythonfunc" has been added to the sandbox eval, so daml stays
oblivious to what everything is.
for the bit i wrote in shpaml, i just did two colons for no reason,
just as a demonstration.
> Without getting too elaborate, I could see something like this:
> 1) look for a method in shpaml.py
> 2) look for a method in shpaml_extensions.py
> 3) look for a module with the appropriate name and call extend() on it
into the shpaml.py namespace, b/c namespaces are one honking great
idea -- let's do more of those
dasacc22
shpaml, but i was under the impression you were looking to incorporate
some kind of extensions module directly into the shpaml codebase if it
was light enough
>
> read more »
Steve Howell
much. I don't think they end up being the bottleneck. It's been a while since
I profiled shpaml, but I recall that the regex processing was the biggest
bottleneck.
The other thing about shpaml is that it's truly meant to be preprocessed. In
prod mode you shouldn't be running it at all. In dev mode you just need some
logic to cache the output for files that haven't changed. The recipes for doing
that vary from environment to environment, but they're easy to build. For my
small sphaml-based site, I reprocess the entire suite of files every time under
a second.
----- Original Message ----
> From: dasacc22 <dasa...@gmail.com>
> To: shpaml <shp...@googlegroups.com>
> Sent: Mon, December 27, 2010 10:25:59 AM
> Subject: Re: Fw: [New post] daml 0.1.4 Release
>
dasacc22
when i first started taking 3 times as long as a string iterator
accomplishing the same thing, and python devs noted its poor
performance as well when i was doing research. Factor in im not a
regex wiz and have no clue how to optimize my expressions...
This doesnt seem to stop mako though from being fast and still making
use of it.
But your right, speed is a none issue with shpaml as it just needs a
caching mech just as if using sass for example
Ill probably have a patch in the next day or so following in line with
what was discussed before unless someone else jumps on it, in the
midst of daml source right now