Mario,Yes, I use addResource for the scriptlet, when I was working on the sandbox.Since there is not an extended form renderer in tomahawk(for now), I am using my own custom renderer for testing purposes in my workspace.
I've packed the current "unrefactored" code at my homepage,www.cagataycivici.c
Hi!
>
> Maybe I can have a look at the ClientConverter stuff?
>
>
> Sure, that would be great Mario.
Here is a proposal for the client converter stuff.
http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/common/converter/
Once we approv
On 7/13/06, Adam Winer <[EMAIL PROTECTED]> wrote:
As discussed earlier in this thread, I should be able to take
a validator someone else wrote and add Tomahawk validation
without subclassing ValidatorBase.
Adding the interface is far more flexible; there's no reason
not to do it.
Ok :) I fi
Mike,
As discussed earlier in this thread, I should be able to take
a validator someone else wrote and add Tomahawk validation
without subclassing ValidatorBase.
Adding the interface is far more flexible; there's no reason
not to do it.
-- Adam
On 7/13/06, Mike Kienenberger <[EMAIL PROTECTE
One thing I'd like to point out -- all of the validators in MyFaces
Tomahawk are intended to be subclassing ValidatorBase. Otherwise,
they're not going to pick up the common validator functionality that
we're putting in there. I'm not really certain why having an
interface adds any value if th
e for their needs, but I think a generic interface is better.
Nick
From: Cagatay Civici
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 13, 2006 1:15
AM
To: MyFaces Development
Subject: Re: Client Validation
Design Discussion
Hi,
No actually, I was talking about the Clie
To: MyFaces Development
Subject: Re: Client Validation
Design Discussion
Hi,
No actually, I was talking about the ClientValidator interface I've used when
working on the sandbox validators but hey this one is very similiar too. My
interface has methods like getJsFunction and getParam
Mario,Yes, this example explains a alot. Seems I've just needed an example to figure out the problem :)
Maybe I can have a look at the ClientConverter stuff?Sure, that would be great Mario.BTW The extended validators with no conversion requirement is almost ready:), I'll present another demo next w
Hi!
> The user has to
> input a "non valid" value in the context of JS as there is the
> currencySymbol (ok, not very realistic)
Matthias pointed out, that the currencySymbol is used only for output
I wonder, but ok, the problem is still the same.
---
Mario
Hi Cagatay!
> A hot discussion we are having here,
Yes, this is great :-)
> I think there is no new API here. Only thing needed is just a single
> interface. As I mentioned before most of the validators do not need
> any conversion before validating the input at all.
This is not necessarily true.
Hi,A hot discussion we are having here,I think there is no new API here. Only thing
needed is just a single interface. As I mentioned before most of the
validators do not need any conversion before validating the input at
all. We could embed converters like number and date to the client
validation
Hi Adam!
Hmmm ok, I understand the "chained validator" thing.
So, even if we go the client side converter way, I would like to have a
way to define the "allowed characters" for the input field.
Maybe by adding a method like
InputMask getInputMask()
to the ClientConverter interface. This ret
On 7/12/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
Well, the thing is that a merge is way off on the timeline.True, but OTOH, there's nothing stopping you from grabbingAPIs and code piecemeal from Trinidad today. That doesn'tneed to wait for the grand merge. And creating new APIs
that are
On 7/12/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Hi Martin!> Well, the thing is that a merge is way off on the timeline.> And Cagatay has something right now, why not take it in?No, I didnt meant to NOT take Cagatys work now. In fact I'd love to see
it imported soon. Its just the converter s
> But now I also think we should put our hands on the converter stuff,
> just, as far as I can see, in Trinidad they implemented a real client
> validator with getAsObject and getAsString - to say the truth, I dont
>
sorry, I meant "a real client converter"
>
> TNT would be cooler :)
>
> but Nobago sounds silly :)
*LOL*
---
Mario
Hi Martin!
> Well, the thing is that a merge is way off on the timeline.
> And Cagatay has something right now, why not take it in?
No, I didnt meant to NOT take Cagatys work now. In fact I'd love to see
it imported soon. Its just the converter stuff I was thinking about.
But now I also think we s
Then we should think about porting this to Trinidad as ours is more
powerful . ;-) *just kidding*
mixing best of all worlds is on the list.
On ApacheCon - during some beers (you know ;)) - Bernd and me also
discussed a "common" upload solution for TTT (Tomahawk, Tobago,
Trinidad)
TNT would
The real question is, should we reimplement all the stuff already
existing in Trinidad, or should we try hard to make Trinidad work with
other component libraries too.
I would like to see the second one instead of reinventing the weel over
and over again.
see my Renderers email. I'd like to intr
Hi Cagatay!
> By the way, these validators run only at onsubmit event of the form.
> I've also implemented simple "onkeypress validation" that allows only
> integers to be entered when there is an integeronly converter by
> disabling letters, or max-min length validation when there is a length
> va
Well, the thing is that a merge is way off on the timeline.
And Cagatay has something right now, why not take it in?
regards,
Martin
On 7/13/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Hi!
>
> > Also, recognize that client-side validation is only half of the
> > picture; you
>
Hi!
>
> > Also, recognize that client-side validation is only half of the
> > picture; you
> > also need client-side converters.
> Lets do this once needed. In fact, I hope Trinidad become a more
> integral part of MyFaces so that we can use Tomahawk and Trinidad and
> ...
t; >
> >
> >
> > So, IMO, +1 for an interface as well.
> >
> >
> >
> > Nick
> >
> >
> >
> >
>
> >
> > From: Adam Winer [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 12, 2
n
> implement.> >> >> >> > So, IMO, +1 for an interface as well.> >> >> >> > Nick> >> >> >> >
>> >> > From: Adam Winer [mailto:[EMAIL PROTECTED]]> > Sent: Wednesday, Jul
iner [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 12, 2006 11:34 AM
> To: MyFaces Development
> Subject: Re: Client Validation Design Discussion
>
>
>
>
> I think that having a ValidatorBase is reasonable enough, but that
> it's critical to make the real API an inter
06
11:34 AM
To: MyFaces Development
Subject: Re: Client Validation
Design Discussion
I think that having a
ValidatorBase is reasonable enough, but that
it's critical to make the real API an interface in this case. We can't
require that everyone on the planet extend from ValidatorBase
most situations, but it
allows for future interfaces that classes can implement.
So, IMO, +1 for an interface as well.
Nick
From: Adam Winer
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 12, 2006
11:34 AM
To: MyFaces Development
Subject: Re: Client Validation
Design Discussion
On 7/12/06, Cagatay Civici <[EMAIL PROTECTED]> wrote:
Hi,Although I fancy the interface design first because of the flexibility, since enabling all of the myfaces extended validators to do validation at client is necessary, validatorbase still seems the better way. Validatorbase is also a nice plac
Hi,Although I fancy the interface design first because of the flexibility, since enabling all of the myfaces extended validators to do validation at client is necessary, validatorbase still seems the better way. Validatorbase is also a nice place for the common client attribute. Anyway maybe a vote
On 7/12/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Hi!> For one example, what if I download> a third-party validator, and want to add client-side validation> support to it?> So, +1 for an interface.I dont think this is the best use-case as you still have to change the
original validator code (
Everyone brews its own soup here, as we can see ... but ok, I wont
complain about a interface as it allows a better flexibility if we think
we should provide a framework for others too.
I saw this
http://jcp.org/en/jsr/detail?id=303
during my daily blog reading, yesterday
> I'd also be -1 agai
Hi!
> For one example, what if I download
> a third-party validator, and want to add client-side validation
> support to it?
> So, +1 for an interface.
I dont think this is the best use-case as you still have to change the
original validator code (implement the interface). To achieve this
without t
I think that having a ValidatorBase is reasonable enough, but thatit's critical to make the real API an interface in this case. We can'trequire that everyone on the planet extend from ValidatorBase ifthey want to take part in this. For one example, what if I download
a third-party validator, and
Hi Cagatay!
> One more discussion topic, the client validation is turned on/off via
> a context parameter, org.apache.myfaces.ENABLE_CLIENT_VALIDATION,
> Do you think validators should override this global setting via an
> attribute like client?
client=true|false - yes, I think this will be a nice
Hi,Yes, using the validatorbase seems a better way in this case. Also as you said, it would be better to remove the abstract signature since it'll break other validators like in sandbox.One more discussion topic, the client validation is turned on/off via a context parameter,
org.apache.myfaces.EN
Hi Cagatay!
> There are two method getJsFunction() and getParams() that must be
> implemented by extended validators so which design seem more convenient?
>
> * Using an IClientSideValidator which will be implemented by extended
> validators marking them capable of doing validation at client side.
It seems to me that both ways lead to inheritance :)
I think that an interface should be used, especially if the *only*
goal of an abstract base class would be defining those two abstract
methods.
This is also more flexible because multiple interfaces inheritance is
allowed: suppose you have a v
37 matches
Mail list logo
