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
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!!!
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.
(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. :)