Aside from the name that makes for bloody impossible searches, I think you have done an extravagantly good job with Markup. XPath for finding nodes is The Way Things Should be, and using xinclude is also great.
I've used DTML, Page Templates, PHP, server-side includes, XSLT, and various other templating approaches throughout the years, and this is *finally* a templating approach that does things right.
To be fair, a good bit of the template language design was done by Ryan Tomayko. But, I think that Chris has done an excellent job producing what is effectively a Kid 2.0... all of the goodness of Kid + corrections for the shortcomings that were found in real-world usage.
Looking at a CherryTemplate error today made me really appreciate the work that has already gone into Markup's error reporting.
> Aside from the name that makes for bloody impossible searches, I think > you have done an extravagantly good job with Markup. XPath for finding > nodes is The Way Things Should be, and using xinclude is also great.
> I've used DTML, Page Templates, PHP, server-side includes, XSLT, and > various other templating approaches throughout the years, and this is > *finally* a templating approach that does things right.
> Aside from the name that makes for bloody impossible searches, I think > you have done an extravagantly good job with Markup. XPath for finding > nodes is The Way Things Should be, and using xinclude is also great.
> I've used DTML, Page Templates, PHP, server-side includes, XSLT, and > various other templating approaches throughout the years, and this is > *finally* a templating approach that does things right.
Glad you like Markup!
You're right about the name, of course. In fact, this is another property inherited from Kid ;-) Searches need to be qualified with "markup templating" or "markup templating python", which results in pretty good results. But still...
The problem, as always, is finding a decent name that is sufficiently unique and doesn't sound too cheesy. It's probably still early enough in the game for a change, so I'm open to suggestions. Anyone?
> The problem, as always, is finding a decent name that is sufficiently > unique and doesn't sound too cheesy. It's probably still early enough > in the game for a change, so I'm open to suggestions. Anyone?
pyMarkup?
Pretty standard for a Python library to have a "py" prefix, and you don't really give up the Markup name. Also, would be pretty straightforward to top google results for it (54 hits so far...).
> Am 16.08.2006 um 02:11 schrieb mindlace: > > Aside from the name that makes for bloody impossible searches, I think > > you have done an extravagantly good job with Markup. XPath for finding > > nodes is The Way Things Should be, and using xinclude is also great.
> > I've used DTML, Page Templates, PHP, server-side includes, XSLT, and > > various other templating approaches throughout the years, and this is > > *finally* a templating approach that does things right.
> Glad you like Markup!
> You're right about the name, of course. In fact, this is another > property inherited from Kid ;-) Searches need to be qualified with > "markup templating" or "markup templating python", which results in > pretty good results. But still...
> The problem, as always, is finding a decent name that is sufficiently > unique and doesn't sound too cheesy. It's probably still early enough > in the game for a change, so I'm open to suggestions. Anyone?
Personally I'm fine with markup, simple, nice and focused on it's scope. I don't like seeing py in almost every python bases package out there but this is just personal taste. ;-)
Kid has the same problem but searching for kid puts it in third position on the first page, it's probable that once markup start growing (and I guess it will) it will show up in the first page?
The first time Kevin mentioned Markup I searched for "markup" and couldn't find anything so I just added "python" and found it, I mean is this such a big problem? we are still talking of python software in the end.
>> The problem, as always, is finding a decent name that is sufficiently >> unique and doesn't sound too cheesy. It's probably still early enough >> in the game for a change, so I'm open to suggestions. Anyone?
> pyMarkup?
> Pretty standard for a Python library to have a "py" prefix, and you > don't really give up the Markup name. > Also, would be pretty straightforward to top google results for it (54 > hits so far...).
I'm not a fan of such prefixed names (WinFoo, KFoo, GFoo, iFoo, etc). IMHO those fall in the "cheesy" category ;-) Exceptions are bindings or Python versions of some product, but otherwise I think it's rather ugly.
> You're right about the name, of course. In fact, this is another > property inherited from Kid ;-) Searches need to be qualified with > "markup templating" or "markup templating python", which results in > pretty good results. But still...
> The problem, as always, is finding a decent name that is sufficiently > unique and doesn't sound too cheesy. It's probably still early enough > in the game for a change, so I'm open to suggestions. Anyone?
The official name seems to be "markup.py", but well, it's a name conflict either way. Never heard about this one before, and I swear I did some research on whether other existing Python packages use the "markup" name. :-P
I loved kid from the get-go; all thanks to Ryan Tomayko for the originial implementation. That being said I've experienced much less pain with Markup.
As for an original name - You could always go for Markleft or Markright (since Markdown is taken.) Other suggestions: MarkyMark, XMarkup, MarkMeld, Goat (what happens to a kid when it grows up :)
In relation to the "Goat" suggestion Chris mentioned on IRC "Markhor" which is a type of goat. Incidentally the name comes from the Persian word for "snake eater", so it has a sort-of tie-in to Python. Though as Christian later that O'Reilly is using wild goats on its covers for Ruby on Rails-related books: http://www.oreilly.com/catalog/rubyrails/
