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
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
req
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 P
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.
--
Two approaches:
(1)
protected String getOnclick(FacesBean bean)
{
return null;
}
protected String getOnclick(FacesContext context,
UIComponent component, FacesBean bean)
{
String onclick = super.getOnclick(bean);
... perform extra manipulation ...
return onclick;
}
...
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
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 publi
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
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
javascr
Hi All,
On my JSF page, I have multiple tables (). 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
wi
well,
there is already convertion/validation done on the client.
I am not really interested in adding GWT dependency to Trinidad.
-M
On 2/28/07, Arash Rajaeeyan <[EMAIL PROTECTED]> wrote:
may be you can use GWT compiler for client side validation as well, it is
also under Apache 2 license.
On
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 F
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
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 l
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 XhtmlRende
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 combi
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 wel
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 f
+1 to removing author tags.. I would like to see a contributors file though
(adding to the pom would
probably a bit too much).
Btw there is a tool for this (relicense.pl), should probably be somewhere in
the committers area I
guess :)
Mvgr,
Martin
Matthias Wessendorf wrote:
> moved discussion
now the trunk (1.0.1-incubating-snap) has a dependency to the release
plugins (1.0.0-incubating)
-M
On 2/27/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
ok,
I'll change the pom to reflact that.
(I need to add a tag for that, since the m2-incubator
repo isn't published to ibiblio)
-M
20 matches
Mail list logo