Skip to main content

Translating Spyce form tags

Jeff Shell doesn't find Spyce tags easy to translate into "what HTML does this output?" That's my fault for writing crappy documentation, I guess, although I did think the examples helped a bit. :)

So, briefly, here's how you translate the Spyce form tags:

<f:text name=quest label="Question:" />
  • All the tags correspond closely with raw HTML. (This is part of Not Wasting Your Time.) If the HTML is "input type=foo," the corresponding Spyce tag is f:foo. So this will generate "input type=text."
  • Name attribute is the same as in HTML; by default Spyce also sets the ID attribute to the same as name, for convenience working with javascript. ID may of course be overridden separately.
  • The "Label" attribute generates a "label for=..." html tag pair. For most form elements, the label will be placed before the input; the exceptions are radio and checkbox buttons.
  • Spyce will add a "value" attribute for you if you don't specify one; this will be the value of the GET/PUT variable corresponding to the input name if there is one, or "" otherwise.

So, the HTML generated is

<label for="quest">Question:</label> <input type="text" name="quest" id="quest" value="">

I find the Spyce notation to be concise and intuitive, once you learn a few simple rules, but to each his own.

(I covered the more "advanced" stuff over here already. Guess I should have started with the basics!)

Comments

Anonymous said…
One of the things i like about spyce tags is the fact that you can mix them with "normal" html form stuff so that you can migrate graually to tags.
You don't have to use the active handlers etc. you can continue using your request (spyce 1.3/php like) form processing logic until you get the chance to switch to the active handlers.

Also, I don't think the documentation on the spyce site makes it clear that the tags also take care of handling of variables submitted in the post

This really unclutters you code and prevents loads of stupid mistakes
Keep up the good work!!!
Jeff Shell said…
Your examples are fine. Your meaning and intent are fine. And it's awesome that you have documentation. But coming from the land of Zope where the word "documentation" is often combined with laughter, sighs, or sobs, I've gotten used to going to the source to guide me through how something works, or what its options/parameters are. And what I like about the 'helpers' system, or even Zope 3's Views (a callable object, bound to a context and request), is that they're normal Python objects and functions, usable both inside and outside of a template. The Zope 3 form widgets fill things in for you from the request, but don't require special tags to do so, and debugging is (generally) quite easy - compared to debugging sessions where I've gone into the guts of DTML, TAL, etc.

I understand and appreciate the 'taglib' / ASP.NET influence that Spyce has taken on. It just doesn't appeal to me these days. But I understand that I'm cranky, and the reasons for my crankiness and what drove me here may have nothing to do with your design, implementation, or decisions.

But man, I'd love to see a good and fast "Python Server Page" implementation that did no request handling, did not run standalone (just bound/called from Python), did not do inheritance, was not responsible for figuring out its place in sys.path since its local module imports could be passed in by the caller, did not have custom tags and widgets, could be easily compiled and/or bound and then called from within Python code as easily as calling any other method, and so on. That's all I want. Spyce wastes my time because it provides a ton of features that I already have in the form of Zope or Pylons or whatever, and it gets in the way of me getting a solid and tested simple Python Server Page solution to use with my already-made system.

I understand, however, that your target audience probably does not include people like me. But I bet that in this day of growing WSGI / Pluggable systems (or other pluggable architectures like Zope 3 is right now) that a 'spyce.core' release that was just the stripped down guts of Spyce - the PSP parser/interpreter/whatever (I don't know your implementation, and I apologize for wild guessing) - it would and could find a big audience among those of us who are using big toolkits already but may be tired of using the XML templating languages (TAL, Kid, Genshi) or custom languages (Cheetah) and just want Python and absolutely nothing else.

Maybe you already have this or maybe there's an implementation out there already that I have yet to find. I haven't had time, sadly, to look.
Jonathan Ellis said…
Thanks for the comment, Jeff. I see where you're coming from, and you're right, Spyce isn't a good fit for what you want to do.

(However, I'll note for the benefit of others that several normal Spyce users have looked at the tag generation code and found it not intimidating at all.)

But I personally find raw python-in-html to involve too much repetition to be a fun environment for doing actual work; hence the tags, etc.

Spyce's guts predate WSGI but it's still designed with modularity in mind. It ought to be fairly easy to create a spyceRequest subclass that works with WSGI, just like there are subclasses for CGI and mod_python. Maybe now that I know there's at least one person interested in it, I'll have a look. :)

Popular posts from this blog

Why schema definition belongs in the database

Earlier, I wrote about how ORM developers shouldn't try to re-invent SQL . It doesn't need to be done, and you're not likely to end up with an actual improvement. SQL may be designed by committee, but it's also been refined from thousands if not millions of man-years of database experience. The same applies to DDL. (Data Definition Langage -- the part of the SQL standard that deals with CREATE and ALTER.) Unfortunately, a number of Python ORMs are trying to replace DDL with a homegrown Python API. This is a Bad Thing. There are at least four reasons why: Standards compliance Completeness Maintainability Beauty Standards compliance SQL DDL is a standard. That means if you want something more sophisticated than Emacs, you can choose any of half a dozen modeling tools like ERwin or ER/Studio to generate and edit your DDL. The Python data definition APIs, by contrast, aren't even compatibile with other Python tools. You can't take a table definition

Python at Mozy.com

At my day job, I write code for a company called Berkeley Data Systems. (They found me through this blog, actually. It's been a good place to work.) Our first product is free online backup at mozy.com . Our second beta release was yesterday; the obvious problems have been fixed, so I feel reasonably good about blogging about it. Our back end, which is the most algorithmically complex part -- as opposed to fighting-Microsoft-APIs complex, as we have to in our desktop client -- is 90% in python with one C extension for speed. We (well, they, since I wasn't at the company at that point) initially chose Python for speed of development, and it's definitely fulfilled that expectation. (It's also lived up to its reputation for readability, in that the Python code has had 3 different developers -- in serial -- with very quick ramp-ups in each case. Python's succinctness and and one-obvious-way-to-do-it philosophy played a big part in this.) If you try it out, pleas

A review of 6 Python IDEs

(March 2006: you may also be interested the updated review I did for PyCon -- http://spyced.blogspot.com/2006/02/pycon-python-ide-review.html .) For September's meeting, the Utah Python User Group hosted an IDE shootout. 5 presenters reviewed 6 IDEs: PyDev 0.9.8.1 Eric3 3.7.1 Boa Constructor 0.4.4 BlackAdder 1.1 Komodo 3.1 Wing IDE 2.0.3 (The windows version was tested for all but Eric3, which was tested on Linux. Eric3 is based on Qt, which basically means you can't run it on Windows unless you've shelled out $$$ for a commerical Qt license, since there is no GPL version of Qt for Windows. Yes, there's Qt Free , but that's not exactly production-ready software.) Perhaps the most notable IDEs not included are SPE and DrPython. Alas, nobody had time to review these, but if you're looking for a free IDE perhaps you should include these in your search, because PyDev was the only one of the 3 free ones that we'd consider using. And if you aren