Hi Robert!
again, many thanks for you input, I really appreciate this discussion
and time you spent
If you're using tapestry's form components inside your component, and binding
the values, then all of the values should be updated automatically. The main
thing is to make sure that the property path to be updated still references a
valid object. For instance, if I have a form:
<t:form>
<t:mycomponent object="someobject"/>
</t:form>
With mycomponent looking something like:
<t:label for="myfield"/><t:textfield t:id="myfield"
value="object.someProperty"/>
this is exactly my problem: "object.someProperty" is a "1:1" mapping of
a data-model value to an UI element and this is not possible in my
particular case. Assume we compact data in our database for example
newsletter settings (daily, weekly, monthly) for several areas. Fully
normalized our database will explode with 100 of fields (even I know
normalisation is usually the way to go, in theory). But changes happen
very often and altering db schema in production is not an option due
very limited downtimes. Thus we store "newsletter" settings in a string
field and use a compact representation like "dwmwmd" to feed 6
checkboxes (example simplified). This means I have something like
boolean newsletterSettingArea1D =
"1".equals(object.newsletter.substring(0,1));
boolean newsletterSettingArea1W =
"1".equals(object.newsletter.substring(1,2));
..
to extract the values in setupRender. And I need the opposite in
"onSuccess" (checking the state and compacting the info again). Just
think about a bitfield which causes exactly the same problems.
After some sleep I was thinking about what you said concerning event
bubbling from components to the form: Looking at field validation it
seems at least the "validation event bubbles" from the form to all input
elements as the page's onSubmit must have initiated the validation
sequence somehow (have not debugged tapestry yet, but I assume this for
now). This simply means Tapestry just uses a different approach for
validating fields which is not based on events, right? But for symmetry
reasons if events can bubble up from components to pages, shouldn't they
not bubble down, too? At least for onSuccess/onFailure/onValidate to
give a component a chance to participate as union not just assembly of
single fields? If a component groups fields than only the component is
able to detect a valid state considering all input elements, right?
Consequently only a component can feed UI elements from the model and
vice versa in case we need something more sophisticated than single
attribute to attribute mappings via coersions.
I am not intending to work "against" Tapestry concepts, but currently
this feels like something is missing in the framework. I can not believe
we are the only developers using a persistence representation of our
data which is quite different from the UI (anyone using SAP as backend
immediately suffers from this)?
And worse: even we use a "Tapestry-friendly attribute only domain model"
we need a chance to extract / compact the persistence data which again
means code is creeping into the page which is usally not required as a
component can fully live on it's own as soon it participates on the form
events onSuccess/onFailure/onValidate.
Please correct me if I am wrong....
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
