[Lift] Re: Record with the new bind-immutable
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 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 -~--~~~~--~~--~--~---
[Lift] Re: Record with the new bind-immutable
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 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 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 -~--~~~~--~~--~--~---
[Lift] Re: Record with the new bind-immutable
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) 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. 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. cheers Oliver On Fri, May 29, 2009 at 6:22 PM, marius d. 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 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 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 -~--~~~~--~~--~--~---
[Lift] Re: Record with the new bind-immutable
One thing I've been thinking about is optionally extending the Validator Functions to also emit JavaScript that would perform the validation in the browser... that would provide a seamless way to do client-side validation for validators (e.g., min len, max len, regex) that only rely on client-side data. On Fri, May 29, 2009 at 6:32 AM, Oliver Lambert 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) > > 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. > > 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. > > cheers > Oliver > > On Fri, May 29, 2009 at 6:22 PM, marius d. 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 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 >> 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 >> >> > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Record with the new bind-immutable
Oh, and I think I now have a better understanding of why David wanted me to add this to the Record module. On Fri, May 29, 2009 at 11:32 PM, Oliver Lambert 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) > > 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. > > 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. > > cheers > Oliver > > On Fri, May 29, 2009 at 6:22 PM, marius d. 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 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 >> 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 -~--~~~~--~~--~--~---
[Lift] Re: Record with the new bind-immutable
That would be very cool On Fri, May 29, 2009 at 11:37 PM, David Pollak < feeder.of.the.be...@gmail.com> wrote: > One thing I've been thinking about is optionally extending the Validator > Functions to also emit JavaScript that would perform the validation in the > browser... that would provide a seamless way to do client-side validation > for validators (e.g., min len, max len, regex) that only rely on client-side > data. > > > On Fri, May 29, 2009 at 6:32 AM, Oliver Lambert 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) >> >> 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. >> >> 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. >> >> cheers >> Oliver >> >> On Fri, May 29, 2009 at 6:22 PM, marius d. 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 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 >>> 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 >>> >>> >> >> >> > > > -- > Lift, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Git some: http://github.com/dpp > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Record with the new bind-immutable
On May 29, 4:32 pm, Oliver Lambert 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. 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. > > 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. 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 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 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.googl
[Lift] Re: Record with the new bind-immutable
On Sat, May 30, 2009 at 2:05 AM, marius d. wrote: > > > > On May 29, 4:32 pm, Oliver Lambert 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. > 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 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 > wrote: > > > > > > > Oliver, > > > > > > > I very briefly looked on your code and I saw that you
