Hey,
> 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.
> LUA
+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.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
