Provocation
In designing Qwicap, I kept thinking of various professors, graduate students, and innocent staff members I've encountered over the years who were perfectly competent programmers and had written useful code. The kind of code that could solve real problems, or get someone a graduate degree, or both. They came to me asking how they could put a nice interface on it, and long before I could finish telling them what they'd have to learn, how they'd have to restructure their code, and so on, the color would kinda drain from their faces. The projects generally progressed from there with great difficulty, and frustration, if at all. I also thought of the many times I've looked at a problem and foolishly thought "I'll just knock-out a quick web app to do that," before remembering what doing a web app correctly required. I've been convinced all along that there had to be better ways to create good interfaces - methods offering small learning curves, and relatively conventional coding styles - and I believe that for web applications Qwicap is one such method.
When Using the "Full-Up" Qwicap System
(As opposed to using just the Qwicap templating engine....)
- All "class" and "id" attribute values that begin with "qwicap" are reserved for use by Qwicap.
- All form control names beginning with "qwicap" are reserved for use by Qwicap. (Qwicap adds hidden "input" controls to your forms for its internal use, and a naming conflict wouldn't do either of us any good.)
- If you view a form data set by whatever means, including using the
FormDataSet.iteratormethod, don't be surprised to find more than just the values from your own form controls; Qwicap adds hidden "input" controls to all forms for its internal use. Their names are always prefixed with "qwicap" to avoid name collisions. - If you view the XHTML source of a web page containing a "form" element, don't be surprised to find that Qwicap has added hidden "input" controls. Those controls supply Qwicap with information it needs in order manage your pages correctly. Their names are always prefixed with "qwicap" to avoid name collisions. The original XHTML template on disk is not altered to include those hidden controls; only the mutable copy of the template that is present in memory is modified.
- Form data sets embedded in the URLs of link elements, e.g. "<a href='foo.html?a=quick&b=brown&c=fox'>", are not supported. This is because Qwicap needs to embed information into all form data sets that uniquely identifies the page and form from which the data set originated, and it can't do that with data sets embedded in URLs. Just being certain which URLs it could re-write to include its unique identifiers would be tricky, and, of course, such form data sets do not originate from any form at all, which creates its own set of issues. So, consider substituting single button forms for such links; the individual values to be submitted can be supplied using "input" controls of type "hidden".
