A somewhat better working example
Locked
A somewhat better working example
 
|
Some of you probably have followed my requests. Now I have attached a
somewhat working example. Well you better not try t use the Delete button in the edit form. This is still not working. And well it's uses "hard" coded strings, which by any means can't be taken serious. I've to find a nice way getting internationalization done. The last tip for getting the refresh down (after the click on the Delete link) was using el := WebElement new. el registerId. According to Janko this can be counted as a bug. IMHO there are many other things lackign also: 1) this lenghty rendering methods. Which are in honest just glorified Copy & Paste code (and this is *really* bad) 2) lacking validation on the elements 3) the toString fromString bottleneck (or put in the other way the representaton of "structured" data even as simple like Dates I doubt anyone has heard of it, but I feel checking out CLIM (the common Lisp interface management system) offers something. It is named Presenter/Accept. I think something along that would be very useful for web development. It was done and used e.g in CL-Http (see http://www.cl-http.org:8001/cl-http/) Other things which has come to my mind. Who is really responsible for presenting information. I think Aida and Iliad have gone a kind of "observer" pattern way, where as Seaside has put this responsibility on the objects itself. The Aida way is in the "spirit" of a model view separation. But I'm really not sure what's the better approach is. If we look though Smalltalk we find a lot of things like asxxx in the diverse classes. so it feel somewhat natural to have it. I thought about it up an down, but can not make anything out of it.... However my impression is a somewhat portable way of sending objects around would be a good thing to have. And in this area JSON would be my choice. It has advantages especially over presenting and marshalling via XML. It's the native interface to diverse NOSQL databases Couchdb etc. And it could be a nice interface to all non-Smalltalk users of our system. Maybe someone really is thinking about using such NOSQL databases as OO-Stores for Smalltalk. Wouldn't that be a good "match"? AFAIKT does Iliad support JSON..., so maybe Aida should follow them with that? Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
Aida-Tests-Tan-QSS-frido.7.mcz (7K)
Re: A somewhat better working example
|
|
Re: A somewhat better working example
|
|
Re: A somewhat better working example
|
|
Re: A somewhat better working example
|
|
Re: A somewhat better working example
|
|
Re: A somewhat better working example
|
|
Friedrich,
FD> I guess that's a reasonable assumption. Maybe it's usedTans which is not FD> initialized? What's does the stack trace say...? it's not usedTans, though it was nil but a initUsedTans didn't help. One of the things that come with Aida (maybe seaside too?) is that the stack trace may not be as helpful as we are used. From looking at it did you modify some Aida methods I don't have? Or something in Date? I guess you should not use #date in #showEditableParts but try the Float trick I mentioned earlier, like having #defaultDateFormat as accessors to date. FD> Well I postede soemthing to Janko. Maybe it should be discussed here FD> also? FD> IMHO validations are one of the most urgent problems. I wonder if you FD> have checked Andrés Vallhauds Sunit based Validation. I think it's very FD> well explained in "A mentoring Course on Smalltalk". Though I bought his books months ago I haven't gotten very far in reading. Both are not the kind of book you can freely skip around the pages. FD> He has published his code one the Cincom public repository. Maybe it FD> would be an idea to check out the SUnit based stuff there and think FD> about using it in Aida. There's also a Squeaksource project recently announced on Squeakdev. FD> I'm currently thinking about the following classes/object attached to FD> WebElements. FD> Accepter(s) (this will allow to read in Elements from different sources, FD> e.g there mayb be an CVSAccepte, a JSONAccepter, StringAcceptor or FD> whatever Yes, sounds useful. FD> Presenter(s) (I thought about it in the following way. On an "error" one FD> may want to have another color of the field which has points out the FD> error FD> For how this is done elswhere you can take CLIM as "example". FD> Decorators (according to some out line one may want to have diffrent FD> colors of lines in a collection to see what belongs to where. E.g even FD> numbers are darker than odd numbers. Isn't this a matter of building some CSS and use the appropriate (css)classes? FD> Validator(s). I think just having a block returning some boolean will FD> not work (it will be tedious and not very informative) I suggested what FD> to check out for it. Though I know I need validators I still fail to see how they belong to the Web framework. Having read the first 15 pages of the relevant part of Andres book seems to confirm that the validators belong to the model hierarchy. My Webapp's observee has an error variable which is set by asking the validator for it's errors and the Webapp decides on how to present the error(s). He has convincing arguments and when I really read this chapter I will refactor my validators to conform to the SUnit paradigm. If I where to do that refactoring now I would have to only change the single #displayErrorComponent method in the Webapp to handle more than a String. FD> Of course I've not written one line of code to support my FD> "points". However just imagine The discussion is useful anyway. And thanks for the pointer. FD> Now imagine FD> tanNr := new Webelemnt FD> tanNr validator: MustBeIntegerValidator new FD> tanNr presenter: JustBeEditableOnAdding new FD> date := new WebElement FD> date validator: MustBeDateInPast new. FD> date presenter: ISOxxxPresenter new. FD> date accepter: DateAccepter new In this case the accepter would need to employ the validator, same with the rest of the fields. FD> amount := new WebElement FD> amount validator: MustBeCurrencyValidator new. FD> .... FD> you see the points? Yes and the WebComponent consisting of these "fields" would be build by the same principle, in the end employing a more complex validator. But the model should do this accepting and validating. Actually the controller. Now that I write this I realize that the controller partly lives in the WebApp action methods. In my case the other part of the controller lives in the WebApp's observee which in my case sits between the WebApp and the real domain objects. FD> Now imagine we want different "aspects" of this object. One could imagine FD> having something in an Array. The following is very interesting but as far as it's described I see it only work for simple things. FD> I hope one can see what I mean I want to avoid FD> repeating code as much as possible and I want a "high level" expressive FD> way of getting the "usual" things done. With acting on the diverse FD> events we can go as much into the "how to do things" level as we like. FD> I do not want this: FD> showEditableParts: aWebElement FD> aWebElement newCell addText: 'TanNr'. FD> aWebElement newCell addInputFieldAspect: #tanNr for: self observee. FD> aWebElement newRow. agreed. For this I have: self addTabbingLineTo: e "onEnterTabulate for fast Entry via numeric keypad" header: 'TanNr:' selector: #tanNrText "invokes the validator on the model" receiver: self observee. When I use it often enough I'll stick it as another convenience method into WebElement. To iterate over a list to build a component is easy. It will simplify the code. And I will follow Andres book in one more aspect: My headers are the same as the accessors (except capitalization and appending 'Text' for the validation), so with a bit of reflection I will end up with: |headers| headers := #('Anfang' 'Ende' 'Radius' 'Parameter') e:= self buildInputComponentFor: self observee achselement headers: headers inputSize: 12 With some more reflection over the accessing protocol, I'd just have to hand in the object. Thanks for the discussion :-) FD> yes agreed I could put the editable Parts elswhere but FD> Imagine I want the amount to not be changeabel also. Ok and putting the type of input to build into another list is no biggie. I think Smalltalk has frameworks to do these things. Glamour for building browsers comes to mind. Or even WebGrid with its #columnAspects, ..align ..addBlocks When I've built more web applications I will know how (and if) these building blocks can be generalised. Cheers, Herbert mailto:[hidden email] _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
Re: A somewhat better working example
|
|
Re: A somewhat better working example
|
|
| Free forum by Nabble | Edit this page |