Table Component Persistence Mechanism

[Derek Brown <ze...@yahoo.com>]

Hello,

I have a persistent property named user in a component
that shows details about a user. A listener in another
component invokes a viewAction method, from within
this method is it possible to change this property
safely from within another component? So that I can
avoid a Page recorder locked after commit error. The
table component changes the sortColumn parameter which
is persistent, is there a simpler way of doing this? I
am not entirely sure how this mechanism works, any
pointers?

What I'm trying to do above is to get a user from a
table component via a directlink with a parameter and
set the user of the view component, the user is a
persistent property on the view component because it's
paged and i'd like it to remember which user it was
on.

I am currently using the visit class for this, but I
would like to keep all logic within the component.


Thanks


	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

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

Re: Alternate validation framework - feedback request

[Derek Brown <ze...@yahoo.com>]

Hello,

Yes please make it available. Can define global
validators? Should be an easy feature to add.

Thanks

--- kranga <kr...@k2d2.org> wrote:

> Hi,
>     I've created an altenate validation framework to
> suit the needs of my
> app and also to address some annoying aspects of
> Tapestry's validation
> framework. I'd like your feedback on what I've done
> and if there is a large
> interest in it, I'll make it available.
> 
> Tapestry Validation Framework - What I didn't like:
> a) Form takes a delegate which seems to have been
> specifically created only
> for validation. The delegate requires definition of
> a delegate bean - I
> shouldn't have to help the framework do its job.
> b) The error messages are either add/remove elements
> before/after field or
> display error messages on top.
> c) Javascript produces pop-up window. No good site
> uses popup windows for
> errors.
> d) I cannot specify multiple validation delegates
> for a field - example
> numeric (range from 0.0 to 1000.0) AND string to
> limit overall length. I'd
> have to create a new validator.
> e) When you have forms in a foreach loop, things go
> crazy because the same
> delegate instance is shared and this throws all
> errors off!
> 
> My solution:
> a) You have to wrap the form in a
> ValidationController component. Why?
> Because I can't subclass Form to introduce code
> before and after
> renderBody() call. I'll have to pretty much
> replicate entire code from
> Form.renderComponent into my subclass. The
> ValidationController allows you
> to specify a property that will be set to indicate
> validation status.
> b) ValidFields (my version of them) allow you to
> specify a list of
> validators separated by comma. They also support
> setting an "errorCSS"
> property and a property to be updated if the field
> fails validation.
> c) Display of errors is separate from the field.
> They are self-contained
> components called ErrorDisplay that take a field
> parameter (simple name of
> ValidField component that it should work against or
> controller to indicate
> overall validation of form). The ErrorDisplay can do
> one of two things:
>         i) Make an error message appear if there is
> a field/form error (the
> message display area can be either blank or
> collapsed before validation is
> performed).
>         ii) Add an errorCSS element to any element
>   You can have as many ErrorDisplay components as
> you want for each field
> (or for the form's overall validation state).
> d) Javascript validation simply produces the exact
> same result as form
> posting would. Elements get decoraetd with errorCSS
> or error messages
> appear!!
> 
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> 
> 



		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 

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

Alternate validation framework - feedback request

[kranga <kr...@k2d2.org>]

Hi,
    I've created an altenate validation framework to suit the needs of my
app and also to address some annoying aspects of Tapestry's validation
framework. I'd like your feedback on what I've done and if there is a large
interest in it, I'll make it available.

Tapestry Validation Framework - What I didn't like:
a) Form takes a delegate which seems to have been specifically created only
for validation. The delegate requires definition of a delegate bean - I
shouldn't have to help the framework do its job.
b) The error messages are either add/remove elements before/after field or
display error messages on top.
c) Javascript produces pop-up window. No good site uses popup windows for
errors.
d) I cannot specify multiple validation delegates for a field - example
numeric (range from 0.0 to 1000.0) AND string to limit overall length. I'd
have to create a new validator.
e) When you have forms in a foreach loop, things go crazy because the same
delegate instance is shared and this throws all errors off!

My solution:
a) You have to wrap the form in a ValidationController component. Why?
Because I can't subclass Form to introduce code before and after
renderBody() call. I'll have to pretty much replicate entire code from
Form.renderComponent into my subclass. The ValidationController allows you
to specify a property that will be set to indicate validation status.
b) ValidFields (my version of them) allow you to specify a list of
validators separated by comma. They also support setting an "errorCSS"
property and a property to be updated if the field fails validation.
c) Display of errors is separate from the field. They are self-contained
components called ErrorDisplay that take a field parameter (simple name of
ValidField component that it should work against or controller to indicate
overall validation of form). The ErrorDisplay can do one of two things:
        i) Make an error message appear if there is a field/form error (the
message display area can be either blank or collapsed before validation is
performed).
        ii) Add an errorCSS element to any element
  You can have as many ErrorDisplay components as you want for each field
(or for the form's overall validation state).
d) Javascript validation simply produces the exact same result as form
posting would. Elements get decoraetd with errorCSS or error messages
appear!!



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