On Sat, May 30, 2009 at 2:05 AM, marius d. <marius.dan...@gmail.com> wrote:
> > > > On May 29, 4:32 pm, Oliver Lambert <olambo...@gmail.com> wrote: > > Hi Marius, > > To try and answer your question, I had to go and look at the Record code > in > > more detail. I hadn't recently written the Binder Validator, so it wasn't > > designed to be > > complementary to anything else (however, some of the naming and > methodology > > is very > > similar in both sets of code). > > > > What I found. > > 1) MetaRecord.validate === Binder.validate > > 2) Field.validators === BoundObj.validations > > 3) Field.validationFunction === Validator.validate > > 4) List[FieldError] === List[ValidationError] > > > > Can I get rid of Binder Validation and just use Record/Field validation? > > It certainly looks like I should try. However, I might have to add/change > > some of the original Lift code. > > For instance, I might want to add an errorType (with a default, so no > code > > is broken) to FieldError. > > I might also want to move/change Field.validationFunction so its a little > > more > > like my Validator,with an errorType and toString (When I print my > > validators, the errorType give a little > > information on what they do, rather than just telling me I have a > function - > > I also filter using > > the errorType) > > I think we should unify the models. What I particularly like about the > existent validators is that it rlies on function type hence the > flexibility to use anonymous functions or existent ones. SO IMHO it > would be really neat to keep the existent validators per Field and if > you would edd the errorType support would just great. > I think Ive managed to unify the models. There is a new Validator object, net.liftweb.record.Validator that has an implicit conversion that accepts a function (anonymous or otherwise) and wraps it in a Validator class with an errorType. Thus validators can be written as functions or classes, and as they are wrapped in a class it should be easy enough to add support for javascript validation. I can't really test it on the existing Record code, as I can't even manage to instanciate a simple record. I have however, refactored the immutable binding code. > Oh FWIW I'm not a fan of function names starting with capital letters > such as: def Range(lower: Int, upper: Int, errStr: String) .. but > that's just me. > Me neither. Don't know why I did this. > > > > > Other things of interest that I found. > > > > Could a Binder be a MetaRecord? There are definitely some similarities. > > Binder holds a set of > > immutable objects which can be an advantage, but MetaRecord can talk to > > databases which is > > kind of useful at times. > > I think we should keep the Meta Record and Record. Please keep in mind > that MetaRecord and Record have NOTHING to do with database, they are > completely separated per design so that Records can be also used > outside of a RDBMS scope. For DB we have DBMetaRecord and DBRecord > which are not fully implemented yet. > > > > > Could a BoundObj be a Field. Same distinction as above. A BoundObj[T] may > > hold a reference to a string value > > that is completely invalid. I'm not sure I see this in Field. > > > IMHO I would just add the features that your code has and current code > does not (such as error type) and put them in the MetaRecord/Record > (or wherever they belong) and have a single coherent model. Please > also take a deeper look on the existent code, in MetaRecord, Record, > Fields implementations Not DB Fields) and see what goodies can be > added from your new code. > > And integrating client side validations (as Dave suggested) in the > same model would be really cool. > > > > > cheers > > Oliver > > > > On Fri, May 29, 2009 at 6:22 PM, marius d. <marius.dan...@gmail.com> > wrote: > > > > > I see ... still the question remains. What are we going to do with two > > > validators? I'd like to understand the principles of your addition > > > (... I know I should have dig into the code but I don't have much time > > > now). > > > > > I'd like to understand as I said previously if we have redundant > > > validators or complementary functionality so that people to not get > > > confused. > > > > > I'm not trying at all to be negative or anything, just trying to > > > understand the value added. > > > > > Br's, > > > Marius > > > > > On May 29, 11:01 am, Oliver Lambert <olambo...@gmail.com> wrote: > > > > I'm aware of S.error and my ValidationError uses it when I'm ready to > > > show > > > > errors. I've briefly looked at the ValidationFunction and the thing I > > > might > > > > stumble on is the errorType which I rely on. > > > > > > I may be able to refactor the code to use List[FieldError] as I don't > > > think > > > > I rely on errorType at this point. > > > > > > I'll have a go at modifying the Binder code. > > > > > > cheers > > > > Oliver > > > > > > On Fri, May 29, 2009 at 5:05 PM, Marius <marius.dan...@gmail.com> > wrote: > > > > > > > Oliver, > > > > > > > I very briefly looked on your code and I saw that you have your own > > > > > validator there. How would that play with the existent validattors > > > > > that Record has where each field has a list of : > > > > > > > type ValidationFunction = MyType => Box[Node] > > > > > > > Note that current MetaRecord's validator after evaluating the > > > > > validators for each field it yields a List[FieldError] which can be > > > > > easily naturally used with S.error function to show the error > messages > > > > > etc. > > > > > > > Is there a redundancy or complementary functionality? > > > > > > > Br's, > > > > > Marius > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
