Mike, sorry for not replying to this earlier ........ here is how I
automate it ......
Briefly..... attribute errors go beside the attributes ..... object
validations (like you can't set B to 5 if C is greater than 10 or
whatever) at the top of the page using addMessageToPageErrors(String
message).
The approach I use for attribute validation failures is sth like this
(in brief) which was based on Malcolm's original article:
- I have an ErrorMessage reusable subcomponent that I can drop in
beside any input and I bind the same input value to it also. That
binding is just for the purpose of discerning the testual keypath,
but I did the binding rather than a quoted keypath text value for
drag bind convenience in WOBuilder (and now for autocomplete in
WOLips editor)
- Every subcomponent is stateless, pages are stateful in my apps ....
in general
- Any subcomponent can grab a lazily initialized errorMessage
NSDictionary with a key defined by the it's own component elementID.
The subcomponent's dictionary is stored in a page level dictionary
but could be put in other places too if you want). The page level
dictionary has subcomponent elementID as the key and the values are
subcomponent error dictionaries.
- So each subcomponent dictionary had a lazily initialized dictionary
for storing error messages .... in which each key is the key path of
the value (with periods replaced which is probably not necessary in
hindsight)
- So the error message WOComponent checks if the error dictionary
exists and if it has a text key that matches the munged binding
keypath and if so it gets the error message and displays it
- Attribute errors are pushed into the subcomponent's error
dictionaries in validationFailedWithException (and failed values are
forced with try/catch/ignore into attributes after failure so the
user gets back what they entered and they have an opportunity to
correct it)
- Any errors encountered in takeValuesFromRequest sets a page level
boolean which is the first thing checked in invokeAction in which
case the same page is returned and no action is taken
- Error dicts are nulled at end of appendToResponse in the page after
they have been rendered in the HTML and the cycle starts again with
the next form submission
All this functionality is stuffed into a generic WKComponent subclass
and pages subclass WKPageComponent. Has not been tested with Ajax
stuff ... yet.
Anyway this works well for my general app construction which is to
have stateless subcomponents and the ability to have multiple use of
the same subcomponent on a page (for example an Address detail
subcomponent)
Kieran
On Apr 21, 2007, at 5:28 PM, Mike Schrag wrote:
We currently MOSTLY just show at the top of the page ... I have
thought about doing a more automated way of making them show up
beside the input, but haven't so far.
On Apr 21, 2007, at 1:57 PM, Kieran Kelleher wrote:
Very interesting ..... do you display all validation failure
messages at top of the page together or use elementID and keypath
munging to display messages beside the input with the unacceptable
value?
On Apr 21, 2007, at 8:22 AM, Mike Schrag wrote:
We have a SessionNotifier object that hangs on the session. All
messages push into this. We find this to be a better overall
solution because if you are using Ajax, you might find that for a
particular request or response, you are not going to be
refreshing the area of the screen that shows errors, so you might
lose the message if you hang it on the request/response.
Instead, you can setup an AjaxResponseAppender that checks to see
if you have any errors and tell it to come back and update the
notification area. By having it on the session, you only clear
out notifications once you are sure you've shown them to the
user. So in our case, we have a notifier component that pulls
the pending notifications out and then clears them at the end of
its appendToResponse.
ms
On Apr 21, 2007, at 7:26 AM, Jean-François Veillette wrote:
.... or store it in either context().request().userInfo() or in
context().response().userInfo() dictionary. look at the doc,
for a which one fit better your needs (most likely the context
().request() one).
- jfv
Le 07-04-20 à 21:52, Kieran Kelleher a écrit :
For stateless subcomponents you need to store the error
messages somewhere stateful ....... either in a ivar in the top-
level page if that is stateful (and nullify it at the end of
append to response) .... or store it in Thread storage (see
ERXThreadStorage in project wonder)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/mschrag%
40mdimension.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists
%40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%
40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
