tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject RE: Tracking of component errors recorded in the business tier
Date Thu, 15 Jan 2004 12:39:33 GMT
I know this is important, but I would rather do this first thing in release 3.1 than last thing
in
3.0. I'm very cautious.

--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components 
http://jakarta.apache.org/tapestry/
http://javatapestry.blogspot.com

> -----Original Message-----
> From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net] 
> Sent: Thursday, January 15, 2004 12:42 AM
> To: Tapestry development
> Subject: Tracking of component errors recorded in the business tier
> 
> 
> Hi,
> 
> For some of our domain objects, we have a couple different 
> ways of capturing the data, Tapestry is
> one of them. For this reason, I would like to move my 
> validations to the business tier (even
> otherwise this is probably the right place for business rules 
> validations). This is not a problem 
> unless have a component inside a Foreach. Now, even if I 
> register the component with the delegate, 
> there is no way of letting the delegate know exactly which 
> occurrence of the component in the loop 
> had the problem. And the "error decoration" always appears 
> for the last rendered component in the loop.
> 
> So I have played around and managed to make things work. 
> Here's what I have done...
> 
> 1. Added component occurrence counter to 
> IdAllocator$NameGenerator. This will hold the actual count 
> of the times the component was rendered (doesn't count the 
> "degenerate" case).
> 2. Added a property (counter) to AbstractFormComponent to 
> hold the count of the rendered component. 
> This property + the component id will give a unique key for 
> the FieldTrackings form map.
> 3. Added new method getElementCount() in Form to return the 
> count of the component occurrence. This 
> will be used by the validation delegate to record a failed 
> field in the trackings form map.
> 4. The validation delegate's findCurrentTrackings() uses the 
> componentId + getElementCount() as the 
> key to register the component in the trackings form map.
> 5. The getComponentTrakings uses the componentId + 
> getElementCount() to retrieve the tracking from 
> the trackings form map.
> 
> Now I can validate a list in the listener method and record 
> the errors thus (not a realistic example):
> 
>              IFormComponent component = (IFormComponent) 
> getComponents().get("loopFld");
>              delegate.setFormComponent(component);
> 
>              component.setIndex(0); // Extra new step to 
> indentify the index
>              delegate.record("Invalid cust name.", null);
> 
>              component.setIndex(2); // Extra new step to 
> indentify the index
>              delegate.record("Invalid cust name.", null);
> 
> This doesn't break the current behavior and should be very 
> transparent.
> 
> I don't see why all form components can't be validatable 
> components. We can have a NullValidator 
> that can be used by default. Perhaps for 3.1 under a new 
> ValidationService :)
> 
> So is this committable?
> 
> -Harish
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Mime
View raw message