[TransWarp] Use cases/design goals/scope for peak.web forms (part 1)
roche at upfrontsystems.co.za
Tue Aug 12 16:47:46 EDT 2003
* Phillip J. Eby <pje at telecommunity.com> [2003-08-12 00:24]:
> Form Types/Scenarios
> Add/View/Edit Forms
> The common case, representing maybe half the forms in an application. It
> should be trivial to create these, preferably by adaptation from the
> peak.model class. Our default decorator for model.Element should
> incorporate a binding that automatically creates or looks up a form (via
> something like 'StdFormFor(Class)'?) Features in peak.model will probably
> want to carry some "hints" to help default widget selection.
Most of my use cases are covered by this post, I think, but I have a
specific question regarding the adaptation of features to widgets. I
started with this over the weekend and its mostly straightforward,
except where a feature's referencedType is another model.Element. Let's
say that a MultiCheckboxWidget or MultiListWidget is the default for
features that references another model.Element and upperBound greater
At the time of the adaptation we don't know what items must be in the
list and what items must be selected. This means that the form should
discover this at render time and supply these values to the widget. We
need to give the form some hint to where these values should come from.
If we take your bulletins app as example then one would want a select
control for the category of a bulletin. I thought one way of handling
this would be to set an attribute on the feature that can be used by the
form or a field to populate the widget with items:
referencedType = 'Category'
referencedEnd = 'bulletins'
sortKey = 'id'
displayName = 'title'
selectFrom = 'NameOfBindingToCategories'
I am not sure though. Maybe it should be a binding that can be resolved
by walking up the component hierarchy. Any ideas how this will work in
Upfront Systems http://www.upfrontsystems.co.za
More information about the PEAK