Validation enhancements?
Locked
Validation enhancements?
 
|
Re: Validation enhancements?
|
|
Hi Friedrich,
FD> The validation of elements. If we add input elements to forms we do it FD> via the add..Aspect:for: functions. But we have to declare the FD> validation in an extra step. let me speak from my experience so far. In general I agree with both of your posts. But I doubt, my validator would solve your problems or that yours would be useful to me. My abstract class InputValidator verifies the basics String, REBInteger and REBFloat instead of Integer and Float. The concrete classes verify over groups of inputs. In the attachment you can see verification for some of the CRUD operations. FD> field := e newCell addInputFieldAspect: #tanNr for: self observee. In this case I write e addInputFieldAspect: #floatNumberText for: self observee. floatNumberText allows for + 123 456,789 as a Float before validation. FD> like this: FD> field := e newCell addInputField: ... for: ... validateAgainst: FD> someBlock? someValidatorObject? yes but also depending on the particular CRUD operation. See attachment. I have buttons for add, update, delete which trigger the validator. FD> well than we still have the question on when this validation will be FD> handeled. If JavaScript is active this validation can be run directly FD> on the Client, but we probably need some other validation rules (either FD> if someone does not have JavaScript active) or if we want to assure that FD> our model data are ok. Anyway the code probably has to emit two FD> different validation functions. One in JavaScript one in Smalltalk. For this I have WebElement>>addClickDo: aBlock andUpdateFunction: aJavaScript which is still an ugly hack but I want to propose this for inclusion in AIDA when it's ready. For some information on the rationale behind this see: http://article.gmane.org/gmane.comp.web.server.aida/2649 In the even older discussions with Alex Baran we planned to have a whole event system based on this. FD> But maybe it's just me beeing to dumb... Definitely not! We need CRUD operations on a grid, we need input verification and we need parts done in the server and parts done in the browser. All IMHO that is. There's another thing I wish for and that's sending JSON back and forth. When somebody clicks on a line in a grid which should be highlighted (rowBoldIfTrue: aBlock) instead of the previously highlighted line, up to now we are: -letting the server know about the newly selected line, -rebuilding the component(s), -replacing the new id's with the old ones -creating the whole HTML of the component(s) and -sending it I want to just send: [{id=1 class='WebGrid'},... {id=7 class='Blue'} ...] and have some JavaScript update the DOM. Maybe I'm straying too far from the path of REST here. But I need my web application perform like my locally running spreadsheet, so in my very constrained time I work towards this. Another thing my grids need is a slider. The current way (rowsOnPage) was not acceptable for me last time I looked. Right now I have a slider beside my grid which indicates which of the 100 rows of a table are displayed in the 10 row grid. Navigating the grid with the slider doesn't work yet. And it will put a big load on the server if it has to go through all the above steps instead of sending a JSON array of 50 floats and have JavaScript update the HTML. Cheers, Herbert mailto:[hidden email] _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
RB# DA53Validator.png (56K)
Re: Validation enhancements?
|
|
Re: Validation enhancements?
|
|
Re: Validation enhancements?
|
|
Re: Validation enhancements?
|
|
Re: Validation enhancements?
|
|
Re: Validation enhancements?
|
|
Hi Friedrich,
FD> Well have you a examples of it in an Aida application? I'm not sure if I understand you here but this is how it goes: The add/change Button triggers the action method #addOrChangePosition in the Aida application. This sends self observee addOrChangeSelectedPosition. This reads: addOrChangeSelectedPosition self isValidSelectedPosition ifFalse: [^self]. self canAddSelectedPosition ifTrue: [self addSelectedPosition] ifFalse: [self canChangeSelectedPosition ifTrue: [self changeSelectedPosition]] Finally isValidSelectedPosition is implemented as: isValidSelectedPosition |validator isValid| validator := DA53Validator new. "<---------------------------" validator dA53: selectedPosition; abrechnung: abrechnung. isValid := validator isValid . lastError := validator lastError. ^isValid I'm still not sure if the model should have readily initialized validators. As I said in another post basic type validation happens in the Web application. It goes like: In viewAddPosition (which is active in the browser in the png) the 4 lines for entering a position are put in a method #displayPositionForEntryComponent which consists of four statements like: self addTabbingLineTo: e header: 'Vorgabemasse:' selector: #vorgabeMasseText receiver: selectedPosition size: 40. where #vorgabeMasseText(:) are implemented in the receiver for accessing a Float ivar. This comes from a suggestion of Janko that Aida itself could deal with getters and setters for Strings and Integers on its own and that for Floats one should implement accessors #floatText which do the Float to String conversion. I used this for implementing basic validation and formatting like: DA53>>vorgabeMasseText ^vorgabeMasse printShowingDecimalPlaces: 3 and: DA53>>vorgabeMasseText: aString aString ifValidForFloatSend: #vorgabeMasse: to: self So I added to the clutter in String by burdening it with basic input validation. Hopefully that answers your question. Cheers, Herbert mailto:[hidden email] _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
| Free forum by Nabble | Edit this page |