[Pharo-users] Roassal configuration missing Glamour dependency
I loaded Roassal2 from the Configuration Browser and it added some menu items, one of which produces a debug statement about GLMPager. The problem is easily remedied by installing Glamour. I suggest there is a missing dependency in ConfigurationOfRoassal2. — Daniel Lyons
Re: [Pharo-users] Roassal configuration missing Glamour dependency
It's worse than that anyway, now it's missing GTInspector. What package provides that class? > On Dec 14, 2014, at 3:06 AM, stepharo wrote: > > I think that roassal packaging is naive. > Roassal core should not depend from Glamour > and there should be a RoassalGlamour configuration > > Stf > Le 14/12/14 07:21, Daniel Lyons a écrit : >> I loaded Roassal2 from the Configuration Browser and it added some menu >> items, one of which produces a debug statement about GLMPager. The problem >> is easily remedied by installing Glamour. I suggest there is a missing >> dependency in ConfigurationOfRoassal2. >> >> — >> Daniel Lyons >> >> >> >> >> >> > > — Daniel Lyons
Re: [Pharo-users] Question about Morphic in Pharo 4
> On Dec 18, 2014, at 3:31 PM, stepharo wrote: > > Hi > > You never know but in general we pay attention not to break for the shake of > it. > Then Morphic is several things >- low level >- widgets >- polymorph > So this is difficult to be fully affirmative. What I can say is that we did > not change much. Not the OP, but I've been confused about the history and future plan for some time. My impression is that Morphic must have started out as a small and beautiful core. Otherwise you wouldn't find so many people talking about how amazing it was in writings dated 10 years ago and earlier. It must have been much faster and easier to work with than the earlier MVC. Then I guess it grew rapidly and radically out of control and became this monstrosity sitting in the Squeak image, which has been pared down significantly in the Pharo image but is still basically huge. Squeak mostly evolved by shared changes to the image, so there was no concept of separate packages adding this or that method to this system class, so everything eventually wound up depending on everything. As our infrastructure is inherited, we inherit this problem, even as we go about breaking everything down and simplifying it, there is a long way to go to get back to the original small and beautiful core—and that may not even really be a goal for Pharo and Morphic. Is this fair and accurate? I have also heard that Morphic made more sense in its original habitat in Self, because you really could just clone a UI component and start customizing it, because Self only has instances, no classes. The "direct manipulation" argument is slightly sabotaged by the intrusion of a class hierarchy and textual coding. I'm just regurgitating a wisp of a memory though, I don't know if anybody who used it a lot would agree or not. (I'm not sure how one is able to make comprehensive principled changes in such a system, but that's an unnecessary diversion.) It seems to me that as Morphic halos get harder to get access to, direct manipulation becomes harder to effect; on the other hand, halos are probably a lot more confusing to beginners than helpful to anyone. Comments? From there I'm not quite sure what Polymorph is and what its development status/future outlook are like. Is it actively developed and are we happy with people building new stuff with it? Seems like it was the preferred UI paradigm a few years ago but now we have Spec. Spec seems to be promising non-Morphic backends, is that an active development interest and if so what targets are being explored? Historically, Morphic itself seems to promise multiple backends (the comment on Canvas says "A canvas is a two-dimensional medium on which morphs are drawn in a device-independent manner"), did that ever come to fruition, or did they just mean it supported different kinds of monitors? In the old books I see a lot of mentions of things like "pluggable" widgets, and in the image I see things like PluggableTextMorph. Following the Spec tutorial (which is excellent, by the way!), it feels like I have a lot of manual copying around of data in whenTextChanged: handlers. In fact, the old books also talk about the changed/changed:/changed:with: observer system, which I see is still in the image but it's not clear to me if any of these systems make use of that or if this whole system is considered deprecated. My suspicion is that it is deprecated because there is NewValueHolder. Is it? I'm mostly asking for history as I try to get my bearings and not trying to deprecate anyone or anything, so if anything in the above is offensive, it is an accident, please correct me. Thanks, — Daniel Lyons
Re: [Pharo-users] Question about Morphic in Pharo 4
> On Dec 19, 2014, at 9:24 AM, kilon alios wrote: > > That also may have to do with how I work which is that I was raised with > legos so I love to assemble things together instead of abstracting them away > which I think is what Spec tries to do. So Morphic definitely fits my way of > thinking better. My brother and I both played with Legos a lot as kids. We'd each get a big set. I would follow the instructions and build the model on the box. Then I'd play with it, and eventually get bored with it and it would go on the shelf. My brother would get halfway through following the instructions and get bored, start making his own stuff. Eventually the pieces would wind up in the big bin under his bed, along with whatever bits and pieces he hadn't taken apart yet. I always thought his stuff was terrible, didn't look as cool as what was on the box. He always thought I was boring because I'd just build the one or two things it would tell you how to make. Today, I am a professional Java web developer, with roots in Python, Haskell and Prolog. My brother, on the other hand, is a writer, potter, musician, and professional industrial hygienist but does not program at all. When you compare Smalltalk programmers to other developers, you get a lot of people who taught themselves by messing around in the image (autodidacts) and you have a lot of people who only know Smalltalk and don't really use other languages. The autodidacts I think, tend to love Morphic. But I'm not sure how many of them learned it in Pharo versus Squeak. And I think most of you probably loved Legos and were a lot more like my brother, building your own things to suit yourselves from your own imagination. Part of the genius of Pharo, in my opinion, is that it is a lot more welcoming to people like me. The downside, of course, is that you have to deal with a lot more people like me. :) Have you seen the Lego Master Builder series? They realized there were a lot of kids out there who would benefit from more documentation. Even unimaginative parents like myself can benefit from them. I got Lego MBA #1 and read the manual closely. It's obviously intended for a 10–12-year-old but I benefited from it. Spec's documentation is a lot like the Lego MBA. You're not the target audience, I am. I wish everything in the image were documented like that. I think that was sort of the intention behind Pharo by Example, which I read and got a lot out of. Spec's documentation being out there and Polymorph/Morphic not having anything like it definitely sends a message about Polymorph and Morphic though, which leads to questions like mine. — Daniel Lyons
[Pharo-users] Spec: "pluggable" widgets / label-input layout?
Supposing I have a domain model, Activity, which looks like this:
Object subclass: #Activity
instanceVariableNames: 'title cost'
classVariableNames: ''
category: 'PERT'
Then I have the expected accessors for title and cost.
I make a Polymorph dialog for editing one of these things like so:
PolymorphEditActivity>>edit: anActivity
| builder content dialog |
activity := anActivity.
builder := Smalltalk ui theme builder.
content := builder newLabelGroup: {
'Title' -> (builder newTextEntryFor: self activity getText:
#title setText: #title: help: 'The title of the activity').
'Cost' -> (builder newTextEntryFor: self activity getText:
#cost setText: #cost: help: 'The cost of the activity')
}.
dialog := builder newPluggableDialogWindow: 'Edit activity' for:
content.
^ builder openModal: dialog.
*First question*: how do I return a value from the dialog?
Now the Spec version of this I have looks like this:
ComposableModel subclass: #SpecEditActivity
instanceVariableNames: 'activity titleLabel costLabel titleWidget
costWidget'
classVariableNames: ''
category: 'PERT'
SpecEditActivity>>initializeWidgets
"Set up the widgets for the dialog"
titleWidget := self newTextInput.
titleLabel := self newLabel.
costWidget := self newTextInput.
costLabel := self newLabel.
titleLabel label: 'Title:'.
costLabel label: 'Cost:'.
self focusOrder
add: titleWidget;
add: costWidget
SpecEditActivity>>initializePresenter
super initializePresenter.
titleWidget whenTextChanged: [ :newText | activity title: newText ].
costWidget whenTextChanged: [ :newCost | activity cost: newCost ]
Then on the class side of things, I have this layout:
SpecEditActivity class>>layout
^ SpecLayout composed
newColumn: [ :column |
column
newRow: [ :row |
row
add: #titleLabel;
add: #titleWidget ];
newRow: [ :row |
row
add: #costLabel;
add: #costWidget ] ];
yourself
I make all the expected "getter" methods.
I can see how to get the model value out: I do something like this:
activityDialog := SpecEditActivity new openDialogWithSpec; yourself.
activityDialog model activity
I have two questions about the Spec side of the house:
1. The title/costWidget whenTextChanged: stuff. With Polymorph, I can just say,
here's an object, here's the getter/setter, deal with it. Does Spec have
anything like this, or do you have to do this manual data shuffling? Is there
an example I can learn from?
2. This layout is a bit on the ugly side. I looked at the examples and saw
usage of the expert layout with asking how tall a line is. Is that the best
that can be done, or is there something more like Polymorph's label layout that
can be used instead?
Thanks for your time and patience!
—
Daniel Lyons
Re: [Pharo-users] Spec: "pluggable" widgets / label-input layout?
> On Dec 20, 2014, at 4:06 AM, Nicolai Hess wrote: > > The spec part of your question: > > 2014-12-20 5:49 GMT+01:00 Daniel Lyons <mailto:fus...@storytotell.org>>: > Supposing I have a domain model, Activity, which looks like this: > > Object subclass: #Activity > instanceVariableNames: 'title cost' > classVariableNames: '' > category: 'PERT' > > Then I have the expected accessors for title and cost. > > Now the Spec version of this I have looks like this: > > SpecEditActivity>>initializePresenter > super initializePresenter. > titleWidget whenTextChanged: [ :newText | activity title: newText ]. > costWidget whenTextChanged: [ :newCost | activity cost: newCost ] > > Then on the class side of things, I have this layout: > > SpecEditActivity class>>layout > > ^ SpecLayout composed > newColumn: [ :column | > column > newRow: [ :row | > row > add: #titleLabel; > add: #titleWidget ]; > newRow: [ :row | > row > add: #costLabel; > add: #costWidget ] ]; > yourself > > I make all the expected "getter" methods. > > I can see how to get the model value out: I do something like this: > > activityDialog := SpecEditActivity new openDialogWithSpec; yourself. > activityDialog model activity > > First, please don't add a method #layout on the class side, this conflicts > with the notion of "Slots" (bug reported, but it is not fixed yet) Don't add a method to do the layout or don't name it #layout? The tutorial doesn't say what to name the method, just that it can be named anything using the pragma. > > > I have two questions about the Spec side of the house: > > 1. The title/costWidget whenTextChanged: stuff. With Polymorph, I can just > say, here's an object, here's the getter/setter, deal with it. Does Spec have > anything like this, or do you have to do this manual data shuffling? Is there > an example I can learn from? > > If you just want to show an edit dialog, I would separate the Acitivty-Model > (two textfields) from your domain model "Activity". Then you don't need this > "whenTextChanged". This is only needed if other elements from the model > depend on the textfield content. > > Now you can use spec to only show a dialog and after closing this dialog you > can retrieve the values with > > activitiy title: theDialogModel titleWidget text > activity cost: theDialogModel costWidget text > OK, but two questions: 1. How do I know when the dialog is finished? 2. That's going to be a lot of manual copying compared to the Polymorph version. Is that just life or are there "pluggable" widgets that will talk to my model directly? > > > 2. This layout is a bit on the ugly side. I looked at the examples and saw > usage of the expert layout with asking how tall a line is. Is that the best > that can be done, or is there something more like Polymorph's label layout > that can be used instead? > > you can define the hight of the rows based on the inputfield default height > (based on the current theme) (ComposableModel class >>#defaultInputHeight > > Take a look at Komitters CredentialEditor Thanks! > > > Thanks for your time and patience! > > — > Daniel Lyons — Daniel Lyons
[Pharo-users] Glamour detecting changes?
I have a pretty simple class and I'm using a GLMFinder to browse its contents. If I make changes to the instance I'm browsing, it doesn't look like Glamour detects the changes and refreshes. I'm using self changed: #property in the setter. If I navigate backwards and unselect, and re-browse into it, it sees the changes. What should I do? Thanks again! — Daniel Lyons
Re: [Pharo-users] Glamour detecting changes?
Doru, buildBrowser browser := GLMFinder new. browser show: [ :a | a list display: #children; format: #title ]. browser title: 'Project Browser' And then #title: looks like this: title: anObject title := anObject. self changed: #title > On Dec 21, 2014, at 12:56 PM, Tudor Girba wrote: > > Could you provide the code snippet you use for building the finder browser? > > Cheers, > Doru > > On Sun, Dec 21, 2014 at 3:46 AM, Daniel Lyons <mailto:fus...@storytotell.org>> wrote: > I have a pretty simple class and I'm using a GLMFinder to browse its > contents. If I make changes to the instance I'm browsing, it doesn't look > like Glamour detects the changes and refreshes. I'm using self changed: > #property in the setter. If I navigate backwards and unselect, and re-browse > into it, it sees the changes. What should I do? > > Thanks again! > — > Daniel Lyons > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow" — Daniel Lyons
Re: [Pharo-users] [ANN] Spec documentation in PFTE book finished
> On Dec 28, 2014, at 3:17 PM, stepharo wrote: > > I would be interested by having an example that I could use to rewrite the > spec documentation: >- would be good to have a kind of container relationships >to be able to display multiple list >- the model should not be too complex to explain. > > So if you have data and idea I'm all ears. I have about 1/2 of an application written to implement PERT, which is something management types study for doing project cost estimation, but usually don't use in reality. It has a nice container hierarchy (Project > Phase > Task > Task > ... > Task). I have part of the UI written in Glamour and part in Spec, but it isn't finished. I'm using this as a tutorial to teach my wife Pharo—although I'm probably not so great at it that I should be teaching anybody. :) The tutorial isn't as far along as the application and is probably wrongly titled at this point. I'm happy to give away the code and the tutorial but I'm a little stuck now since we have just had a baby and are now preparing to move in three weeks. So I apologize for the rough state of affairs, but since you asked I only hope it may be better than nothing. The tutorial can be read here: http://st.7gf.org/PERT/ <http://st.7gf.org/PERT/> PDF: http://st.7gf.org/PERT/PERT.pdf <http://st.7gf.org/PERT/PERT.pdf> Markdown source: http://st.7gf.org/PERT/PERT.md <http://st.7gf.org/PERT/PERT.md> Additionally I have a whiteboard capture of the interface I envision with Glamour (which may or may not be appropriate). The size is quite large despite the low quality, my apologies: http://st.7gf.org/PERT/project-window <http://st.7gf.org/PERT/project-window>.jpg http://st.7gf.org/PERT/simulation-window.jpg <http://st.7gf.org/PERT/simulation-window.jpg> http://st.7gf.org/PERT/project-graph-diagram.jpg It would be hard to come up with a more "boring" and "business" application domain than this… but for management people the problem is pretty well-known and for my wife, her only prior programming experience (not counting Excel) is C and the experience has been positive for her so far. She's also greatly enjoying going through my paper copy of Pharo by Example and the built-in tutorial. The basic concept, in case anyone is interested, is that you can form a directed acyclic graph between subtasks and then using min/max cost estimates, determine which tasks are "critical" and which tasks can be late without affecting the deadline or budget. The "project window" above uses a GLFinder-like approach to allow drilling down into subtasks from projects and phases. This means you're stuck with a tree instead of a DAG. The target level of sophistication for the final application is one that can use expected costs and a beta distribution to simulate thousands of different possible outcomes and then aggregate from there to see which tasks are likely to be troublesome or have bad estimates. This is what is pictured in the simulation-window mockup. The project graph diagram is just a sketch of something that would be trivial to do with Roassal. The project and task/activity objects should be fairly obvious. Phase is just recognition of the idea that projects are usually implemented in phases, and you usually have to complete one phase before starting the next: e.g., you must have made the prototype before you can put it into production. This layer is unnecessary from a computational point of view (there's nothing like it in the wiki page for PERT either) but it's a helpful organizational tool, plus it lets you create a nice boundary to get back some of the nice things about having a DAG that you lose with a tree representation. I don't know if this is what you're looking for or not but here it is. All the best, — Daniel Lyons
Re: [Pharo-users] [ANN] Spec documentation in PFTE book finished
All that and I forgot to include the link to the code. http://smalltalkhub.com/#!/~DanielLyons/PERT <http://smalltalkhub.com/#!/~DanielLyons/PERT> — Daniel Lyons
Re: [Pharo-users] Stackoverflow, was: [Pharo-dev] Could we keep Pharo-dev for Pharo-dev?
kilon alios writes: > Yeah StackOverflow has serious issues with moderation but still that does > not change the fact that is a popular site where tons of developers go > there to find answers to their questions. I asked my own questions on SO > about Pharo and so far I have not been disappointed. The Prolog section does pretty well by having a small but significant community that watch the Prolog tag like hawks. There are still "drive-by moderation" incidents but by and large it isn't a huge problem. There also is no general Prolog mailing list around which to organize, so a substantial community is able to organize just around Stack Overflow instead. The big advantage of Stack Overflow is that googling your question finds it there with an actual answer. Googling your question about Pharo often lands you in the middle of a conversation on the mailing list, replicated on some random site without enough context or useful navigation, while the actual answers may be buried deep in some thread. Or the question never got answered, but people went on to talk about different things, but Google sees the question in the subject repeated many times and assumes this is a useful page. Stack Overflow doesn't let this kind of thing happen. Things tend to move so quickly with Pharo that an answer on the mailing list from 2011 is often practically useless today. That would be a problem with old Pharo questions on Stack Overflow as well, except that Stack Overflow doesn't make a point of drawing your attention to the age of the answer. It's good and bad; good that things are moving quickly and improving, bad in that a lot of that knowledge has a short shelf-life. This phenomenon seems to be shared with Smalltalk, very few books go into much detail about what's in the image, and the ones that do are all greatly outdated because what's in the image changes fast. Ruby and Javascript are also like this. Prolog is almost ideal for Stack Overflow because everybody who shows up is asking the same questions (taking the same classes at the same universities, probably), and the system hasn't changed much in the last thirty years. Stack Overflow is good at fossilizing knowledge, but not every system benefits from that. -- Daniel Lyons
[Pharo-users] parsing a file / stream API advice
This is an OO design question. For my task, I have some objects and a particular file format that encodes them. I want to be able to read the file and create those objects. The Stream API seems like the right way to do this, but I'm not sure how to encapsulate my code. I see these options: • Create a new class (subclass of Object) that implements #next to return the next object in some underlying stream. Pro: very simple, one place with all the code. Con: what about the rest of the Stream and/or Collection APIs? Is it wise to delegate everything else to the underlying stream with #doesNotUnderstand:? • Create a new class, subclass of Stream, that implements #next like the above. Pro: still pretty simple, not sure what is needed to implement the API completely (I did add a method #atEnd). Con: not sure if more methods are missing; unclear about initialization (overrode class>>#on: to call #basicNew). This seems close to the right approach but I'm unsure. • Create a method #nextFoo on the existing Stream class. Pro: very simple—no new class. Con: nextFoo doesn't integrate well with the rest of the API (#do: for instance), not sure this is clean or wise. • Ignore the Stream classes altogether. Pro: No chance of misundestanding. :) Con: everything else. Advice? Thanks for your time, — Daniel Lyons
Re: [Pharo-users] parsing a file / stream API advice
Thanks to all of you for the advice! > On Jan 18, 2015, at 9:31 AM, Johan Fabry wrote: > > Hi Daniel, > > I have disclaimers as the 2 previous responses, this is my feeling about the > matter. :-) > > I would prefer to think purely in terms of the API that you want to use when > reading the file, and have that clear and explicit. So do NOT subclass Stream > nor do a class extension with #nextFoo. I would think in terms of the Stream > API when doing that, and reuse as many message names as possible, because it > is a fairly ‘standard’ API. So: option 1, without the use of > doesNotUnderstand. > >> On Jan 18, 2015, at 06:11, Daniel Lyons wrote: >> >> This is an OO design question. >> >> For my task, I have some objects and a particular file format that encodes >> them. I want to be able to read the file and create those objects. The >> Stream API seems like the right way to do this, but I'm not sure how to >> encapsulate my code. I see these options: >> >> • Create a new class (subclass of Object) that implements #next to return >> the next object in some underlying stream. >> >> Pro: very simple, one place with all the code. Con: what about the rest of >> the Stream and/or Collection APIs? Is it wise to delegate everything else to >> the underlying stream with #doesNotUnderstand:? >> >> • Create a new class, subclass of Stream, that implements #next like the >> above. >> >> Pro: still pretty simple, not sure what is needed to implement the API >> completely (I did add a method #atEnd). Con: not sure if more methods are >> missing; unclear about initialization (overrode class>>#on: to call >> #basicNew). This seems close to the right approach but I'm unsure. >> >> • Create a method #nextFoo on the existing Stream class. >> >> Pro: very simple—no new class. Con: nextFoo doesn't integrate well with the >> rest of the API (#do: for instance), not sure this is clean or wise. >> >> • Ignore the Stream classes altogether. >> >> Pro: No chance of misundestanding. :) Con: everything else. >> >> Advice? >> >> Thanks for your time, >> >> — >> Daniel Lyons >> >> >> >> >> > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > — Daniel Lyons
Re: [Pharo-users] Popular
Ben Coman writes: > 3) a book - Currently we have only half of this. We have a very good > book in PBE, but it is outdated several years. Early adopters and existing > Pharo users can work around this, but for potential incoming masses, an up > to date book is a critical aspect. There is current activity to update PBE > for Pharo 4 (and now I realise I should help with it more, Thanks for > clarifying my thinking on this.) I'm happy to offer my services as an editor, proof-reader and writer. It's a lot easier to get English text out of me than code. :) If anybody needs or wants me to fix their text, just point me to it. -- Daniel Lyons
[Pharo-users] Installing GlorpDBX on OS X Mavericks for Pharo 2.0.
In case someone else is trying to get this to work, here’s a recipe I found that worked for me. Scenario: you have PostgreSQL on your Mac via MacPorts and would like to install GlorpDBX with your Pharo 2.0. 1. Make sure you have a universal build of PostgreSQL. Pharo 2.0 is 32-bit, and MacPorts is probably going to fetch you a 64-bit build of Postgres. So do this: $ sudo port install postgresql93 +universal 2. Download opendbx 1.4.6 and use the following options to ./configure: $ ./configure CFLAGS="-I/opt/local/include -I/opt/local/include/postgresql93 -arch i386 -arch x86_64" CXXFLAGS="-I/opt/local/include -I/opt/local/include/postgresql93 -arch i386 -arch x86_64" LDFLAGS="-L/opt/local/lib -L/opt/local/lib/postgresql93 -arch i386 -arch x86_64" --disable-dependency-tracking --disable-utils --with-backends=pgsql Most of that is wiring up opendbx to the MacPorts-specific install areas for Postgres. The -arch flags cause it to build a universal library. --disable-dependency-tracking was mentioned on Stack Overflow here: http://stackoverflow.com/questions/3350107/how-to-compile-universal-libraries-on-mac-os-x --disable-utils stops the build from trying to make a command line utility that seems not to build with the readline on Mavericks. 3. Install it: $ sudo make install From here, creating a username/database sodbxtest showed the unit tests passing. Thanks, — Daniel Lyons
[Pharo-users] SQL queries without injection vulnerability (DBXTalk)
I'd like to run some ad-hoc queries against my database without opening up a security vulnerability. I don't see any direct way to use parameterized queries from DBXTalk. I'd expect to see something like #executeStatement:withArguments: but I don't. In fact, I don't even see odbx_escape in the image anywhere. What's the trick here? Surely GlorpDBX et. al. are not gluing together bits of SQL with bits of user-supplied text and running it unescaped. What am I missing? http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/Usage#Executing_statements Thanks for your time, — Daniel Lyons
Re: [Pharo-users] SQL queries without injection vulnerability (DBXTalk)
Joachim, On Jan 14, 2014, at 12:24 AM, jtuc...@objektfabrik.de wrote: > I cannot help with opendbx, but I can comment on the way Glorp generates SQL. > You typically write blocks of code that look like a normal Smalltalk block, > but they have limitations to what you can write in there. These blocks are > evaluated and get converted to SQL by some kind of Visitor. The SQL string is > then concatenated out of fragments. > > BUT: Glorp does not have an API to provide SQL fragments to include in a > query. So there is not an easy way to inject SQL into a Glorp genaretd query. > What you are asking for is not related to Glorp, but to the underlying DB > interface, DBXTalk in your case. Interesting. So, I guess I'm wondering, how does Glorp escape the strings? > If you want to provide the user with the ability to provide SQL clauses and > construct queries out of that, I guess you are on your own. > > So the question is: do your users write SQL fragments or are you thinking of > a tool to construct queries by example? Oh, I'm afraid I haven't been very clear. The "user" supplying the query is me, the programmer. You see, I love SQL and I love relational databases. I probably lost most of the list with that sentence. :) I'm porting this program from PHP. It's a US Census browser, if you're curious: http://census.7gf.org . Anyway, it's basically one table and a huge pile of indexes and some set queries. Each page there is just a different query or two. I got through the front page and the about page with Seaside and PostgresV3 and it works great, but now I need to handle a query with the state as a parameter. In PHP (and JDBC, and Python's DBAPI), I can say "SELECT * FROM places WHERE state = ? ORDER BY population DESC" and then supply an array with the state in it, which fills in the '?' in the query. On a project with a true object model and real behavior on the objects, this approach wouldn't scale up. But in this case, the program is just a nice frontend on a simple one-table database. Glorp is bound to be more effort than it's worth. I only brought it up thinking Glorp must be doing this kind of escaping. It sounds like you're saying it has some other mechanism though, in which there is some kind of visitor that does the escaping, and I won't be able to leverage that. > Do you provide objects to fill in some example data or do your users know the > tables? The right solution for you depends on what exactly you have in mind. > For our project we use Glorp and provide forms to enter string fragments or > number ranges or dates etc. Then we use these in Glorp's blocks. This way the > structure of the query is provided as Smalltalk-code and only user-provided > data for the right-side operand of comparisons is provided by the user. It is > extremely hard to misuse this because the query String will always be fixed > and so fragments that include SQL will always lead to SQL errors. I agree :) > I am still learning about all the powerful things Glorp can do to cunstruct > subqueries, outer joins, having clauses and stuff, but every time I find > something I am excited ;-). I have another project I am looking forward to learning Glorp for. Don't worry, I'm sure I'll need a lot of help to get that going! Thanks, — Daniel Lyons
Re: [Pharo-users] SQL queries without injection vulnerability (DBXTalk)
> Did you know there are specialized mailing lists for glorp and dbxtalk? You > can find them on forum.world.st. If you'd rather I ask there I will, but they did not look promising. The DBXTalk site also seems to be gone. — Daniel Lyons
Re: [Pharo-users] SQL queries without injection vulnerability (DBXTalk)
Joachim, On Jan 14, 2014, at 12:54 AM, Daniel Lyons wrote: >> Did you know there are specialized mailing lists for glorp and dbxtalk? You >> can find them on forum.world.st. > > If you'd rather I ask there I will, but they did not look promising. The > DBXTalk site also seems to be gone. This puts the emphasis on the wrong thing. I am genuinely not sure what to do. I'm not wedded to DBXTalk, it just seems to be the emphasized way to access a database now—if this isn't the right path, I'm here to be steered in the right direction. I like PostgresV3's connection pooling, but if it's "legacy" then I'd rather get in with what's going to be used. It looks like Mariano is maintaining PostgresV2, but V3 stalled out in 2010. So, it may be a stretch for here, but I am not sure "should I use your library or not" is going to be on-topic on those mailing lists. If there's a mailing list for PostgresV3, I didn't find it. Thanks again, — Daniel Lyons
Re: [Pharo-users] SQL queries without injection vulnerability (DBXTalk)
Esteban Lorenzano writes: > no its not :) > I’m just changing servers and old .com.ar domain is still not refreshed (and > you, accomplishing murphy’s law, just tried to hit the site now :). > you can find it at dbxtalk.smallworks.eu Thanks! This makes me feel much better. > anyway… no, we did not implemented sql injection defence. Is our > understanding that that is better done at pharo level, before calling any dbx > function. I'm sure that if I could replace ' with '' on the way out it would be sufficient. Forgive my ignorance, but what's the simplest way to do that? Database vendors tend to provide a function that does at least that, and OpenDBX provides access to that via their odbx_escape function, but round-tripping through FFI for each component of a string may have undesirable performance ramifications. -- Daniel Lyons
Re: [Pharo-users] SQL queries without injection vulnerability (DBXTalk)
Mariano Martinez Peck writes: > Regarding the SQL injection, yes, we didn't implement the one provided by > OpenDBX, but you can give it a try yourselfbut you would need to > recompile stuff. I may take a crack at it, but I'm not well-experienced with Smalltalk and certainly not knowledgeable about the FFI facility. If I come up with anything, I will write back. > Also, as mentioned by Joachim, if you use Glorp, you are not likely to > write the queries yourself..so at least that helps... but I don't know if > Glorp provides something extra for sql injection. You could ask in glorp > google group. Thanks for your help, -- Daniel Lyons
Re: [Pharo-users] Could Pharo be more idiot-proof?
PBK Research writes: > As a supplementary point, I am trying to use PetitParser to parse natural > language. From the examples it is clear that PP is designed with formal > languages in mind. Am I wasting my time using it on natural languages? Has > anyone else tried this? What are you trying to do with natural language? Do you have highly regular input and a somewhat restricted domain? I have used Prolog DCGs to mess around with this kind of thing, and if you have a lot of control over the input and your expectations you can make progress with a tool for formal languages, but if you want to do something sophisticated or support arbitrary inputs, you're probably wasting your time. -- Daniel Lyons
