[
11:29am
]
balunasj
:
so everyone must be able to build this way - so even our 3.3.X builds will need to find some usable JSF 1.2 impl in there.
[
11:29am
]
•
balunasj
 
N.B. - everyone does not have to build this way, but they must BE ABLE to build this way
[
11:30am
]
balunasj
:
This is from a conversation with Paul yesterday
[
11:30am
]
balunasj
:
ok I think we have enough to go on here
[
11:30am
]
balunasj
:
we should move on to client side validation
[
11:30am
]
balunasj
:
so we have time
[
11:31am
]
balunasj
:
Emmanuel brought this up, and was disappointed we were not farther along
[
11:31am
]
balunasj
:
I know we touched base on this last meeting
[
11:31am
]
balunasj
:
but I wanted to make sure we all were on the smae page with this.
[
11:31am
]
mojavelinux
:
balunasj Stan uploads JSF
[
11:32am
]
mojavelinux
:
is that going into Seam Faces?
[
11:32am
]
balunasj
:
mojavelinux: I think that is what we need to determine so we can all move forward.
[
11:32am
]
balunasj
:
alexsmirnov: last time you had some thoughts on this
[
11:33am
]
balunasj
:
alexsmirnov: could you explain them some more -
[
11:33am
]
balunasj
:
alexsmirnov: I believe at the time you thought they required CDI to do right?
[
11:34am
]
pmuir
:
sorry, just got back
[
11:34am
]
alexsmirnov
:
I think that client side validation is up to RichFaces while it can use Hibernate or Seam server-side code.
[
11:34am
]
pmuir
:
re JSF/Mojarra, as you guys use the JBoss repo, you could upload it into our thirdparty nexus repo ok
[
11:34am
]
alexsmirnov
:
Graph validation is more up to Seam.
[
11:35am
]
pmuir
:
http://community.jboss.org/wiki/UploadingaThirdpartyArtifact
[
11:35am
]
balunasj
:
pmuir: yup that is part of what we discussed, problem there is then we maintain it.
[
11:36am
]
balunasj
:
pmuir: better to proxy, but we could do this if needed for 3.3.X i think
[
11:36am
]
mojavelinux
:
oh, alexsmirnov I got confused
[
11:36am
]
alexsmirnov
:
Currently, RichFaces can clone bean at the validation phase to store submitted values in that cloned object, so we can run validation on the graph of object without affecting real data.
[
11:36am
]
mojavelinux
:
it was graph validation that we were going to talk on
[
11:36am
]
mojavelinux
:
got that confused with client-side validation
[
11:36am
]
mojavelinux
:
in my memory of the conv
[
11:36am
]
balunasj
:
mojavelinux: it is a mixture of both imo
[
11:36am
]
pmuir
:
also, re. the java.net/central work - Sonatype are doing a masive cleanup of the repo before putting the artifacts into central. this includes cleaning up the POMs, removing bad uploads from central, fixing broken deps,
[
11:37am
]
pmuir
:
juven has been working on it full time for quite a while (like >1 month)
[
11:37am
]
mojavelinux
:
pmuir yep, but it is a one-time import too
[
11:37am
]
pmuir
:
no, we need to talk about client side validation
[
11:37am
]
pmuir
:
mojavelinux: i believe they are also then providing a repo for the java.net projects to use which will keep things correct
[
11:37am
]
pmuir
:
so, i don't think it's just a "dump"
[
11:38am
]
pmuir
:
not graph validation
[
11:38am
]
balunasj
:
From what alexsmirnov is saying RichFaces could handle client side validation, but require seam integration for client side graph validation
[
11:38am
]
balunasj
:
alexsmirnov: does that sound about right?
[
11:39am
]
alexsmirnov
:
Ok. I just want to point out that CDI/Seam can take care of object cloning, so we need them there.
[
11:39am
]
alexsmirnov
:
balunasj:  correct.
[
11:39am
]
pmuir
:
i think it is client side validation that we need to move on
[
11:39am
]
balunasj
:
alexsmirnov: ok goo
[
11:39am
]
balunasj
:
pmuir: agree
[
11:40am
]
balunasj
:
alexsmirnov: I know you have been busy with CDK
[
11:40am
]
alexsmirnov
:
Currently, we just "simulate" client-side validation by calling real validator via AJAX.
[
11:40am
]
balunasj
:
alexsmirnov: have you put anything design thought into client side?
[
11:40am
]
balunasj
:
alexsmirnov: I think brings up a fair point - lets define client-side
[
11:40am
]
balunasj
:
alexsmirnov: is it 100% client side - no ajax?
[
11:41am
]
balunasj
:
alexsmirnov: is it ajax validation ( allows for validating updated data from server
[
11:41am
]
balunasj
:
or is it both like what some other component do
[
11:41am
]
balunasj
:
where they have modes = "client/server/ajax"
[
11:42am
]
pmuir
:
100$ client side
[
11:42am
]
alexsmirnov
:
balunasj: In any case, validation should be performed no the both sides. Any data that coming from client should be validated before update.
[
11:42am
]
alexsmirnov
:
on the both
[
11:42am
]
pmuir
:
alexsmirnov: agreed
[
11:43am
]
balunasj
:
agreed as well - you almost always what to validate before update
[
11:43am
]
alexsmirnov
:
so, for the client side  we need a some JavaScript code that tightly related to the server-side.
[
11:44am
]
lincolnthree
:
Gotta run for a bit guys, will review when I return.
[
11:44am
]
•
balunasj
 
looking for old emails, threads on ths...
[
11:45am
]
alexsmirnov
:
My thought was to implement client-side validation as "behavior". It can read which validators used by component and render proper code.
[
11:45am
]
alexsmirnov
:
Client-side script for known types or AJAX call for general case.
[
11:45am
]
balunasj
:
alexsmirnov: ooo - I like that idea.
[
11:45am
]
lfryc left the chat room. (Remote host closed the connection)
[
11:46am
]
balunasj
:
would users need to set the behavior at all inputs?
[
11:46am
]
mojavelinux
:
right, and for the generation of the JavaScript, perhaps you could annotate a class for client-side like you currently annotate the real validator
[
11:46am
]
balunasj
:
or perhaps at the form/view level as well.
[
11:46am
]
mojavelinux
:
so the behavior would "resolve' the class which is to create the JavaScript
[
11:46am
]
alexsmirnov
:
It also requires custom massage components with some API to publish validation messages.
[
11:46am
]
mojavelinux
:
in a similar way
[
11:46am
]
Alex_Kolonitsky left the chat room. (Quit: Leaving.)
[
11:46am
]
mojavelinux
:
good point, do you create validation messages w/o involving the server
[
11:47am
]
balunasj
:
mojavelinux: would you really want more annotations?
[
11:47am
]
mojavelinux
:
I mean, the answer has to be yes
[
11:47am
]
mojavelinux
:
sure sounds like Spring JavaScript
[
11:47am
]
mojavelinux
:
no, not more annotations
[
11:47am
]
mojavelinux
:
I'm saying
[
11:47am
]
mojavelinux
:
you have something like
[
11:47am
]
alexsmirnov
:
balunasj: It can be done in the same way as f:ajax does, wit per-component and group
[
11:47am
]
mojavelinux
:
EmailValidatorJavaScript.java
[
11:47am
]
mojavelinux
:
an you annotate it @Email
[
11:47am
]
balunasj
:
alexsmirnov: +1
[
11:47am
]
mojavelinux
:
so the behaviors implementation says something like
[
11:48am
]
mojavelinux
:
go find me the generator for @Email
[
11:48am
]
mojavelinux
:
I'm just suggesting that the annotation is your "link"
[
11:48am
]
mojavelinux
:
when you seee
[
11:48am
]
mojavelinux
:
@Email public String getEmail() {}
[
11:49am
]
mojavelinux
:
because, this makes it so that the impl could be overridden, customized...if you do it all internally (internal factory)
[
11:49am
]
balunasj
:
mojavelinux: I could see something like that work well.
[
11:49am
]
mojavelinux
:
then people get stuck with the impl...and it's hard to extend w/ custom validators
[
11:49am
]
mojavelinux
:
because most of the time, the user is going to have to provide the JavaScript impl w/ the server-side impl
[
11:49am
]
balunasj
:
mojavelinux: either way we would need our one JS generator for each bean validator
[
11:49am
]
mojavelinux
:
when using bean validation that is
[
11:50am
]
alexsmirnov
:
mojavelinux: For the standard or Bean validators, we can extract messages from known place: Faces messages.properties or from annotation.
[
11:50am
]
mojavelinux
:
right, finding the message isn't the issue
[
11:50am
]
mojavelinux
:
Bean Validation solves that
[
11:50am
]
mojavelinux
:
the issue is how to weave it into the UI
[
11:50am
]
mojavelinux
:
how it gets styled, where it gets placed, etc
[
11:51am
]
mojavelinux
:
perhaps it just gets inserted where <h:message> is
[
11:51am
]
mojavelinux
:
for that field
[
11:51am
]
mojavelinux
:
but you just have to realize that you are manipulating the DOM w/ changing the server-side
[
11:51am
]
balunasj
:
we also want to make sure that client validation behaves the same as server side when a violation is found.
[
11:51am
]
mojavelinux
:
what do you mean by that
[
11:52am
]
balunasj
:
so if a user submits something that is right when client was rendered, but is now wrong because something on the server changed
[
11:52am
]
alexsmirnov
:
mojavelinux: That is my point: we can provide JavaScript for standard types, whatever Faces or Bean validators.
[
11:52am
]
balunasj
:
the reaction at the client level should be the same
[
11:52am
]
mojavelinux
:
alexsmirnov got it
[
11:52am
]
balunasj
:
alexsmirnov: we also want to allow plugable customer clientside validators
[
11:53am
]
pmuir
:
re how you decide what validators to apply, you need to use the composition stuff
[
11:53am
]
mojavelinux
:
right, that's why I'm suggesting this idea of the annotation
[
11:53am
]
alexsmirnov
:
Component developers can provide such code as well. For any other type client validator should transparently switches to AJAX.
[
11:53am
]
balunasj
:
so when people make their own validators they can also make their own client side version.
[
11:53am
]
mojavelinux
:
it's a triad
[
11:53am
]
mojavelinux
:
you have the annotation, the server-side impl and now a client-side impl
[
11:54am
]
mojavelinux
:
so the client-side impl needs to have a standard JavaScript "interface" to follow to perform the validation
[
11:54am
]
mojavelinux
:
just like the serverside one
[
11:54am
]
alexsmirnov
:
mojavelinux: sure.
[
11:56am
]
pmuir
:
i don't think having non-BV client side validators should be a first priority
[
11:56am
]
mojavelinux
:
function(beanType, propertyName, value, groups) {}
[
11:56am
]
balunasj
:
pmuir: you mean the ability for customer validators?
[
11:57am
]
pmuir
:
also, I just want to make sure you are all aware how the composition stuff works, as it's the intended way to do this stuff, and allows graceful degradation of capabilities
[
11:57am
]
pmuir
:
balunasj: yes
[
11:57am
]
balunasj
:
pmuir: agree - but I just want to make sure we keep in mind the ability to plugin custom ones
[
11:58am
]
balunasj
:
pmuir: can you explain what you mean with the composition a bit more?
[
12:00pm
]
pmuir
:
trying to find the blog about it
[
12:00pm
]
pmuir
:
http://in.relation.to/Bloggers/ConstraintCompositionProposalInBeanValidationJSR303
[
12:00pm
]
pmuir
:
also, the message stuff is a little more complex than you are fiscussing
[
12:00pm
]
pmuir
:
discussing
[
12:01pm
]
pmuir
:
let me check why again
[
12:02pm
]
balunasj
:
ok - so to me is seems we need to have a design/dev group get started with this.  Obviously I think that alexsmirnov should be part of it, and Dan seems to have a lot of ideas around this as well.
[
12:02pm
]
balunasj
:
We need to take the concepts here and the ones Pete is pointing out
[
12:02pm
]
alexsmirnov
:
pmuir: Of course, custom message interpolator can complete change messages, and it is not possible to infer from annotations.
[
12:02pm
]
pmuir
:
ah yes, because BV supports message interpolation
[
12:02pm
]
pmuir
:
http://docs.jboss.org/hibernate/stable/validator/reference/en/html_single/#section-message-interpolation
[
12:03pm
]
alexsmirnov
:
pmuir: you first
[
12:03pm
]
pmuir
:
emmanuel and I worked out a way to do this reasonably somewhere
[
12:03pm
]
balunasj
:
Come up with a plan and see what RF release we can get into
[
12:03pm
]
pmuir
:
this is definitely one to brainstorm on, as its not-obvious
[
12:04pm
]
balunasj
:
but we are all agreed that client side validation will be in RichFaces
[
12:04pm
]
pmuir
:
the other thing that occurred to me
[
12:04pm
]
balunasj
:
for some of it we will require seam integration ( graph  at least )
[
12:04pm
]
balunasj
:
pmuir: sorry pete - go ahead
[
12:05pm
]
pmuir
:
is that mojavelinux mentioned "the user is going to have to provide the JavaScript impl w/ the server-side impl"
[
12:05pm
]
Ilya
:
http://docs.jboss.org/hibernate/stable/validator/reference/en/html_single/#section-message-interpolation
[
12:05pm
]
Ilya
:
sorry..
[
12:05pm
]
pmuir
:
just so we are clear we are not suggesting putting the JS in literally the same file as the annotation
[
12:05pm
]
pmuir
:
I mean the java validator
[
12:06pm
]
alexsmirnov
:
pmuir: Custom validator requires custom lient-side script as well.
[
12:06pm
]
pmuir
:
but instead we should use some sort of convention approach I think such that the JS could co in a file like com/acme/FooValidator.js
[
12:06pm
]
pmuir
:
or similar
[
12:06pm
]
balunasj
:
alexsmirnov: correct, but I agree with pete we need to have is separated.
[
12:06pm
]
balunasj
:
in a standard way.
[
12:06pm
]
pmuir
:
rather than using some sort of registry
[
12:06pm
]
balunasj
:
pmuir: agree
[
12:06pm
]
pmuir
:
possibly a registry is useful as well
[
12:07pm
]
pmuir
:
idk
[
12:07pm
]
balunasj
:
We would ship with all the standard validators there
[
12:07pm
]
balunasj
:
but users who add there own could follow the same standard
[
12:07pm
]
pmuir
:
actually, thinking again, no registry, just rely on CP order
[
12:07pm
]
alexsmirnov
:
pmuir: Default place by convention with optional regestry.
[
12:07pm
]
balunasj
:
I would not want a registry I think.
[
12:07pm
]
pmuir
:
issue with a registry is you need to support hot-reloading
[
12:08pm
]
pmuir
:
so you need a trigger to flush it
[
12:08pm
]
balunasj
:
another thing to maintain.
[
12:08pm
]
balunasj
:
lets try it the first time without
[
12:08pm
]
balunasj
:
please
[
12:08pm
]
pmuir
:
yep
[
12:08pm
]
pmuir
:
also, can we please split this totally from gaph validation
[
12:08pm
]
pmuir
:
these two things should not depend on each other in any way
[
12:09pm
]
mojavelinux
:
okay, I get the compositions now
[
12:09pm
]
pmuir
:
yeah, composition is very powerful in this case
[
12:09pm
]
mojavelinux
:
so it's saying that the JavaScript could potentially just use some of the validations
[
12:09pm
]
mojavelinux
:
or could do them in bits
[
12:09pm
]
pmuir
:
as it means that a custom validator could do 50% of it work without the user writing any JS at all
[
12:09pm
]
balunasj
:
mojavelinux: you also need the ability to "nest" or chain them.
[
12:09pm
]
mojavelinux
:
like in the case, validate a number, validation min and max, but not having an impl for frenchcodevalidation
[
12:09pm
]
pmuir
:
exactly
[
12:10pm
]
mojavelinux
:
got it
[
12:10pm
]
pmuir
:
by then it's done 50% of the validation which is better than 0%
[
12:10pm
]
mojavelinux
:
lots of reuse
[
12:10pm
]
pmuir
:
and we provide the compositions
[
12:10pm
]
pmuir
:
the built in ones
[
12:10pm
]
pmuir
:
balunasj: no, the compositions are idempotent
[
12:10pm
]
mojavelinux
:
so Pete, what I was suggesting
[
12:10pm
]
mojavelinux
:
is that not that we provide a registery
[
12:10pm
]
pmuir
:
if you need ordering you must do it the main validator routine
[
12:10pm
]
mojavelinux
:
but that we provide a mapper/resolver
[
12:10pm
]
mojavelinux
:
a way to know how to get from @Max to MaxValidator.js
[
12:10pm
]
pmuir
:
yeah, that is a better approach
[
12:11pm
]
mojavelinux
:
you see that you need to include a validator as you scan the field
[
12:11pm
]
pmuir
:
though
[
12:11pm
]
alexsmirnov
:
mojavelinux: Yes, that was I have in mind.
[
12:11pm
]
pmuir
:
why do we need this?
[
12:11pm
]
mojavelinux
:
so how do you know which one, and the key is that you go from annotation -> resolver -> somewhere it lives
[
12:11pm
]
pmuir
:
why don't we reuse the Java stuff here
[
12:12pm
]
pmuir
:
i.e the validator already says "use this validator to validate something annotated with this constraint"
[
12:12pm
]
mojavelinux
:
that's what i was getting at first...that we annotate an interface impl that returns the path or something
[
12:12pm
]
pmuir
:
but why not reuse the existing class name?
[
12:12pm
]
mojavelinux
:
okay, by convention, yeah, I suppose my solution is overengineered
[
12:13pm
]
pmuir
:
it already says "this uses org.jboss.constrains.CheckCreditCardConstrain(.class)"
[
12:13pm
]
mojavelinux
:
makes sense that it's a 1-to-1 mapping
[
12:13pm
]
pmuir
:
what I am saying
[
12:13pm
]
mojavelinux
:
yep
[
12:13pm
]
mojavelinux
:
got it
[
12:13pm
]
pmuir
:
is substitute .class for .js
[
12:13pm
]
pmuir
:
and then reuse CP ordering
[
12:13pm
]
mojavelinux
:
I was thinking too abstract
[
12:13pm
]
pmuir
:
to provide override
[
12:13pm
]
mojavelinux
:
sure
[
12:13pm
]
balunasj
:
pmuir: yes  - I agree to fine the Javascript to replace
[
12:13pm
]
pmuir
:
this also means that you can easily support existing validators without having to recompile the constraints
[
12:13pm
]
mojavelinux
:
+1
[
12:14pm
]
mojavelinux
:
huge +1 there
[
12:14pm
]
pmuir
:
if you had to add an annotations, we would need a xml config for this etc.
[
12:14pm
]
balunasj
:
alexsmirnov: do you think there will be times where you need to update the JS?
[
12:14pm
]
•
balunasj
 
hoping no
[
12:14pm
]
alexsmirnov
:
pmuir: That is fine for default. Custom mapping is necessary if you going to override default one or need a bunch of scripts for different render kits.
[
12:14pm
]
pmuir
:
no, you don't need custom mapping to override
[
12:14pm
]
pmuir
:
and render kits are dead
[
12:15pm
]
mojavelinux
:
so is this something that's going to be richfaces specific? I mean, do I need to use RichFaces as a component library to get this
[
12:15pm
]
mojavelinux
:
of course, this goes to my whole "we should have a programming model-oriented library choice"
[
12:15pm
]
balunasj
:
mojavelinux: as apposed to needing seam-faces to do this?
[
12:15pm
]
balunasj
:
opposed
[
12:16pm
]
pmuir
:
well it depends, it won't depend on the ui components (I hope
[
12:16pm
]
pmuir
:
but it would depend on core?
[
12:16pm
]
alexsmirnov
:
mojavelinux: at least, it requires our message components, and JavaScript framework.
[
12:16pm
]
balunasj
:
pmuir: it may need some interactions with messaging if it is going to be customer stuff.
[
12:16pm
]
balunasj
:
custom
[
12:17pm
]
pmuir
:
i think it could depend on core
[
12:17pm
]
mojavelinux
:
pmuir right, we want it to look like <h:inputText id="email" value="#{customer.email}"/>
[
12:17pm
]
mojavelinux
:
it just happens
[
12:17pm
]
pmuir
:
esp if core will coexist with other JSF component sets happily
[
12:17pm
]
pmuir
:
mojavelinux: definitely
[
12:18pm
]
mojavelinux
:
the tricky part is that this requires a lot of infrastructure
[
12:18pm
]
Ilya
:
alexsmirnov, why only our  mesages? could we lookup standard messages as for placeholder for messages output?
[
12:18pm
]
mojavelinux
:
and that is where we say, okay, "Seam Faces" or "RichFaces core library"
[
12:19pm
]
balunasj
:
pmuir: mojavelinux : so you guys want client side bean validation always on?
[
12:19pm
]
balunasj
:
if the bean has it set.
[
12:19pm
]
balunasj
:
alexsmirnov was discussing a behavior to trigger it
[
12:21pm
]
balunasj
:
I could see using standard messaging - that will likely be fine.
[
12:21pm
]
balunasj
:
but don't you think people will want more control over the BV on the client side?
[
12:21pm
]
Ilya
:
mojavelinux, pmuir, balunasj, I believe it should not be like always on.. I checed Oracle ADF client validation some time ago and sometimes it's really weird that you could not control if you want to validate on both sides or just at server side
[
12:22pm
]
pmuir
:
we should have an analagous range of controls as in JSF2
[
12:22pm
]
pmuir
:
i.e. you can enable it globally
[
12:22pm
]
pmuir
:
or per form
[
12:22pm
]
pmuir
:
or per field
[
12:22pm
]
pmuir
:
if you enable it globally, then you can disable per-X
[
12:22pm
]
balunasj
:
pmuir: agree with that
[
12:22pm
]
pmuir
:
but we should have it auto on
[
12:23pm
]
balunasj
:
that is alot like our queues
[
12:23pm
]
pmuir
:
it's just a switch in web.xml to turn it off
[
12:23pm
]
pmuir
:
and it's also exactly like it happens in JSF so it's easy to understand
[
12:23pm
]
balunasj
:
pmuir: that I'm fine with - you are just talking about a default setting
[
12:23pm
]
pmuir
:
yes
[
12:23pm
]
balunasj
:
pmuir: was not sure if we were on same page
[
12:24pm
]
balunasj
:
good - then I'm ok with that level of control.
[
12:24pm
]
mojavelinux
:
yep, and we have something matching <f:validateBean> to control what is on/off
[
12:24pm
]
pmuir
:
are there any other technical concerns?
[
12:24pm
]
mojavelinux
:
could even have different validation groups on/off than on server
[
12:24pm
]
mojavelinux
:
<f:clientValidationBean disable="true"/>
[
12:24pm
]
•
balunasj
 
agrees with pmuir lets wrap up, and assign tasks
[
12:25pm
]
balunasj
:
pmuir: one thought is to have this in RichFaces, but outside of the /ui
[
12:25pm
]
pmuir
:
yeah, we need to work out some approx of idea when this can be ready
[
12:25pm
]
pmuir
:
balunasj: not sure on your exact layout
[
12:25pm
]
pmuir
:
but ideally this should work happily with other stuff
[
12:25pm
]
balunasj
:
alexsmirnov: although we would likely need UI core for the JS framework.
[
12:25pm
]
pmuir
:
like in a ICEFaces page
[
12:26pm
]
balunasj
:
pmuir: agree - that is the general goal anyway - but I think it is more specific with this though.
[
12:27pm
]
balunasj
:
ok so alexsmirnov & mojavelinux do you guys want to take the lead on this?
[
12:27pm
]
balunasj
:
then we can start breaking up "next actions"
[
12:27pm
]
pmuir
:
make sure you run any design past emmanuel as well as he has thought through how to do this before
[
12:28pm
]
balunasj
:
pmuir: agree
[
12:28pm
]
balunasj
:
I think a wiki page with the ideas would be best for review.
[
12:28pm
]
alexsmirnov
:
Ok, because I already did some part of that.
[
12:28pm
]
balunasj
:
alexsmirnov:
[
12:29pm
]
balunasj
:
mojavelinux: will you have the time for this, or is perhap more in lincolnthree's corner?
[
12:29pm
]
alexsmirnov
:
I think we can just started with AJAX code that delegates validation calls to server.
[
12:29pm
]
mojavelinux
:
lincolnthree is the point man for the faces, but I'll be involved for sure
[
12:29pm
]
balunasj
:
mojavelinux: ok - and pmuir you are ok with that?
[
12:30pm
]
alexsmirnov
:
Then extend it with custom client script for known validators ( length, min/max, empty and so on ).
[
12:30pm
]
pmuir
:
i think one person should lead it
[
12:30pm
]
pmuir
:
with others advising
[
12:31pm
]
balunasj
:
pmuir: ok sure
[
12:31pm
]
balunasj
:
alexsmirnov: can you lead this?  When will you be wrapped up with the CDK and A2 tasks for now?
[
12:32pm
]
alexsmirnov
:
I hope I can. CDK seems on the finish way.
[
12:32pm
]
pmuir
:
otherwise mojavelinux emmanuel and I can help out with review etc
[
12:32pm
]
balunasj
:
although I would ask mojavelinux or lincolnthree to assist with wiki pages to make it go faster for alexsmirnov
[
12:32pm
]
pmuir
:
yeah, thats a good idea
[
12:32pm
]
balunasj
:
yes so that sounds good.
[
12:33pm
]
balunasj
:
alexsmirnov: will you be able to work on this next week?  or do we need to talk more?
[
12:33pm
]
ppitonak joined the chat room.
[
12:35pm
]
pmuir
:
i would also like an approx of idea of when we can get this done
[
12:35pm
]
alexsmirnov
:
balunasj: I'll create wiki page with my vision about validation. Really, I already started writing though it the form of outline now.
[
12:35pm
]
pmuir
:
at least a beta
[
12:35pm
]
balunasj
:
pmuir: agree
[
12:35pm
]
balunasj
:
alexsmirnov: what are your thoughts on effort and timing?
[
12:36pm
]
balunasj
:
I'm sure we can get some assistance to, once impl is started, if needed.
[
12:37pm
]
alexsmirnov
:
Not sure how much it would take. Ajax validation in RF 3 was done for 3-4 weeks, I guess client-side would take the same or more.
[
12:38pm
]
alexsmirnov
:
That is rough estimate.
[
12:39pm
]
balunasj
:
Once you work through the wiki do you think you'll be able to be more precise
[
12:39pm
]
balunasj
:
pmuir: I think a good goal here would be to have beta - at least available by JBW
[
12:42pm
]
balunasj
:
are we just burnt out now