From probert at os.ca Wed Jan 2 16:47:55 2008 From: probert at os.ca (Pascal Robert) Date: Wed Jan 2 16:48:04 2008 Subject: [OT] Not everything goes well in Ruby land :-) Message-ID: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> http://www.zedshaw.com/rants/rails_is_a_ghetto.html From dleber at codeferous.com Wed Jan 2 18:13:54 2008 From: dleber at codeferous.com (David LeBer) Date: Wed Jan 2 18:14:08 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> Message-ID: <7463E844-59F7-4DA4-8FCE-06CE627DCEA3@codeferous.com> On 2-Jan-08, at 7:47 PM, Pascal Robert wrote: > http://www.zedshaw.com/rants/rails_is_a_ghetto.html Wow, nasty. I'm not sure what or who that reflects worse on. ;david -- David LeBer Codeferous Software 'co-def-er-ous' adj. Literally 'code-bearing' site: http://codeferous.com blog: http://davidleber.net profile: http://www.linkedin.com/in/davidleber -- Toronto Area Cocoa / WebObjects developers group: http://tacow.org From jerrywwalker at gmail.com Thu Jan 3 05:49:24 2008 From: jerrywwalker at gmail.com (Jerry W. Walker) Date: Thu Jan 3 05:49:35 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> Message-ID: Hi, Pascal, WOW!!! That was hard to read. Zed Shaw would do well to learn that dropping the four letter words in his screed would make his prose more effective. Of course, it takes a good deal more thought to say something like "plagiarizing amateur coder" than "f**king a** h*le". (Sorry for the redaction, I just can't bring myself to write that way in public.). I've only ever seen one small instance in the WO community of the kind of name calling, back-stabbing nonsense both described and used in the article; and that instance was a misaddressed private email. Dare I say, I treasure the gems (i.e. people and products) in our WO community, even if they're not rubies. :-) Regards, Jerry On Jan 2, 2008, at 7:47 PM, Pascal Robert wrote: > http://www.zedshaw.com/rants/rails_is_a_ghetto.html -- __ Jerry W. Walker, WebObjects Developer/Instructor for High Performance Industrial Strength Internet Enabled Systems jerrywwalker@gee-em-aye-eye-ell.com 203 278-4085 office From webobjects_lists at webappz.com Sun Jan 6 22:47:56 2008 From: webobjects_lists at webappz.com (Gaastra Dennis - WO Lists) Date: Sun Jan 6 22:47:47 2008 Subject: WO5.4: Generics for objectsWithFetchSpecification ??? Message-ID: Dear List and Pierre, How do solve this without having to suppress generics warnings: array = editingContext.objectsWithFetchSpecification(spec); and array = instance.valueForKey("key"); where NSArray array; Or do we have to wait for 5.4.1? With Kind Regards, Dennis Gaastra, Chief Technology Officer, WEBAPPZ Systems, Inc. HQ: (+1) 604.921.1333 From ian.joyner at sportstec.com Sun Jan 6 22:52:38 2008 From: ian.joyner at sportstec.com (Ian Joyner) Date: Sun Jan 6 22:52:44 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> Message-ID: <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> Scary stuff. I thought the Zed Shaw must be a complete raving loony from this post, but then realized he wrote the Mongrel server. He seems quite calm and rational in this interview: http://www.infoq.com/interviews/ruby-zed-shaw with not one swear word. It makes you wonder what happened in the space of a month to make him so bitter (yeah well it's probably how anyone can turn working in this industry!) Is Rails really to be compared with the .com bomb? What of Nitro/og which doesn't seem to have had an update in 18 months? Ian On 04/01/2008, at 12:49 AM, Jerry W. Walker wrote: > Hi, Pascal, > > WOW!!! > > That was hard to read. Zed Shaw would do well to learn that dropping > the four letter words in his screed would make his prose more > effective. Of course, it takes a good deal more thought to say > something like "plagiarizing amateur coder" than "f**king a** h*le". > (Sorry for the redaction, I just can't bring myself to write that > way in public.). > > I've only ever seen one small instance in the WO community of the > kind of name calling, back-stabbing nonsense both described and used > in the article; and that instance was a misaddressed private email. > > Dare I say, I treasure the gems (i.e. people and products) in our WO > community, even if they're not rubies. :-) > > Regards, > Jerry > > On Jan 2, 2008, at 7:47 PM, Pascal Robert wrote: > >> http://www.zedshaw.com/rants/rails_is_a_ghetto.html > > > > > -- > __ Jerry W. Walker, > WebObjects Developer/Instructor for High Performance Industrial > Strength Internet Enabled Systems > > jerrywwalker@gee-em-aye-eye-ell.com > 203 278-4085 office > > > > _______________________________________________ > WebObjects-talk mailing list > WebObjects-talk@omnigroup.com > http://www.omnigroup.com/mailman/listinfo/webobjects-talk > From pierce at twinforces.com Mon Jan 7 09:46:42 2008 From: pierce at twinforces.com (Pierce T. Wetter III) Date: Mon Jan 7 09:46:47 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> Message-ID: On Jan 6, 2008, at 11:52 PM, Ian Joyner wrote: > Scary stuff. I thought the Zed Shaw must be a complete raving loony > from this post, but then realized he wrote the Mongrel server. He > seems quite calm and rational in this interview: > > http://www.infoq.com/interviews/ruby-zed-shaw > > with not one swear word. It makes you wonder what happened in the > space of a month to make him so bitter (yeah well it's probably how > anyone can turn working in this industry!) > > Is Rails really to be compared with the .com bomb? What of Nitro/og > which doesn't seem to have had an update in 18 months? I figured out Rails was crap when I was getting FrontBase to work with it, and we found that Rails has all sorts of bugs because it considers: 1.0 and "1.0" To be equivalent, because that's what MySQL does. In fact, using anything but MySQL with Rails seems to lead to a lot of friction. That isn't what makes it crap though, what made it crap was the attitude from the Rails guys. That said, what I think WebObjects could steal from Rails is the whole concept of less configuration for the default behavior. There's all this stuff that a production-quality WO program has to implement that should really come pre-done. It's not a lot of code to pull the primary key out of a URL, fetch the relevant object, and pass it to a page component for display, but everyone seems to be constantly reinventing that wheel. Pierce From mschrag at mdimension.com Mon Jan 7 10:42:14 2008 From: mschrag at mdimension.com (Mike Schrag) Date: Mon Jan 7 11:12:22 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> Message-ID: > To be equivalent, because that's what MySQL does. In fact, using > anything but MySQL with Rails seems to lead to a lot of friction. For what it's worth, I don't think Rails is crap, nor do I think that guy's post should be representative of an entire community. The guy wrote Mongrel, so he's certainly not dumb, but he's clearly pretty bitter and, to me, his post loses most of its credibility due to its tone. He basically comes off a bit like a crazy person who happens to make a couple decent points. Also, we use Rails with FrontBase on of our apps (though we had to had to patch the db "adaptor"). I don't recall if our patches were accepted back into the mainline or not, but it's been working pretty well for us so far. I don't know if we just haven't hit the problems you have or if we actually patched it such that the problems you're seeing don't happen. > That isn't what makes it crap though, what made it crap was the > attitude from the Rails guys. I get this vibe, too ... Same thing from the Hibernate guys. > That said, what I think WebObjects could steal from Rails is the > whole concept of less configuration for the default behavior. > There's all this stuff that a production-quality WO program has to > implement that should really come pre-done. It's not a lot of code > to pull the primary key out of a URL, fetch the relevant object, and > pass it to a page component for display, but everyone seems to be > constantly reinventing that wheel. ... coming to a Wonder framework near you very soon. We are using an "inspired-by-rails-routes/controllers" WO framework. Like you said, it's easy to do, but it's just not available by default. At least if you use Wonder that will be changing pretty soon. ms From arroz at guiamac.com Mon Jan 7 13:41:46 2008 From: arroz at guiamac.com (Miguel Arroz) Date: Mon Jan 7 13:41:54 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> Message-ID: Hi! > That said, what I think WebObjects could steal from Rails is the > whole concept of less configuration for the default behavior. > There's all this stuff that a production-quality WO program has to > implement that should really come pre-done. It's not a lot of code > to pull the primary key out of a URL, fetch the relevant object, > and pass it to a page component for display, but everyone seems to > be constantly reinventing that wheel. There's a lot of discussion about if it is dangerous, or not, to expose the PKs. I prefer to avoid that when possible, but to be honest, sometimes I end up doing stuff that is almost the same as exposing the PK (exposing an UNIQUE field that is there exactly to be exposed, for example). What do you think? What are the goods and the bads of exposing PKs in URLs? Yours Miguel Arroz Miguel Arroz http://www.terminalapp.net http://www.ipragma.com From mschrag at mdimension.com Mon Jan 7 13:52:43 2008 From: mschrag at mdimension.com (Mike Schrag) Date: Mon Jan 7 13:52:49 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> Message-ID: > What do you think? What are the goods and the bads of exposing PKs > in URLs? The only issue as far as I'm concerned is security. I don't care if anyone sees PK's, but exposing access to arbitrary EO's via a URL means that the onus of security is much more on the developer's shoulders. With normal component actions, there's at least some level of security built-in (that you are even able to access this action means that you were pre-authorized to get to it by way of some authentication process). Note, however, that this is really not all that different than security of DA's in general (or even direct access to any .wo that has intrinsic state). ms From chill at global-village.net Mon Jan 7 14:04:25 2008 From: chill at global-village.net (Chuck Hill) Date: Mon Jan 7 14:04:29 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> Message-ID: On Jan 7, 2008, at 1:52 PM, Mike Schrag wrote: >> What do you think? What are the goods and the bads of exposing >> PKs in URLs? > The only issue as far as I'm concerned is security. I don't care > if anyone sees PK's, but exposing access to arbitrary EO's via a > URL means that the onus of security is much more on the developer's > shoulders. True, but exposing a PK or some other unique value seems equally dangerous to me. I have heard people claim the evils of giving the PK meaning by using it in this manner. I see this as more of an academic than a practical concern. Not using the PK (e.g. using some other manufactured, unique value) would allow you to swap in other objects for the same value, but I have never seen where that was needed when there was not some other suitable unique value (e.g. a part number). > With normal component actions, there's at least some level of > security built-in (that you are even able to access this action > means that you were pre-authorized to get to it by way of some > authentication process). Note, however, that this is really not all > that different than security of DA's in general (or even direct > access to any .wo that has intrinsic state). Yes, you need to be extra vigilant when using these. Chuck -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects From andrus at objectstyle.org Mon Jan 7 13:57:20 2008 From: andrus at objectstyle.org (Andrus Adamchik) Date: Mon Jan 7 14:04:48 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> Message-ID: There's an endless discussion about that on Cayenne user list, and at the end everybody still uses PK's in URL's and DataObjectUtils.objectForPK(..) and DataObjectUtils.intPKForObject(..) are the two most popular methods in the framework :-) Good or bad, people prefer simplicity in most situations. A simple rule of thumb - if you don't care that a rogue user may hack a URL by trying various random or sequential ids, then use your PK and save time on building an extra abstraction. This may be true even if a page requires security... Andrus On Jan 7, 2008, at 11:41 PM, Miguel Arroz wrote: > Hi! > >> That said, what I think WebObjects could steal from Rails is the >> whole concept of less configuration for the default behavior. >> There's all this stuff that a production-quality WO program has to >> implement that should really come pre-done. It's not a lot of code >> to pull the primary key out of a URL, fetch the relevant object, >> and pass it to a page component for display, but everyone seems to >> be constantly reinventing that wheel. > > There's a lot of discussion about if it is dangerous, or not, to > expose the PKs. I prefer to avoid that when possible, but to be > honest, sometimes I end up doing stuff that is almost the same as > exposing the PK (exposing an UNIQUE field that is there exactly to > be exposed, for example). > > What do you think? What are the goods and the bads of exposing PKs > in URLs? > > Yours > > Miguel Arroz > > Miguel Arroz > http://www.terminalapp.net > http://www.ipragma.com From pierce at twinforces.com Mon Jan 7 14:10:22 2008 From: pierce at twinforces.com (Pierce T. Wetter III) Date: Mon Jan 7 14:10:27 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> Message-ID: <0A2AC436-A592-46AC-970E-9D3C8FC5C030@twinforces.com> > What do you think? What are the goods and the bads of exposing PKs > in URLs? It depends on what they look like. I always expose _encrypted_ primary keys in my URLs, so that people can't generalize: 10000001 10000002 10000003 etc. There's a method in Wonder that makes this easy. After that, since URLs are always in the browser history anyways, for things that have to be secure, I have a method that takes the encrypted primary key, a key path, and session.user and makes sure that if you follow the specified key path from the object pointed at by the encrypted primary key, that you reach session.user. Pierce From mschrag at mdimension.com Mon Jan 7 14:12:53 2008 From: mschrag at mdimension.com (Mike Schrag) Date: Mon Jan 7 14:12:55 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> Message-ID: <184763D1-C196-4F12-92E4-9C0528781DBD@mdimension.com> > True, but exposing a PK or some other unique value seems equally > dangerous to me. I have heard people claim the evils of giving the > PK meaning by using it in this manner. I see this as more of an > academic than a practical concern. Not using the PK (e.g. using > some other manufactured, unique value) would allow you to swap in > other objects for the same value, but I have never seen where that > was needed when there was not some other suitable unique value (e.g. > a part number). Certainly you could expose other candidate keys if you have them, but from my perspective, PK = Object ID, and RESTful URL's are _supposed_ to be invariant (blah blah), which makes PK a pretty obvious candidate for this role. Old me would have been offended by this, new me doesn't have time :) I think if it gets the job done and it isn't obviously catastrophic, so be it. ms From chill at global-village.net Mon Jan 7 14:24:09 2008 From: chill at global-village.net (Chuck Hill) Date: Mon Jan 7 14:24:13 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: <0A2AC436-A592-46AC-970E-9D3C8FC5C030@twinforces.com> References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> <0A2AC436-A592-46AC-970E-9D3C8FC5C030@twinforces.com> Message-ID: On Jan 7, 2008, at 2:10 PM, Pierce T. Wetter III wrote: > >> What do you think? What are the goods and the bads of exposing >> PKs in URLs? > > It depends on what they look like. > > I always expose _encrypted_ primary keys in my URLs, so that > people can't generalize: > > 10000001 > 10000002 > 10000003 > > etc. But why? I am not a big fan of security though obscurity. If there are security issues, you need to check the permission to view (as you note below). If there are no security issues (say items in a catalog), what does it matter? > There's a method in Wonder that makes this easy. > > After that, since URLs are always in the browser history anyways, > for things that have to be secure, I have a method that takes the > encrypted primary key, a key path, and session.user and makes sure > that if you follow the specified key path from the object pointed > at by the encrypted primary key, that you reach session.user. Chuck -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects From pierce at twinforces.com Mon Jan 7 14:41:03 2008 From: pierce at twinforces.com (Pierce T. Wetter III) Date: Mon Jan 7 14:41:08 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> <0A2AC436-A592-46AC-970E-9D3C8FC5C030@twinforces.com> Message-ID: <87A76AD2-234A-47F8-8EF5-B08024C56CDD@twinforces.com> >> I always expose _encrypted_ primary keys in my URLs, so that >> people can't generalize: >> >> 10000001 >> 10000002 >> 10000003 >> >> etc. > > > But why? I am not a big fan of security though obscurity. If there > are security issues, you need to check the permission to view (as > you note below). If there are no security issues (say items in a > catalog), what does it matter? > > >> There's a method in Wonder that makes this easy. >> >> After that, since URLs are always in the browser history anyways, >> for things that have to be secure, I have a method that takes the >> encrypted primary key, a key path, and session.user and makes sure >> that if you follow the specified key path from the object pointed >> at by the encrypted primary key, that you reach session.user. Because not everything can always be tied to a user, and encryption is not just obscurity. Another advantage of encryption is that its nice to get a failure if URLs have been truncated in the middle of the primary key. Something you might not get if both 1000 and 10001 are legitimate primary keys. Encryption functions actually make really good checksum/validation tools... Pierce From i_love_my at mac.com Mon Jan 7 15:00:54 2008 From: i_love_my at mac.com (Pierre Bernard) Date: Mon Jan 7 15:01:04 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> <0A2AC436-A592-46AC-970E-9D3C8FC5C030@twinforces.com> Message-ID: <3D068AE4-119B-4F0B-8A32-9824DD717854@mac.com> There is more to not exposing primary keys than security. If you expose any "developer private" information, users are going to start to rely on it. Consider it UI. Preventing you from making changes. I.e. Users could start bookmarking URLs with primary keys in them. I used to work on a project where the project manager gave the users read-only access to the database. They started making requests for changes to the data model, wanted views for the data model to behave like its ancestor ... They wrote M$ Access "applications" digging into the schema. Any future change on our side will require maintenance to these proliferating "applications" On two occasions, I ran into a gaping security hole in the "secure message" system of the web banking I use. The interface was so broken that it seemed easier to modify the URL than to navigate as designed. Wanting to go to my next message I +1ed the message ID in the URL. Guess what? I got to see another customer's messages. I spent 1 week explaining the bank that this was a security issue. In the end they agreed and fixed it. A year later I discovered they had it fixed for INBOX, not for the SENT mailbox. Best, Pierre Bernard Houdah Software s.? r.l. On 7 Jan 2008, at 23:24, Chuck Hill wrote: > > On Jan 7, 2008, at 2:10 PM, Pierce T. Wetter III wrote: > >> >>> What do you think? What are the goods and the bads of exposing PKs >>> in URLs? >> >> It depends on what they look like. >> >> I always expose _encrypted_ primary keys in my URLs, so that >> people can't generalize: >> >> 10000001 >> 10000002 >> 10000003 >> >> etc. > > > But why? I am not a big fan of security though obscurity. If there > are security issues, you need to check the permission to view (as > you note below). If there are no security issues (say items in a > catalog), what does it matter? > > >> There's a method in Wonder that makes this easy. >> >> After that, since URLs are always in the browser history anyways, >> for things that have to be secure, I have a method that takes the >> encrypted primary key, a key path, and session.user and makes sure >> that if you follow the specified key path from the object pointed >> at by the encrypted primary key, that you reach session.user. > > Chuck > > -- > > Practical WebObjects - for developers who want to increase their > overall knowledge of WebObjects or who are trying to solve specific > problems. > http://www.global-village.net/products/practical_webobjects > > > > > > _______________________________________________ > WebObjects-talk mailing list > WebObjects-talk@omnigroup.com > http://www.omnigroup.com/mailman/listinfo/webobjects-talk --- Pierre Bernard http://www.bernard-web.com/pierre http://www.houdah.com From mschrag at mdimension.com Mon Jan 7 15:13:32 2008 From: mschrag at mdimension.com (Mike Schrag) Date: Mon Jan 7 15:13:38 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: <3D068AE4-119B-4F0B-8A32-9824DD717854@mac.com> References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> <0A2AC436-A592-46AC-970E-9D3C8FC5C030@twinforces.com> <3D068AE4-119B-4F0B-8A32-9824DD717854@mac.com> Message-ID: <7D708B26-B1A2-46E3-A426-AE2F655EC19F@mdimension.com> > If you expose any "developer private" information, users are going > to start to rely on it. Consider it UI. Preventing you from making > changes. I.e. Users could start bookmarking URLs with primary keys > in them. But that's perfectly valid, right? RESTful folks would say that your URL's ARE API ... Especially if you start exposing ActiveResource- style RESTful XML services, those are going to have to have SOME sort of ID's in them. Like Chuck said, you could use some other candidate key, but if you have a sufficient non-OID candidate key that is going to be basically invariant and act in this capacity in your API, why not just make that your PK in WO in the first place? ms From andrus at objectstyle.org Mon Jan 7 15:26:48 2008 From: andrus at objectstyle.org (Andrus Adamchik) Date: Mon Jan 7 15:26:53 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: <7D708B26-B1A2-46E3-A426-AE2F655EC19F@mdimension.com> References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> <0A2AC436-A592-46AC-970E-9D3C8FC5C030@twinforces.com> <3D068AE4-119B-4F0B-8A32-9824DD717854@mac.com> <7D708B26-B1A2-46E3-A426-AE2F655EC19F@mdimension.com> Message-ID: <98C1240F-44A8-44C8-9543-8A0BCE3A72AB@objectstyle.org> In the enterprise world where the backend apps and databases are mutant creatures born from generations of uncoordinated and discontinuous programming efforts, I can see that exposing anything can become a liability rather quickly... So that's where that kind of thinking is coming from... For the rest of the world using PK's in URLs is a nice and helpful shortcut :-) Andrus On Jan 8, 2008, at 1:13 AM, Mike Schrag wrote: >> If you expose any "developer private" information, users are going >> to start to rely on it. Consider it UI. Preventing you from making >> changes. I.e. Users could start bookmarking URLs with primary keys >> in them. > But that's perfectly valid, right? RESTful folks would say that > your URL's ARE API ... Especially if you start exposing > ActiveResource-style RESTful XML services, those are going to have > to have SOME sort of ID's in them. Like Chuck said, you could use > some other candidate key, but if you have a sufficient non-OID > candidate key that is going to be basically invariant and act in > this capacity in your API, why not just make that your PK in WO in > the first place? > > ms From ari at ish.com.au Mon Jan 7 19:02:26 2008 From: ari at ish.com.au (Aristedes Maniatis) Date: Mon Jan 7 19:35:58 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: <7D708B26-B1A2-46E3-A426-AE2F655EC19F@mdimension.com> References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> <0A2AC436-A592-46AC-970E-9D3C8FC5C030@twinforces.com> <3D068AE4-119B-4F0B-8A32-9824DD717854@mac.com> <7D708B26-B1A2-46E3-A426-AE2F655EC19F@mdimension.com> Message-ID: <9E0E86FE-A41F-49C0-825C-FDD381D7F5B9@ish.com.au> On 08/01/2008, at 10:13 AM, Mike Schrag wrote: >> If you expose any "developer private" information, users are going >> to start to rely on it. Consider it UI. Preventing you from making >> changes. I.e. Users could start bookmarking URLs with primary keys >> in them. > But that's perfectly valid, right? RESTful folks would say that > your URL's ARE API ... Especially if you start exposing > ActiveResource-style RESTful XML services, those are going to have > to have SOME sort of ID's in them. Like Chuck said, you could use > some other candidate key, but if you have a sufficient non-OID > candidate key that is going to be basically invariant and act in > this capacity in your API, why not just make that your PK in WO in > the first place? Another reason is that customers (that is the company we write code for) will sometimes look at those exposed keys and start to ask for them to become meaningful. "Those invoice numbers are great", they'll say, "but if could you have all previous financial year invoices have a letter appended to the end that would be great." So sometimes, what starts out at an invariant PK, changes in nature as the project matures. Sure, invoice numbers are usually invariant, numerical and monotonically increasing. Until Jo from Accounts decides that they aren't. It can be easier to deal with this if the exposed field isn't scattered across as FKs in a whole bunch of related tables. Also, depending on the strategy for PK generation, sometimes they are not monotonically increasing. That is, the requirements of locking strategies, validation and database transactions means that PKs could be skipped in the sequence. That can sometimes be unacceptable for, say, invoice numbers. Cheers Ari --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From chill at global-village.net Mon Jan 7 19:51:34 2008 From: chill at global-village.net (Chuck Hill) Date: Mon Jan 7 19:51:34 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: <9E0E86FE-A41F-49C0-825C-FDD381D7F5B9@ish.com.au> References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> <0A2AC436-A592-46AC-970E-9D3C8FC5C030@twinforces.com> <3D068AE4-119B-4F0B-8A32-9824DD717854@mac.com> <7D708B26-B1A2-46E3-A426-AE2F655EC19F@mdimension.com> <9E0E86FE-A41F-49C0-825C-FDD381D7F5B9@ish.com.au> Message-ID: <491E5BFB-3ED2-4F61-9BEF-3922DF123769@global-village.net> On Jan 7, 2008, at 7:02 PM, Aristedes Maniatis wrote: > > On 08/01/2008, at 10:13 AM, Mike Schrag wrote: > >>> If you expose any "developer private" information, users are >>> going to start to rely on it. Consider it UI. Preventing you from >>> making changes. I.e. Users could start bookmarking URLs with >>> primary keys in them. >> But that's perfectly valid, right? RESTful folks would say that >> your URL's ARE API ... Especially if you start exposing >> ActiveResource-style RESTful XML services, those are going to have >> to have SOME sort of ID's in them. Like Chuck said, you could use >> some other candidate key, but if you have a sufficient non-OID >> candidate key that is going to be basically invariant and act in >> this capacity in your API, why not just make that your PK in WO in >> the first place? > > Another reason is that customers (that is the company we write code > for) will sometimes look at those exposed keys and start to ask for > them to become meaningful. "Those invoice numbers are great", > they'll say, "but if could you have all previous financial year > invoices have a letter appended to the end that would be great." > > So sometimes, what starts out at an invariant PK, changes in nature > as the project matures. Sure, invoice numbers are usually > invariant, numerical and monotonically increasing. Until Jo from > Accounts decides that they aren't. It can be easier to deal with > this if the exposed field isn't scattered across as FKs in a whole > bunch of related tables. I think the original point was if you did not have any alternative. Certainly, if I had an invoice number or a catalog number or part number or whatever, I would use that instead of the PK. But sometimes there just isn't anything else. > Also, depending on the strategy for PK generation, sometimes they > are not monotonically increasing. That is, the requirements of > locking strategies, validation and database transactions means that > PKs could be skipped in the sequence. That can sometimes be > unacceptable for, say, invoice numbers. Definitely, using generated unique identifiers for anything with human sensible meaning (e.g. invoice numbers) is a bad idea. The skipped values almost always causes business problems. Chuck -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects From chill at global-village.net Mon Jan 7 20:24:51 2008 From: chill at global-village.net (Chuck Hill) Date: Mon Jan 7 20:24:51 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: <7D708B26-B1A2-46E3-A426-AE2F655EC19F@mdimension.com> References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> <0A2AC436-A592-46AC-970E-9D3C8FC5C030@twinforces.com> <3D068AE4-119B-4F0B-8A32-9824DD717854@mac.com> <7D708B26-B1A2-46E3-A426-AE2F655EC19F@mdimension.com> Message-ID: On Jan 7, 2008, at 3:13 PM, Mike Schrag wrote: >> If you expose any "developer private" information, users are going >> to start to rely on it. Consider it UI. Preventing you from making >> changes. I.e. Users could start bookmarking URLs with primary keys >> in them. > But that's perfectly valid, right? RESTful folks would say that > your URL's ARE API ... Excluding component action URLs, I would agree that they are API. And if I use a PK in a URL and that PK becomes no longer valid, the URL _should_ stop working. If that is not the correct behavior, then the PK is the wrong thing to use in the URL. > Especially if you start exposing ActiveResource-style RESTful XML > services, those are going to have to have SOME sort of ID's in > them. Like Chuck said, you could use some other candidate key, but > if you have a sufficient non-OID candidate key that is going to be > basically invariant and act in this capacity in your API, why not > just make that your PK in WO in the first place? I lean more towards always making a meaningless PK. Candidate keys have a bad habit of needing changes over the years. But if I had a candidate key, I would prefer to that in my URL. Chuck -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects From mlaster at gmail.com Mon Jan 14 08:50:25 2008 From: mlaster at gmail.com (Mike Laster) Date: Mon Jan 14 08:50:28 2008 Subject: [OT] Not everything goes well in Ruby land :-) In-Reply-To: References: <79306A65-9120-4DC7-9420-F1545AFDC2CF@os.ca> <1E820468-34CF-4745-AB5A-C2A608B25933@sportstec.com> Message-ID: <28256e610801140850j1f1834eakca96c43e1eeae9ca@mail.gmail.com> On Jan 7, 2008 10:42 AM, Mike Schrag wrote: > Also, we use Rails with FrontBase on of our apps (though we had to had > to patch the db "adaptor"). I don't recall if our patches were > accepted back into the mainline or not, but it's been working pretty > well for us so far. I don't know if we just haven't hit the problems > you have or if we actually patched it such that the problems you're > seeing don't happen. Wow, I'm impressed that someone is actually using it! I wrote the FB adapter and then never actually used it myself since I left the company that was using FrontBase before I could really dig into it. I had a hell of a time getting it accepted into the Rails code base. From bon_d at mac.com Tue Jan 15 12:18:31 2008 From: bon_d at mac.com (David BON) Date: Tue Jan 15 12:18:38 2008 Subject: Comments on the Confluence doc? Message-ID: <08D0F7EF-E8CF-4FA0-95DF-955149CF8B0B@mac.com> Just my 2 cts about the docs on the Confluence web site: Would it be possible to add a feature on the Confluence web site to allow readers (could be restricted to members) to add comments each page. Therefore we (I mean mainly newbies) could directly ask questions for further explanation on particular points of the related topic? David B. From programmingosx at mac.com Tue Jan 15 12:24:18 2008 From: programmingosx at mac.com (David Holt) Date: Tue Jan 15 12:25:44 2008 Subject: Comments on the Confluence doc? In-Reply-To: <08D0F7EF-E8CF-4FA0-95DF-955149CF8B0B@mac.com> References: <08D0F7EF-E8CF-4FA0-95DF-955149CF8B0B@mac.com> Message-ID: Hi David, At the bottom of every page I am seeing a place to add comments. I am a member and logged in at the time, so you may have to sign up and in to get it, but the function is certainly already being used. Thanks, David -------------- next part -------------- On 15-Jan-08, at 12:18 PM, David BON wrote: > Just my 2 cts about the docs on the Confluence web site: > > Would it be possible to add a feature on the Confluence web site to > allow readers (could be restricted to members) to add comments > each page. Therefore we (I mean mainly newbies) could directly ask > questions for further explanation on particular points of the > related topic? > > David B. > _______________________________________________ > WebObjects-talk mailing list > WebObjects-talk@omnigroup.com > http://www.omnigroup.com/mailman/listinfo/webobjects-talk From bon_d at mac.com Tue Jan 15 12:40:08 2008 From: bon_d at mac.com (David BON) Date: Tue Jan 15 12:40:49 2008 Subject: Comments on the Confluence doc? In-Reply-To: References: <08D0F7EF-E8CF-4FA0-95DF-955149CF8B0B@mac.com> Message-ID: Thanks David, I always read those pages without login in before and never notice that before! Does not seem to be lot of activity yet... I'm open my first comment on the home page of the WOCOM part of the site on this subject. Cheers, David B. Le 15 janv. 08 ? 20:24, David Holt a ?crit : > Hi David, > > At the bottom of every page I am seeing a place to add comments. I > am a member and logged in at the time, so you may have to sign up > and in to get it, but the function is certainly already being used. > Thanks, > > David > > > > On 15-Jan-08, at 12:18 PM, David BON wrote: > >> Just my 2 cts about the docs on the Confluence web site: >> >> Would it be possible to add a feature on the Confluence web site >> to allow readers (could be restricted to members) to add comments >> each page. Therefore we (I mean mainly newbies) could directly ask >> questions for further explanation on particular points of the >> related topic? >> >> David B. >> _______________________________________________ >> WebObjects-talk mailing list >> WebObjects-talk@omnigroup.com >> http://www.omnigroup.com/mailman/listinfo/webobjects-talk >