You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Francois Armand <fa...@linagora.com> on 2007/12/13 10:12:02 UTC

"error" image near fields and text browser : remove it ?

Hello,

Near each fields in a form, there is an error image with css classes 
"t-error-icon" and  "t-invisible". The t-invisible class is removed if 
the field is in error, to signal what field is faulty.

This behaviour is problematic with text browser.
Well, you will say that nobody use them anymore, but in the case of 
blinded people, they use an equivalent that read pages for them, and 
don't care of the CSS. The problem is that for this kind of browser, all 
fields seems to be on fault since the first access to the form.

So it would be great if there were a way to remove this image, and add 
it *only* when there is actually an error. And javascript validate can 
add the img node if needed.

Anyone knows how to do that ?

-- 
Francois Armand
Etudes & Développements J2EE
Groupe Linagora - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
InterLDAP - http://interldap.org 
FederID - http://www.federid.org/
Open Source identities management and federation


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


Re: "error" image near fields and text browser : remove it ?

Posted by Chris Lewis <ch...@bellsouth.net>.
I haven't tried this yet, but on seeing this message I couldn't believe 
that this service (DefaultValidationDecorator) couldn't be completely 
replaced using existing T5 IoC infrastructure. From a quick glance at 
the T5 source code it /looks like/ there are (at least) 1 way of 
replacing this service:

*Provide a contributePageRenderInitializer method in your AppModule.
*TapestryModule is T5's internal "AppModule" that wires up all of the 
core services. It provides the method contributePageRenderInitializer 
which contributes several MarkupRendererFilter implementations, one of 
which adds DefaultValidationDecorator. This filter is added with the 
service id "DefaultValidationDecorator."
It seems to me that you could simply provide a 
contributePageRenderInitializer method in your own AppModule, implement 
a filter in the exact same manner (except provide you own implementation 
of ValidationDecorator), and add that filter with the same service id 
("DefaultValidationDecorator"). This should replace the implementation 
across the whole registry, and therefore your entire app. No nasty page 
subclassing, no JIRA (assuming I'm right ;-))

Of course the T5 IoC, or perhaps the TapestryModule could be loosened up 
a bit so you could simply provide a class name (autobinding) of your 
validator, instead of (re)implementing the filter.

Thoughts?

chris


Kristian Marinkovic wrote:
> Hi Francois,
>
> the images are generate by the DefaultValidationDecorator.
> You can provide your own (as i did :)) by implementing the 
> ValidationDecorator interface or extending BaseValidationDecorator. 
> Then you have to replace the DefaultValidationDecorator 
> in the environment with your implementation...
>
> @Inject
> private Environment environment;
>  
> @Inject
> private ThreadLocale threadLocale;
>
> public void setupRender() {
>     environment.push(ValidationDecorator.class, 
>            new CssValidationDecorator(environment,threadLocale));
> }
>
> .. and every Form component on your page will use this decorator
>
> the drawback is that you have to do it in every page you want
> to replace the ValidationDecorator (alternatively you can have a
> BasePage that every page in your project extends). i've already
> file a JIRA so you can change it globally.
>
> https://issues.apache.org/jira/browse/TAPESTRY-1754
>
> g,
> kris
>
>
>
>
> Francois Armand <fa...@linagora.com> 
> 13.12.2007 14:55
> Bitte antworten an
> "Tapestry users" <us...@tapestry.apache.org>
>
>
> An
> Tapestry users <us...@tapestry.apache.org>
> Kopie
>
> Thema
> Re: "error" image near fields and text browser : remove it ?
>
>
>
>
>
>
>
> Francois Armand wrote:
>   
>> Hello,
>> [...]
>> This behaviour is problematic with text browser.
>> Well, you will say that nobody use them anymore, but in the case of 
>> blinded people, they use an equivalent that read pages for them, and 
>> don't care of the CSS. The problem is that for this kind of browser, 
>> all fields seems to be on fault since the first access to the form.
>>     
>
> Well, it seems that a lot of things are broken with text browser. It 
> seems that a lot of form do not work, perhaps due to some persisted value.
> I think/hope it is due to the alpha status, and that it will evolve in a 
> near future.
>
>   


Re: "error" image near fields and text browser : remove it ?

Posted by Francois Armand <fa...@linagora.com>.
Kristian Marinkovic wrote:
> Hi Francois,
>
>   
Hello,
> the images are generate by the DefaultValidationDecorator.
> You can provide your own (as i did :)) by implementing the 
> ValidationDecorator interface or extending BaseValidationDecorator. 
> Then you have to replace the DefaultValidationDecorator 
> in the environment with your implementation...
>   
Thank you for your advice, I will do that :)

-- 
Francois Armand
Etudes & Développements J2EE
Groupe Linagora - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
InterLDAP - http://interldap.org 
FederID - http://www.federid.org/
Open Source identities management and federation


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


Re: "error" image near fields and text browser : remove it ?

Posted by Kristian Marinkovic <kr...@porsche.co.at>.
Hi Francois,

the images are generate by the DefaultValidationDecorator.
You can provide your own (as i did :)) by implementing the 
ValidationDecorator interface or extending BaseValidationDecorator. 
Then you have to replace the DefaultValidationDecorator 
in the environment with your implementation...

@Inject
private Environment environment;
 
@Inject
private ThreadLocale threadLocale;

public void setupRender() {
    environment.push(ValidationDecorator.class, 
           new CssValidationDecorator(environment,threadLocale));
}

.. and every Form component on your page will use this decorator

the drawback is that you have to do it in every page you want
to replace the ValidationDecorator (alternatively you can have a
BasePage that every page in your project extends). i've already
file a JIRA so you can change it globally.

https://issues.apache.org/jira/browse/TAPESTRY-1754

g,
kris




Francois Armand <fa...@linagora.com> 
13.12.2007 14:55
Bitte antworten an
"Tapestry users" <us...@tapestry.apache.org>


An
Tapestry users <us...@tapestry.apache.org>
Kopie

Thema
Re: "error" image near fields and text browser : remove it ?







Francois Armand wrote:
> Hello,
> [...]
> This behaviour is problematic with text browser.
> Well, you will say that nobody use them anymore, but in the case of 
> blinded people, they use an equivalent that read pages for them, and 
> don't care of the CSS. The problem is that for this kind of browser, 
> all fields seems to be on fault since the first access to the form.

Well, it seems that a lot of things are broken with text browser. It 
seems that a lot of form do not work, perhaps due to some persisted value.
I think/hope it is due to the alpha status, and that it will evolve in a 
near future.

-- 
Francois Armand
Etudes & Développements J2EE
Groupe Linagora - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
InterLDAP - http://interldap.org 
FederID - http://www.federid.org/
Open Source identities management and federation


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



Re: "error" image near fields and text browser : remove it ?

Posted by Francois Armand <fa...@linagora.com>.
Francois Armand wrote:
> Hello,
> [...]
> This behaviour is problematic with text browser.
> Well, you will say that nobody use them anymore, but in the case of 
> blinded people, they use an equivalent that read pages for them, and 
> don't care of the CSS. The problem is that for this kind of browser, 
> all fields seems to be on fault since the first access to the form.

Well, it seems that a lot of things are broken with text browser. It 
seems that a lot of form do not work, perhaps due to some persisted value.
I think/hope it is due to the alpha status, and that it will evolve in a 
near future.

-- 
Francois Armand
Etudes & Développements J2EE
Groupe Linagora - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
InterLDAP - http://interldap.org 
FederID - http://www.federid.org/
Open Source identities management and federation


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