>The performance hit would be fine with me if I could gain the abstraction.
We'll implement both. That way the user can select.
>> <x:formfiller data=foo>
>> my form goes here <y:foo/>
>That's not tagless but it's pretty close. My question is "can it be done
>tagless, just like EmbPerl". You don't put a tag around the form in EmbPerl.
>You just put data in a hash and it magically works.
Yeah, we should be able to do that too, using modules. There is already
a transform module. (See documentation.) It can do a whole bunch of
things right now. One of them is to dynamically compress on its way out.
Another is to post-process the output from static strings, spyce
expressions and dynamic output from spyce code. We could certainly hook
into that filter mechanism to post-process the output of a script, and
to fill in any fields. As before, there will *not* be a pre-processing
phase, which you seemed to want, but it will "tagless". If we wish to
later write the tag-based version, we can re-use this form-filing code.
You just get your initial string in a different manner, but the filling
logic is the same.
>I don't think Spyce can do that without making it a "built-in".
I have nothing against making things "built-in". I did this, for
example, for the request-handling, error-handling, and for internal
redirects -- things that are core, essential, and not possible outside
the engine. I would prefer, though, whenever possible, to design the
Spyce engine in a way that would not require users to tinker with it. I
would like to have an engine that users can dynamically extend. To this
end I created the module and tagging frameworks.
>Spyce is built around this tag model. I'm not sure that's a really
>good model but that's a debate for another life! Certainly a tag can
>process it's body.
Not true. In fact, I just added tags of late. Spyce did not even have
modules until v1.1.0. Tags were added only in v1.3.0. Since they are
new, there has been a lot of development focus lately on tags, and
perhaps that has been misleading. Tags are relatively new, and not
useful for much yet.
>What if I have a form:
> <mytag:a blah>
> my form goes here
> <mytag:b blah>
> <y:foo/> (<-- What's this for?)
>Processing reaches my formfiller tag. How do I know that the other tags "a",
>"b" and "c" are already processed? I am in a catch 22. I can't emit the
>output to the client because I don't know if everything is done and ready for
>sending to the client, and I can't send it back through Spyce to catch any
>remaining tags that are not processed yet. That is why I was thinking in
>terms of sending it back through Spyce. After I parse it and fill in my form
>values, what do I do with it? How do I make it get to the client? How do I
>process all nested (and surrounding) active tags first so that I'm the last
>point in the chain before sending output to the client. What disadvantages
>are there to me sending output directly to the client rather than letting
>Spyce do it. It's a hack'd up deal at that point and doesn't "feel" right.
>If it was integrated right into Spyce then it would feel right.
Major misunderstandings here. ;) You should type in some code with
active tags into Spyce and see what's produced in terms of Python code
(i.e. type spyce -c mytagfile.spy). It's too long for me to explain how
tags work, and I think we should just stay away from tags for now,
anyways. If you are interested, you should read the documentation on
tags, and how to write your own active tag libraries.
>My Python skills are still quite rudimentary. I'm moving out of Perl and not
>all up to speed on Python yet because I'm reading a lot about Object Oriented
>in an attempt to really "wrap my head around it". That's one of the reasons I
>want a truly "developer friendly" solution (I'm spoiled by EmbPerl :). I'd
>be happy to give it a try.
Ok, let's use modules. I've written a short starter module for you.
Don't worry about all the fluff at the top. There's a single function at
the bottom of the file:
def FillForm(s, data):
's' - output of the script, just before being sent out
'data' - is whatever information you pass in using the setdata()
This function currently does nothing with the string. You need to return
a modified 's'. That's what will get emitted to the browser. So, fill
's' with 'data', and return that new string. That's all you need to do.
I've taken care of the rest. You might find the Python HTML parsing
libraries to be of some use... But, I don't know *exactly* what you have
There are two files attached:
rim.spy: a sample spyce script that uses the formfiller module
formfiller.py: the spyce module, but with only a generic
FillForm() function implemented, as shown above
Stick these two files anywhere (in the same directory), and run:
Things will work as expected. If you change the return statement in
return 'my test'
you'll see that you get 'my test', as output to the command above,
instead of the expected script output.
Does that make sense? Can you start from this point? I'd be happy to
help further. BTW, let's take this offline, until we're done with the
development of formfiller. You can can keep emailing at this email
All the best,