Am 14.07.2014 um 17:44 schrieb Esteban A. Maringolo <emaring...@gmail.com>:
> Are you going to be the end user of this? > Yes, it is pure internal functionality. > I wouldn't let users compile whatever Smalltalk expressions they want. > You can't scope the globals that can be accessed by the compiler. > Of course not. Sorry, I wasn't specific enough. > What I would do is model a hierarchy of "Condition" objects used by > "Filter" objects, which are composable, and know how to translate > themselves to SQL, Mongo condition, or even Smalltalk expressions to > apply the conditions to a collection of objects. > > The other way is to have a DSL, but that's a longer road if what you > plan is simply to apply filters. > I want a simple solution with powerful capabilities and therefor smalltalk is the perfect match IMHO. Norbert > We've done both in my previous job and worked perfectly. > > > Regards! > > > > Esteban A. Maringolo > > > 2014-07-14 12:19 GMT-03:00 Norbert Hartl <norb...@hartl.name>: >> I was looking for a solution where I can have a textual grammar for a DSL in >> order to specify filters on objects. I didn't really search the net because >> I know a cute little DSL for that already. It is called smalltalk, you might >> have heard of it. >> >> So what I do is putting the filter spec into the image via an http >> interface, materialize the filter in image and store it in a database to >> have them survive image restart. A filter spec could look like this >> >> [ :value | ( self sectionLabelOf: value ) = 'device' ] >> >> I want to know if there is any trouble to expect if I'm using plain block >> syntax for that task. As the blocks are injected using an http interface >> there is no environment/context problem. I would have some helper class as a >> facade to ease the filtering let's call it >> >> FilterHelper (would have a class side method #sectionLabelOf:) >> >> So getting the block code via HTTP I could do >> >> block := Smalltalk compiler >> evaluate: request contents >> for: FilterHelper >> logged: false >> >> And I would serialize it into a database as a string again doing >> >> self store: block sourceNode formattedCode >> >> Are there any possible drawbacks using it this way? >> >> thanks, >> >> Norbert >> >> >
