> it doesn't seem important enough, in my opinion, to get a slot in the Google Summer of Code
I tend to agree here. There are things in greater demand that would be useful to more people that could be done. However, I think this idea should go on the GSoC page regardless. If we get a very capable student for it, and have less success for other ideas, then it might very well be worth the effort.
> But in general, I'm not aware of a widespread demand for behavior in forms that SF can't address, that would call for a general rule-based framework like this one.
I'd say that SF can definitely handle the vast majority of use cases already. Most forms are relatively simple, with complex ones being the exception. I think there would be more complex forms if there where more advanced features though, so would not be so quick with saying that there is no demand at all. People are familiar with basic form features from other applications, and will demand these if they don't find them. This does not hold true as much for advanced features, which also typically are needed by more advanced users, who might be more prone to assuming it simply can't be done, would take to much work to implement or simply don't have the time to care about it either way. So I think this feature would find use when published and documented properly. Nevertheless, it seems like the 80% of effort to solve the 20% of remaining (potential) use cases.
Having more generic systems is always nice though, so I think SF could benefit from this extension. At least, if this new more generic system was actually used by SF. So I think it's worth looking into either putting this into SF, or moving the existing, more limited, functionality out of it and into this new extension.
+1. Introducing even more special syntax is something I would avoid. Then again, it will be a while before the LUA stuff is done, and will take longer before you can use it in SF (or an extension to it).
> One other possibility would be to use the structure provided by the Page Schemas extensions instead
Yeah, this seems like a nice pragmatic thing to do for now. The parsing done by the new functionality can be made modular in such a way the XML parser for PS can be replaced by a LUA one if that ends up being desired at some point.
Jeroen De Dauw
Don't panic. Don't be evil.