Re: using trinidad as non-default render-kit
This is definitely harder than I expected. What about coupling the
RenderingContext with the used RenderingKit? And droping the
RenderingContext ThreadLocal based access in favour of
FacesContext.getCurrentInstance().getRenderKit().getRenderingContext().
The RenderKitBase could probably extended for handling the
RenderingContext?
I dont quite understand the reason behind the
ExtendedRenderKitService.encodeEnd() and
encodeFinally() contract. The only implementation I found was the
CoreRenderKit, and its doing nothing basically except for the
RenderingContext creation. Theres also no such contract in the jsf
RenderKit, so enforcement may turn out to become difficult.
On 2/24/07, Adam Winer [EMAIL PROTECTED] wrote:
Stefan,
Take a look at the code in ViewHandlerImpl - w/regard
to ExtendedRenderKitService and its encodeBegin() method. You
don't need to have any direct reference to CoreRenderingContext.
(Also, by only mucking with encodeBegin(), this'll fail
if the first Trinidad component is rendersChildren. In
your page, perhaps it's not, but most actually are.)
Once you use that, then you have to satisfy the contract
of ExtendedRenderKitService - calling
ExtendedRenderKitService.encodeEnd() and
encodeFinally(). That second half is the bigger trick,
especially because you really have to do
ExtendedRenderKitService.encodeBegin(), etc. exactly
once per page, not multiple times.
-- Adam
On 2/22/07, Stefan Podkowinski [EMAIL PROTECTED] wrote:
Adam,
I think the CoreRenderer should take care of initializing the
RenderingContext. Facelets will be kind enough to set the rendering
kit in the FacesContext, as specified by the renderKitId attribute.
Since encodeBegin() will be called in the CoreRenderer impl., we
should know which RenderingContext we have to use, right?
Try the following hack. Its still not 100% working, but the page is rendering.
CoreRenderer.java:
public final void encodeBegin(FacesContext context,
UIComponent component) throws IOException
{
if (!getRendersChildren())
{
RenderingContext arc = RenderingContext.getCurrentInstance();
if (arc == null) {
//throw new IllegalStateException(No RenderingContext);
try {
Class ctxClazz =
Class.forName(org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext);
arc = (RenderingContext) ctxClazz.newInstance();
} catch (Exception e) {
throw new IllegalStateException(e);
}
}
FacesBean bean = getFacesBean(component);
encodeBegin(context, arc, component, bean);
}
}
On 2/22/07, Adam Winer [EMAIL PROTECTED] wrote:
How are you thinking of tackling this one?
I didn't have any great ideas.
-- Adam
On 2/21/07, Stefan Podkowinski [EMAIL PROTECTED] wrote:
Created the issue in jira.
https://issues.apache.org/jira/browse/ADFFACES-387
I'll hopefully be able to contribute a patch in the coming week, if I
have the time for it.
On 2/20/07, Adam Winer [EMAIL PROTECTED] wrote:
Yep, re-reading it, that's exactly what you said. Sorry
for the misunderstanding. So this is a tougher nut
to crack. I can imagine some hacks to try to
instantiate the rendering context on the fly, but
nothing really obvious and bulletproof comes to mind.
I think we need a JIRA issue...
-- Adam
On 2/20/07, Stefan Podkowinski [EMAIL PROTECTED] wrote:
Hi Adam
I already have trinidad working with facelets. The problem is it only
runs with trinidad as the *default rendering kit*. Defining trinidad
as the rendering kit per page does *not* work. Please see my first
mail for details.
On 2/19/07, Adam Winer [EMAIL PROTECTED] wrote:
Oh, I see. You're using Facelets. You need to configure things
a bit differently than without Facelets. Check out:
http://wiki.apache.org/myfaces/Facelets_with_Trinidad
-- Adam
On 2/16/07, Stefan Podkowinski [EMAIL PROTECTED] wrote:
I just tried the other way around by setting trinidad as default
render kit in faces-config.xml and f:view ..
renderKitId=HTML_BASIC. Afterwards the page renders fine but
I'm
getting an error on submit:
javax.faces.application.ViewExpiredException:
viewId:/jsfexamples/examples-simple-1.jsf - View
/jsfexamples/examples-simple-1.jsf could not be restored.
com.sun.faces.lifecycle.RestoreViewPhase.execute(
RestoreViewPhase.java:180)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java
:248)
If I remove trinidad as default rendere kit, submit works too.
Whats also a bit concerning here is that with trinidad as default
render kit, the following hidden field is also generated every
time
for the form tag, not taking f:view renderKitId=..
Re: Getting the Component ID from within getOnclick()
Sorry, I should have been clearer. In the renderer code on the server-side my component overrides the XhtmlRenderer.getOnclick() to insert some custom javascript. Within this method I'd like to be able to call getClientId() on the component to grab the id. Currently I'm having to use eval combined with this.id to workaround this issue, but it's not very clean. Danny On 2/27/07, Mike Kienenberger [EMAIL PROTECTED] wrote: Keeping in mind that I have barely a day's worth of practical javascript experience, maybe this.id or something along those lines? On 2/27/07, Danny Robinson [EMAIL PROTECTED] wrote: anyone ;-) On 2/23/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Any advice on how to easily retrieve the component ID from within an overridden method such as XhtmlRenderer.getOnclick(). The only parameter to this is FacesBean.Type, and not the component itself. Thanks, Danny -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com
Re: Getting the Component ID from within getOnclick()
Well, if the component is not passed in, you can't. The question is if the method signature should be changed. regards, Martin On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Sorry, I should have been clearer. In the renderer code on the server-side my component overrides the XhtmlRenderer.getOnclick() to insert some custom javascript. Within this method I'd like to be able to call getClientId() on the component to grab the id. Currently I'm having to use eval combined with this.id to workaround this issue, but it's not very clean. Danny On 2/27/07, Mike Kienenberger [EMAIL PROTECTED] wrote: Keeping in mind that I have barely a day's worth of practical javascript experience, maybe this.id or something along those lines? On 2/27/07, Danny Robinson [EMAIL PROTECTED] wrote: anyone ;-) On 2/23/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Any advice on how to easily retrieve the component ID from within an overridden method such as XhtmlRenderer.getOnclick(). The only parameter to this is FacesBean.Type, and not the component itself. Thanks, Danny -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Client-side validation - enhance to match server-side
Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com
Re: Client-side validation - enhance to match server-side
may be you can use GWT compiler for client side validation as well, it is also under Apache 2 license. On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Arash Rajaeeyan
Re: Client-side validation - enhance to match server-side
are you talking about still using JS for the client side converter/validator stuff, but just don't use alert(), instead using a web2.0-ish dialog ? The validator/converter stuff isn't just an alert(). We have client side Converter (with getAsObject/String) and Validators (with validate) and FacesMessage etc. Here is more on that interesting topic: http://incubator.apache.org/adffaces/devguide/clientValidation.html -Matthias On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Question on skinning just 1 table component.
Hi All,
On my JSF page, I have multiple tables (tr:table). For one of the table,
I want display it differently. I am currently passing in a value for
styleClass. My question is how can I apply the skin to just that table. I
don't want borders for the table. And I want the column header to display
with red background and bold txt.
tr:table value=#{test.values} var=value horizontalGridVisible=false
verticalGridVisible=false styleClass=noBorderTable
tr:column styleClass=columnTitle headerNoWrap=true align=center
f:facet name=header
tr:outputLabel value=header 1 /
/f:facet
tr:outputTextvalue=#{value.name} /
/tr:column
tr:column styleClass=columnTitle headerNoWrap=true align=center
f:facet name=header
tr:outputLabel value=header 2 /
/f:facet
tr:outputTextvalue=#{value.desc} /
/tr:column
tr:table
The following will change all of the table and column elements which is NOT
what I want. I need something specific to noBorderTable and columnTitle
af|table::content {
border: none;
}
af|column::header-text {
border: none;
background-color: red;
white-space: nowrap;
font-weight: bold;
}
Thanks,
Yao-Ning
Re: Client-side validation - enhance to match server-side
I was thinking that instead of displaying alert, the messages would appear in the same place as they do in server-side. So keep the existing javascript validator/converter stuff but change where/how it is displayed. We'd probably have to render a hidden container for each field, which the javascript would populate and make visible. Taking this route over a dialog means we could also probably provide some kind of on-tab-out instant validation for more data-entry heavy applications. That said these approaches are not mutually exclusive. Danny On 2/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: are you talking about still using JS for the client side converter/validator stuff, but just don't use alert(), instead using a web2.0-ish dialog ? The validator/converter stuff isn't just an alert(). We have client side Converter (with getAsObject/String) and Validators (with validate) and FacesMessage etc. Here is more on that interesting topic: http://incubator.apache.org/adffaces/devguide/clientValidation.html -Matthias On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Chordiant Software Inc. www.chordiant.com
Re: Client-side validation - enhance to match server-side
I've been reiterating the necessity for this time and again ;) - I'd be pretty much for an addition like this. regards, Martin On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: I was thinking that instead of displaying alert, the messages would appear in the same place as they do in server-side. So keep the existing javascript validator/converter stuff but change where/how it is displayed. We'd probably have to render a hidden container for each field, which the javascript would populate and make visible. Taking this route over a dialog means we could also probably provide some kind of on-tab-out instant validation for more data-entry heavy applications. That said these approaches are not mutually exclusive. Danny On 2/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: are you talking about still using JS for the client side converter/validator stuff, but just don't use alert(), instead using a web2.0-ish dialog ? The validator/converter stuff isn't just an alert(). We have client side Converter (with getAsObject/String) and Validators (with validate) and FacesMessage etc. Here is more on that interesting topic: http://incubator.apache.org/adffaces/devguide/clientValidation.html -Matthias On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Chordiant Software Inc. www.chordiant.com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [maven] assembly
Bernd? any suggestions? if not... see you Friday :-))) -Matthias On 2/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hello, I started to add to the RELEASE branch an assembly project, which will allow us to publish Trinidad CORE in source and as binary, as well. Therefore we don't publish a upcoming only to a maven2 repo. However, since the -demo project produces a WAR, I think we need a second assembly as well, for the demo. I took a look at Tobago and MyFaces Core, there this pattern (assembly for the project and another for the demo(s)) is used too. What do you think? Or is it possible to also use the one assembly for the JAR and WAR projects of Trinidad (-api,build, impl vs -demo) ? The first assembly I published here for a quick review: http://people.apache.org/~matzew/trinidad-assembly/ (I only did a upload of the ZIP file) When I finished the assembly stuff, I merge the profile also to trunk. Thanks, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: using trinidad as non-default render-kit
Changing how we get the RenderKit would break a lot of code,
so I'd be a big -1 on that.
There's other parts of the ExtendedRenderKitService
contract, and, yes, they'll be hard to enforce in general.
Facelets could actually fix this quite elegantly by
getting the renderKitId correct in createView(), which
should theoretically be possible.
I think the thing to do for this issue is to let CoreRenderer
call encodeBegin() if the RenderingContext hasn't been
called, and allow ViewHandlerImpl to recompute the
ExtendedRenderKitService after renderView() (since the
renderKitId will be correct by then).
-- Adam
On 2/28/07, Stefan Podkowinski [EMAIL PROTECTED] wrote:
This is definitely harder than I expected. What about coupling the
RenderingContext with the used RenderingKit? And droping the
RenderingContext ThreadLocal based access in favour of
FacesContext.getCurrentInstance().getRenderKit().getRenderingContext().
The RenderKitBase could probably extended for handling the
RenderingContext?
I dont quite understand the reason behind the
ExtendedRenderKitService.encodeEnd() and
encodeFinally() contract. The only implementation I found was the
CoreRenderKit, and its doing nothing basically except for the
RenderingContext creation. Theres also no such contract in the jsf
RenderKit, so enforcement may turn out to become difficult.
On 2/24/07, Adam Winer [EMAIL PROTECTED] wrote:
Stefan,
Take a look at the code in ViewHandlerImpl - w/regard
to ExtendedRenderKitService and its encodeBegin() method. You
don't need to have any direct reference to CoreRenderingContext.
(Also, by only mucking with encodeBegin(), this'll fail
if the first Trinidad component is rendersChildren. In
your page, perhaps it's not, but most actually are.)
Once you use that, then you have to satisfy the contract
of ExtendedRenderKitService - calling
ExtendedRenderKitService.encodeEnd() and
encodeFinally(). That second half is the bigger trick,
especially because you really have to do
ExtendedRenderKitService.encodeBegin(), etc. exactly
once per page, not multiple times.
-- Adam
On 2/22/07, Stefan Podkowinski [EMAIL PROTECTED] wrote:
Adam,
I think the CoreRenderer should take care of initializing the
RenderingContext. Facelets will be kind enough to set the rendering
kit in the FacesContext, as specified by the renderKitId attribute.
Since encodeBegin() will be called in the CoreRenderer impl., we
should know which RenderingContext we have to use, right?
Try the following hack. Its still not 100% working, but the page is
rendering.
CoreRenderer.java:
public final void encodeBegin(FacesContext context,
UIComponent component) throws IOException
{
if (!getRendersChildren())
{
RenderingContext arc = RenderingContext.getCurrentInstance();
if (arc == null) {
//throw new IllegalStateException(No RenderingContext);
try {
Class ctxClazz =
Class.forName(
org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext);
arc = (RenderingContext) ctxClazz.newInstance();
} catch (Exception e) {
throw new IllegalStateException(e);
}
}
FacesBean bean = getFacesBean(component);
encodeBegin(context, arc, component, bean);
}
}
On 2/22/07, Adam Winer [EMAIL PROTECTED] wrote:
How are you thinking of tackling this one?
I didn't have any great ideas.
-- Adam
On 2/21/07, Stefan Podkowinski [EMAIL PROTECTED] wrote:
Created the issue in jira.
https://issues.apache.org/jira/browse/ADFFACES-387
I'll hopefully be able to contribute a patch in the coming week,
if I
have the time for it.
On 2/20/07, Adam Winer [EMAIL PROTECTED] wrote:
Yep, re-reading it, that's exactly what you said. Sorry
for the misunderstanding. So this is a tougher nut
to crack. I can imagine some hacks to try to
instantiate the rendering context on the fly, but
nothing really obvious and bulletproof comes to mind.
I think we need a JIRA issue...
-- Adam
On 2/20/07, Stefan Podkowinski [EMAIL PROTECTED] wrote:
Hi Adam
I already have trinidad working with facelets. The problem is
it only
runs with trinidad as the *default rendering kit*. Defining
trinidad
as the rendering kit per page does *not* work. Please see my
first
mail for details.
On 2/19/07, Adam Winer [EMAIL PROTECTED] wrote:
Oh, I see. You're using Facelets. You need to configure
things
a bit differently than without Facelets. Check out:
http://wiki.apache.org/myfaces/Facelets_with_Trinidad
-- Adam
On 2/16/07, Stefan Podkowinski [EMAIL PROTECTED] wrote:
I just tried the other way around by setting trinidad as
default
render kit in faces-config.xml and f:view ..
Re: Client-side validation - enhance to match server-side
I'd be happy to see functionality like this too. The trickiest part is, I think, figuring out how to clear the messages. I agree with Matthias that we don't need GWT. We already have the client-side JS. It's just the code that decides to turn the messages into an alert that is the problem. -- Adam On 2/28/07, Martin Marinschek [EMAIL PROTECTED] wrote: I've been reiterating the necessity for this time and again ;) - I'd be pretty much for an addition like this. regards, Martin On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: I was thinking that instead of displaying alert, the messages would appear in the same place as they do in server-side. So keep the existing javascript validator/converter stuff but change where/how it is displayed. We'd probably have to render a hidden container for each field, which the javascript would populate and make visible. Taking this route over a dialog means we could also probably provide some kind of on-tab-out instant validation for more data-entry heavy applications. That said these approaches are not mutually exclusive. Danny On 2/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: are you talking about still using JS for the client side converter/validator stuff, but just don't use alert(), instead using a web2.0-ish dialog ? The validator/converter stuff isn't just an alert(). We have client side Converter (with getAsObject/String) and Validators (with validate) and FacesMessage etc. Here is more on that interesting topic: http://incubator.apache.org/adffaces/devguide/clientValidation.html -Matthias On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Chordiant Software Inc. www.chordiant.com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: @author tags
I agree as well. There's something a little nice about @author tags as a way of giving credit to the people who aren't the obvious people on a project. But they're rarely kept up to date, and the implication of ownership is not very OSS-friendly. -- Adam On 2/26/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 2/26/07, Scott O'Bryan [EMAIL PROTECTED] wrote: -1 for removing them. I don't see this as an ownership issue. It's helpful to know who in the community might be able to answer questions on a particular piece of code. I know with the Portal work I did, it was very handy to know WHO had written a piece of code, especially since they may not me monitoring the lists. This argument does not scale in the long term. My own experience is a case in point -- my name is still splattered over lots of the Catalina sources inside Tomcat, even though: * I have not worked on them for four years (but I still get 20 personal emails for Tomcat help every week). * In many cases, the number of lines of code that were mine originally is less than half of the total -- so the tag is totally misleading. * The real people you want to talk to are the ones who have been making recent commits, not whoever wrote the code in the first place. I am strongly i+1 on removing @author tags, for the community related reasons that have been previously published. Craig McClanahan
Re: @author tags
I'm +0 about it. I think it's nice to know who wrote a piece of code before you modify it, so you can ask a quick question to the author. The main example I can find in Trinidad is the use of Hashtable and Vector every now and then, was it because of the old 1.2 codebase or was synchronization required? A simple mail to the author would have answered that question. Then again, I can see Craig's point as well as ASF concerns. The best compromise I can find is maintaining a history of changes in the Javadoc with the author names, but I really don't think many of us (starting with me) will have the patience to keep such a thing up-to-date, hence the +0. On 2/28/07, Adam Winer [EMAIL PROTECTED] wrote: I agree as well. There's something a little nice about @author tags as a way of giving credit to the people who aren't the obvious people on a project. But they're rarely kept up to date, and the implication of ownership is not very OSS-friendly. -- Adam On 2/26/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 2/26/07, Scott O'Bryan [EMAIL PROTECTED] wrote: -1 for removing them. I don't see this as an ownership issue. It's helpful to know who in the community might be able to answer questions on a particular piece of code. I know with the Portal work I did, it was very handy to know WHO had written a piece of code, especially since they may not me monitoring the lists. This argument does not scale in the long term. My own experience is a case in point -- my name is still splattered over lots of the Catalina sources inside Tomcat, even though: * I have not worked on them for four years (but I still get 20 personal emails for Tomcat help every week). * In many cases, the number of lines of code that were mine originally is less than half of the total -- so the tag is totally misleading. * The real people you want to talk to are the ones who have been making recent commits, not whoever wrote the code in the first place. I am strongly i+1 on removing @author tags, for the community related reasons that have been previously published. Craig McClanahan
Re: Client-side validation - enhance to match server-side
the difference is with GWT, user can write java code for client side validation instead of JS. they can compile it with their own Java IDE. but I also agree that adding another dependency to MyFaces is not good, specially dependency to such a big project. On 3/1/07, Adam Winer [EMAIL PROTECTED] wrote: I'd be happy to see functionality like this too. The trickiest part is, I think, figuring out how to clear the messages. I agree with Matthias that we don't need GWT. We already have the client-side JS. It's just the code that decides to turn the messages into an alert that is the problem. -- Adam On 2/28/07, Martin Marinschek [EMAIL PROTECTED] wrote: I've been reiterating the necessity for this time and again ;) - I'd be pretty much for an addition like this. regards, Martin On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: I was thinking that instead of displaying alert, the messages would appear in the same place as they do in server-side. So keep the existing javascript validator/converter stuff but change where/how it is displayed. We'd probably have to render a hidden container for each field, which the javascript would populate and make visible. Taking this route over a dialog means we could also probably provide some kind of on-tab-out instant validation for more data-entry heavy applications. That said these approaches are not mutually exclusive. Danny On 2/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: are you talking about still using JS for the client side converter/validator stuff, but just don't use alert(), instead using a web2.0-ish dialog ? The validator/converter stuff isn't just an alert(). We have client side Converter (with getAsObject/String) and Validators (with validate) and FacesMessage etc. Here is more on that interesting topic: http://incubator.apache.org/adffaces/devguide/clientValidation.html -Matthias On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Chordiant Software Inc. www.chordiant.com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Arash Rajaeeyan
