re: No integration

Post #156,467 by tablizer 5/23/04 12:47:13 AM Reply	re: No integration Java Beans, mapped to fields. Automatic, and it doesn't care where the data comes from, or where it's going, like bound fields do. And that doesn't cover web applications. Somehow database columns have to be associated with screen widgets. Applications and frameworks cannot read minds. For one, it is often not a one-to-one correspondence so that we cannot just take a schema as-is and splash it on a screen. Perhaps such can serve as the starting point, but not the final. So with a web application, you will have a reverse mapping step given your example. Yes or no? Ideally there is a data-dictionary-like UI item table that has optional column names. When the screen is drawn, it uses those column names to populate the widget. And when it is time to save, the same column names are used to build the saving SQL (unless designated read-only). ________________ oop.ismad.com
Post #156,487 by admin 5/23/04 9:32:39 AM Reply	re: No integration Somehow database columns have to be associated with screen widgets. Applications and frameworks cannot read minds. For one, it is often not a one-to-one correspondence so that we cannot just take a schema as-is and splash it on a screen. Perhaps such can serve as the starting point, but not the final. Correct. Ideally there is a data-dictionary-like UI item table that has optional column names. When the screen is drawn, it uses those column names to populate the widget. And when it is time to save, the same column names are used to build the saving SQL (unless designated read-only). So this includes data caching, query caching, and so on like Hibernate does? You'll have to write it and show it to convince me that it isn't more bloated than the example I've already given. Where's the bloat with O-R mapping? You haven't shown that, and therefore your claim is still bogus. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,503 by tablizer 5/23/04 2:15:24 PM Reply	So you want to see an Iwethey clone? ________________ oop.ismad.com
Post #156,507 by admin 5/23/04 3:35:37 PM Reply	I'd prefer you answer the points first. But suits me. The new version, of course, not this one. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,513 by tablizer 5/23/04 5:21:55 PM 5/23/04 5:24:01 PM Reply	We need code, not brochure-talk, to settle this I will not match iwethey feature-for-feature because nobody is ever going to use it, since there is already one. But, I could create the basic functionality and then add specific features that you want to explore. ________________ oop.ismad.com Edited by tablizer May 23, 2004, 05:24:01 PM EDT Expand All History
Post #156,520 by admin 5/23/04 6:21:31 PM 5/23/04 6:37:27 PM Reply	Re: We need code, not brochure-talk, to settle this The user create/login/edit functionality of the new site I linked should be sufficient. I'll refresh the version that's on the site. Features it has: User caching and on-demand loading of user preferences Session variables linked by a cookie session ID Anonymous users Login required can be turned on declaratively by screen Remote database (ie. no filesystem databases - this isn't a desktop app) Internationalized message stores for field labels and errors Full unit and regression testing Since this is a practical example, use whatever toolkits you wish, and no whining thereof. I'm not interested in pie-in-the-sky "well, it COULD be like this" crap. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..." Edited by admin May 23, 2004, 06:37:27 PM EDT Expand All History
Post #156,540 by tablizer 5/23/04 11:49:04 PM Reply	Is that part of iwethey? ________________ oop.ismad.com
Post #156,543 by admin 5/24/04 12:30:00 AM Reply	Yes. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,548 by tablizer 5/24/04 1:19:04 AM 5/24/04 12:41:13 PM Reply	questions and comments Off the top of my head, here is how I might approach some of these, in case anyone is interested. I also have some questions. User caching and on-demand loading of user preferences I am not quite sure what you mean by this. I would possibly use the dictionary-array approach I described a day or so ago. Session variables linked by a cookie session ID PHP has built-in session handling (although they keep changing it). Login required can be turned on declaratively by screen Not sure what you mean by this. Do you mean the administrator has a switch? Internationalized message stores for field labels and errors I would probably create some tables something like this: Table: Messages --------------- msgID // could be number or pneumonic EnglishMsg Table: Languages ---------------- langID langDescript // example: Spanish, French, etc. Table: LanguageMessages ----------------------- msgRef langRef msg I probably would not include internationalization in my actual example because implementing the above is pretty obvious. More info on speed issues and others at: [link\|http://www.c2.com/cgi/wiki?InternationalUiExample\|http://www.c2.com/cg...nationalUiExample] Note pseudo-code example at the very bottom. Full unit and regression testing Fluck that. This is a toy example. Since this is a practical example, use whatever toolkits you wish May put me at a disadvantage since there are not a lot of existing TOP toolkits out there. Self-fulfilling prophecy trick again, eh? You sneaky devil. ________________ oop.ismad.com Edited by tablizer May 24, 2004, 02:01:55 AM EDT Edited by tablizer May 24, 2004, 12:41:13 PM EDT Expand All History
Post #156,556 by ben_tilly 5/24/04 2:50:12 AM Reply	Reading comprehension? From [link\|http://z.iwethey.org/forums/render/content/show?contentid=156520\|http://z.iwethey.org...?contentid=156520] (what you are replying to): Since this is a practical example, use whatever toolkits you wish, and no whining thereof. I'm not interested in* pie-in-the-sky "well, it COULD be like this" crap* What Scott said that he didn't want is a pretty good description of what you actually provided. Don't say, "Well you could do this." Either do it or shut up. Regards, Ben To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act - [link\|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20\|Nebraska Supreme Court]
Post #156,629 by tablizer 5/24/04 12:39:54 PM Reply	What is your complaint? I provided descriptions as a bonus. If you don't want to read them, then simply ignore them. If Scott does not want to hear "it could be like this....", then he can just plain simply bypass it. The Web is big. Ignore what you don't want. ________________ oop.ismad.com
Post #156,759 by ben_tilly 5/24/04 8:38:02 PM Reply	Why not eliminate everything that is only a bonus? Oops, not much is left, huh? While Scott's attempts to enlighten you sometimes are informative for the rest of us, the conversation long ago reached the point where you really need to put up or shut up. Considering that nobody has demonstrable work experience with the way that you think should work better, while many of us have experience with existing alternatives, the burden of proof is on you to show that it is possible. Not us. In case you didn't notice, our experience tells us that the approach that you're suggesting will not scale development-wise. Perhaps we just misunderstand what you're suggesting. Perhaps we really do understand what you're suggesting, and our intuition is wrong. So why not build your own version of part of IWETHEY? I think that it really would be informative to see how you would tackle it. But until you do that, watching your hands flap in the breeze is rather pointless on all sides. Cheers, Ben To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act - [link\|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20\|Nebraska Supreme Court]
Post #156,578 by admin 5/24/04 8:24:10 AM 5/24/04 8:27:08 AM Reply	Then don't bother. User caching: the user information is cached locally, in RAM, for performance reasons. User properties (preferences) aren't loaded unless they're needed. Declarative login checking: if I want to require a user to be logged in to reach a particular screen, I put: <ref bean="loginInterceptor"/> in that section of the config file, and the login is checked and redirected if necessary. Unit testing: Toy examples don't prove anything. If you aren't going to write unit tests then you're not showing anything, because one of the hallmarks of ease of maintenance is testability. It would be real easy to glop together a bunch of crap in a single messy, unmaintainable file and declare "victory". Toolkits: Again, if it's not something you can do today, what's the point? I work with today's tools. I get things done. You're telling me that my code is bloated compared to what you can do. Well, prove it or concede that it isn't. PHP is used by an awful lot of people and there is a large body of work out there providing libraries of useful things. And if what you need is so all-fired useful, write it yourself so you have it to use in the future, for crying out loud. Should be easy, right, since it's "TOP"? Unsurprising, Bryce. When it comes down to it all you have is excuses. Do you go to your employers and say, "well, I could code it like this if I had the ÜberMegaTOP Toolkit, but we don't, so I'll have to do a crappy job"...? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..." Edited by admin May 24, 2004, 08:27:08 AM EDT Expand All History
Post #156,638 by tablizer 5/24/04 1:23:24 PM Reply	Fine. It is not "bloated". Just unknown. User caching: the user information is cached locally, in RAM, for performance reasons. User properties (preferences) aren't loaded unless they're needed. You are micro-managing how to design such an app. Putting the user preferences into a map array may take up far less space and time than your caching manager because cached info takes up space whether you use it later or not. Declarative login checking: if I want to require a user to be logged in to reach a particular screen, I put: <ref bean="loginInterceptor"/> in that section of the config file, and the login is checked and redirected if necessary. So, one could put a "loginOnly()" function at the start of any checked section/page. By not putting it in XML I also have smaller granularity options on where it is used. For example, maybe certain buttons don't show or have a different description if not logged in. Toolkits: Again, if it's not something you can do today, what's the point? I work with today's tools. I get things done. So do I. I have written an e-bay clone (more or less) in less than 7 weeks during the dot-com mayham. When it comes down to it all you have is excuses. You were the one who has been claiming OO is objectively better and then expect me to rewrite a whole Iwethey from scratch? I withdrawl the "bloated" claim for now. Feel better? However, that still does not make OO less bloated than p/r, only unknown. BTW, you guys never countered my running-code toy example at: [link\|http://www.geocities.com/tablizer/chal06.htm\|http://www.geocities...blizer/chal06.htm] I was first with the coded challenge, and now you are trying to trump it with your own. If OO cannot do that better, I would like to know why. If it's because it is a toy example instead of a real one, then describe how it differs from a real one that prevents OO's benefits from showing up. "well, I could code it like this if I had the \ufffdberMegaTOP Toolkit, but we don't, so I'll have to do a crappy job"...? Sure, if they pay me, I will work with lame tools. It may slow me down compared to a good TOP system, but that is life. Same reason we live with Microsoft. I tend to think that favorite paradigms and tools are subjective. Studies by Ed Yourdon seem to suggest that using tools that one is comfortable with is more important for productivity and quality than selecting tools based on what is popular. Show me slam-dunk evidence that OO is better, and I will look into it more. Most reasons given for OO are fuzzy-zenny, and make tradeoffs that the claimers are not aware of or conveniently ignore. For example grouping by noun helps noun-oriented changes, but un-helps task-oriented changes. Plus, the reasons everybody gives why OO is better differ. Some say polymorphism off of "subtypes" or variations is the main power of OO. Others who use more delegation disagree. Nobody has been able to clearly "encapsulate" the benefits of OO. All I get is, "it is j..j..j..just b..b..b..better, and if you were smart like me, you would see it." ________________ oop.ismad.com
Post #156,651 by admin 5/24/04 2:48:18 PM 5/24/04 3:12:45 PM Reply	That's all I needed. You were the one who has been claiming OO is objectively better and then expect me to rewrite a whole Iwethey from scratch? I withdrawl the "bloated" claim for now. Feel better? However, that still does not make OO less bloated than p/r, only unknown. It seems to me the claim under discussion in this thread was "O-R mappers bloat your code". Now that you've admitted that they don't, we can put it to rest. Although I'll note that old habits apparently die hard. You're still weaseling. Either the code is bloated compared to how you would do it, or it isn't. If you're not willing to provide an example, the conclusion to be drawn is "Bryce can't provide an example", not "the status is unknown." You say it's bloated, prove it. Otherwise it isn't. So do I. I have written an e-bay clone (more or less) in less than 7 weeks during the dot-com mayham. Then stop whining about toolkits. You must have used something to do that. BTW, you guys never countered my running-code toy example at: [...] I was first with the coded challenge, and now you are trying to trump it with your own. If OO cannot do that better, I would like to know why. If it's because it is a toy example instead of a real one, then describe how it differs from a real one that prevents OO's benefits from showing up. 1) I'm not in the habit of reading your website in the off-chance that you've provided something for me to do and 2) I'm not interested in toys, which you admit it is. Here's an example that does a real-life thing. If you think you can do better, then have at it. Otherwise shaddap. [edit: removed the broken "challenge" link] Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..." Edited by admin May 24, 2004, 03:12:45 PM EDT Expand All History
Post #156,657 by ChrisR 5/24/04 2:59:25 PM Reply	Probably not telling you anything you don't already know... ...but that example was originally started by Jim Weirich on Freep's OOP board. JohnU also got involved. Of course, since EZBoard decided to shut down the inactive boards, we don't have any extant to refer to. The reason I like the EZBoard example is (a) it's working (or soon to be working) code - the code can be objectively tested for performance and features; (b) it's something that we share in common and can immediately reap the benefits of any new ideas. So, yes, let's dispense with code fragments and toy code.
Post #156,658 by admin 5/24/04 3:02:11 PM Reply	I take it you mean... ... "IWETHEY example", and not "EZBoard example"? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,659 by ChrisR 5/24/04 3:09:53 PM Reply	Yep = That's what I meant The reporting example was fine, it's just that there was no measurable way to run the code and verify for correctness and performance.
Post #156,695 by JimWeirich 5/24/04 4:55:09 PM Reply	Re: Probably not telling you anything you don't already know ...but that example was originally started by Jim Weirich on Freep's OOP board Actually, the problem was introduced by someone else (JohnU perhaps?). Bryce actually wrote some (non-working) psuedo-code for it. All I did was translate Bryce's non-working psuedo-code into working Ruby code. Then I refactored to a better written procedural version and finally made it more flexible by introducing some polymorphism. I always thought the problem description was a little screwy (I never really understood the need for some the the requirements), but at least we had some form of code from Bryce to compare to. And the OO code compared very favorably with the procedural version (e.g. comparable code sizes (no bloat), polymorphism without taxinomy). At least, that's how I remember it. -- -- Jim Weirich jim@weirichhouse.org [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #156,700 by ChrisR 5/24/04 5:12:43 PM Reply	My memory is too taxed Not sure why I thought you initiated the sample. But your recollection does sound about right. Sure wish we hadn't lost the EZBoard archives. For that matter, I wish Freep would come visit every once in a while.
Post #156,704 by tablizer 5/24/04 5:16:58 PM Reply	Memory Lane I always thought the problem description was a little screwy (I never really understood the need for some the the requirements) We kind of never agreed on the scope. And the OO code compared very favorably with the procedural version (e.g. comparable code sizes (no bloat), polymorphism without taxinomy). If I remember correctly, you implemented a different set of features than mine, so that we really couldn't compare code-to-code for many parts, but rather focused on the architecture issues. ________________ oop.ismad.com
Post #156,686 by tablizer 5/24/04 4:40:18 PM Reply	re: That's all I needed. It seems to me the claim under discussion in this thread was "O-R mappers bloat your code". Now that you've admitted that they don't, we can put it to rest. I didn't say that they don't. I just don't have any comparative evidence to offer youses right now. I am curious though about what percent of self-declared OO proponents prefer O-R mappers. Many have lots of complaints. "Bryce can't provide an example", not "the status is unknown." You say it's bloated, prove it. Otherwise it isn't. False dichotomy. The answer to "is A > B" is Null at this point. Otherwise shaddap. Okay. After addressing some ongoing subissues, I will shut up about O-R mappers until new evidence arises. ________________ oop.ismad.com
Post #156,690 by admin 5/24/04 4:46:37 PM Reply	re: That's all I needed. Given that the evidence so far has either been conceded or unanswered by you, I'd say "isn't" is a lot closer to the current state of affairs than "null". Of course, you will never admit that, so I'll take a "shaddap". I have no doubt that you'll sit on this for a while and then trot out, "youses never proved it wasn't bloated!" at some point in the future, so I'm calling pre-foul now so it doesn't happen. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,652 by admin 5/24/04 2:48:25 PM Reply	Caching You are micro-managing how to design such an app. Putting the user preferences into a map array may take up far less space and time than your caching manager because cached info takes up space whether you use it later or not. The caching manager is generic. I don't need special one-off caching code all over the place. And it seems to me that you've always been the "machines are fast, programmers aren't, optimize for the programmer" champion. Why the sudden reversal? Regardless, I listed it as a feature. If you believe you have a better way of doing it, then do it that way. I'll warn you, though, that the caching speeds the app up considerably over loading it from the database for every request. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,654 by admin 5/24/04 2:48:31 PM Reply	Login checks and declarative processing So, one could put a "loginOnly()" function at the start of any checked section/page. By not putting it in XML I also have smaller granularity options on where it is used. For example, maybe certain buttons don't show or have a different description if not logged in. Which is what my code does in addition to the generic declarative checks. So your method is not as functional. If I want to have the entire application protected, that's one change in the config file. Or perhaps every page that has the word "secure" in the URI. Less work on average. But I don't care how you do it, I'm just telling you what needs to be done. Some pages are protected, others aren't. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,682 by tablizer 5/24/04 4:30:30 PM Reply	re: Login checks and declarative processing If I want to have the entire application protected, that's one change in the config file. In most web apps I have a standard "include" file. If I want the check applied to all pages, I simply put it there. Or perhaps every page that has the word "secure" in the URI. \n // standard header file\n ....\n if (contains(selfURI, 'secure')) {\n performCheckFoo(...)\n }\n ________________ oop.ismad.com
Post #156,687 by admin 5/24/04 4:40:47 PM Reply	re: Login checks and declarative processing And if you decide to move that include file? Or rename it? Don't say it doesn't happen, because it does. What if a developer forgets to include the check file in his page? What if two different clients share the same code, but run it locally and want to configure it differently? Your solutions always "work" for suitably limited scopes. I'll take the solution that's more globally applicable, thank you. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,699 by tablizer 5/24/04 5:11:26 PM Reply	re re: Login checks and declarative processing And if you decide to move that include file? Or rename it? Don't say it doesn't happen, because it does. What if a developer forgets to include the check file in his page? Then most pages will probably not work because a lot of stuff tends to depend on it for things like database handles. What if two different clients share the same code, but run it locally and want to configure it differently? A "split or share" decision is part of any such endevour. Computers can't read minds. If the criteria for triggering a given check changes, we simply change the criteria. Boolean expressions are usually more powerful than subclassing because we don't have to try to cram it into a tree shape and can more easily have orthogonal factors involved. Subclassing tends to puke and squirm when dealing with orthogonal factors. ________________ oop.ismad.com
Post #156,713 by admin 5/24/04 6:01:48 PM Reply	Re: Login checks and declarative processing (new thread) Created as new thread #156712 titled [link\|/forums/render/content/show?contentid=156712\|Re: Login checks and declarative processing] Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,630 by admin 5/24/04 12:50:01 PM Reply	I18N All that link to the Internation UI Example showed was your inability to grasp the issues. "Bottom" is right... using a database over text files gives you no benefits, and results in a loss of efficiency. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,641 by tablizer 5/24/04 1:48:02 PM 5/24/04 2:15:41 PM Reply	You are WRONG! All that link to the Internation UI Example showed was your inability to grasp the issues. Name calling? I don't appreciate that in the slight. I take big offense to that. Fuck you! If you have slam-dunk evidence then show it shove it! "Bottom" is right... using a database over text files gives you no benefits, and results in a loss of efficiency. If one has the option of using tables to generate "resource files" or whatever you want to call them, then the compiler does NOT CARE where they came from. It is not going to say, "Oh, these resource files were auto-generated from DB tables; therefore, I will run them slower". That is outright silly! That is a PHB-style mental error. I personally don't want to manage boatloads of messages as programming language files. Databases were created to help people track and manage boatloads of attributes, and that is just what international message info is. You are not going to tell me how to best manage information that I have to work with. Sure, a boss can dictate to me how to organize such info, and can even dictate to me how to organize my desk and pencils and paperclips. But, that does not necessarily make me more productive. Having them in tables allows one to sort by language, sort by message (ID), search for similar messages, print reports that non-programmers understand, etc. The presentation becomes untied to a programming language grouping or file organization. Sure, if it is a small application and there are only a few target languages, then editing within code files directly is fine. The bottom line is that code makes a shitty database. ________________ oop.ismad.com Edited by tablizer May 24, 2004, 02:15:41 PM EDT Expand All History
Post #156,648 by admin 5/24/04 2:31:42 PM Reply	My my, I touched a raw nerve, apparently. Where's the name I called you? From the link: Top: I am trying to think fairly large-scale here. What if "last" is used to mean both "previous" and "final" in different circumstances in the application? Bottom: The word "last" can be used in many different circumstances in the application. Top: A simple content look-up will not work. Bottom: It will and it does. The word "last" isn't looked up by itself. The phrases "Enter last name:" and "Your glory shall last" each have their own separate translation. It doesn't matter that the same word appears in each English version. It's pretty plain to me that you don't understand the issues here. Hence your confusion in the conversation you linked. How is this name calling? I personally don't want to manage boatloads of messages as programming language files. Neither do I. That's why I use resource files. You are not going to tell me how to best manage information that I have to work with. And you have done how many internationalized sites? I thought so. Yet you still feel qualified to tell everyone that your approach is so much better, even though it just solves problems that don't exist. "Bottom" is right. People don't need the sorts of "reports" you're talking about. Having them in tables allows one to sort by language, Er, and this can't be done with resource files for what reason? sort by message (ID), Why would anyone want to do this? You don't understand the problem set. search for similar messages, grep is your friend. print reports that non-programmers understand, etc. What kind of reports? This stuff simply isn't needed, and your over-engineered "solution" is more work for no gain. code makes a shitty database And databases make shitty code. Now change your tone or this conversation is over. I've been perfectly civil to you and I don't appreciate your response. You're acting like a sore loser. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,679 by tablizer 5/24/04 4:24:23 PM Reply	Grep is no substitute for clean, normalized data It's pretty plain to me that you don't understand the issues here. The context of that has appearently been deleted. Some were proposing translations using phrase look-ups. Even the links given did not use direct phrase lookups. How is this name calling? You accused me of "inabability to grasp the issues" without giving specifics. Even if true, the diplomatic way to say it is, "I beleive you are incorrect with regard to point X" rather than some sweeping generalization. Your people skills are even worse than mine, and that is saying something. I've been perfectly civil Bull. See above. Even if you think somebody is a total retard, it is improper to inform them of such judgement. One should point out specific things to complain about, not sweeping or vague generalizations. If you know of a specific use-case that busts my proposed solution, you are by all means welcomed to produce it. grep is your friend. That is a hacky approach. Tables are safer. Neither do I. That's why I use resource files. Hardly better than source code files. Why would anyone want to do this? You don't understand the problem set. That is nature of the biz world: you cannot predict ahead of time how somebody is going to want to see/query something. And databases make shitty code. Translation lookup tables are not "code". Even the VB resource file example calls them "tables". ________________ oop.ismad.com
Post #156,685 by admin 5/24/04 4:35:47 PM Reply	Re: Grep is no substitute for clean, normalized data That is a hacky approach. Tables are safer. That is a general statement. Provide specifics. Hardly better than source code files. In what way? They're a specific solution for a limited problem. some.string=The specific string for a message. How is the above "hardly better than source code"? I'll go you one better, in fact: how do you maintain database information over revisions? Keeping this in the database isn't sufficient when you have several database environments (Dev, Test, QA, Prod for example). Text resource files are amenable to revision control via common source code control tools. Translation lookup tables are not "code". And neither are resource files. That is nature of the biz world: you cannot predict ahead of time how somebody is going to want to see/query something. Especially if you've never done an internationalized application, which I'm guessing (by your non-response) that you haven't. Those who have understand that this simply isn't a requirement. You're inventing problems in order to provide your "solution". And since your solution adds extra complexity in the form of database access (or code generation) for no material gain, it is inferior. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,696 by tablizer 5/24/04 5:00:31 PM Reply	Depends on the scale {That is a hacky approach. Tables are safer.} That is a general statement. Provide specifics. You generally don't have to parse to isolate the "atoms". Unless you always provide a perfect parsing specification, there is a chance of getting it wrong. The "walls" are predefined for us so that we don't have to find them over and over. I'll go you one better, in fact: how do you maintain database information over revisions? Keeping this in the database isn't sufficient when you have several database environments (Dev, Test, QA, Prod for example). Text resource files are amenable to revision control via common source code control tools. I will agree that the existing crop of revision control tools are designed for files and not databases (although I have not done a survey yet). However, tables make it easier to roll-your-own. Plus, one can have more control over individual messages. See below. I am just too damned far ahead of my time :-) Especially if you've never done an internationalized application, which I'm guessing (by your non-response) that you haven't. Those who have understand that this simply isn't a requirement. You're inventing problems in order to provide your "solution". And since your solution adds extra complexity in the form of database access (or code generation) for no material gain, it is inferior. No, I have not done formal internationalization. But, how large was the project(s) you did? A tablized solution probably would not be practical unless you have say 20+ languages and 1000+ messages (per lang). Files are fine for smaller stuff. I never disputed that here. I am pretty sure there is a size-point in which you agree that files won't cut it anymore. For example, suppose most of the translators work offshore (which is expected for language translation). One may want a web-site where they log into and review and change messages. Doing that at a file granularity is a bit messy. Through such a portal we can fairly easily track which messages were changed by who and when. That can be done with files, but it takes a lot of Diff commands. You also make it sound as if tables are hard to use and bulky for internal stuff. Somebody used to XBase stuff will generally disagree. ________________ oop.ismad.com
Post #156,703 by FuManChu 5/24/04 5:15:10 PM Reply	You've never used CVS either, have you?
Post #156,711 by tablizer 5/24/04 5:50:18 PM Reply	No, only MS sourcesafe ________________ oop.ismad.com
Post #156,714 by admin 5/24/04 6:02:42 PM Reply	shudder I used Source"Safe" once. Just once. It ate the repository. What a piece of cack that program is. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,809 by tablizer 5/25/04 2:10:39 AM Reply	Not my pickings ________________ oop.ismad.com
Post #156,710 by admin 5/24/04 5:48:35 PM Reply	Re: Depends on the scale You generally don't have to parse to isolate the "atoms". Unless you always provide a perfect parsing specification, there is a chance of getting it wrong. The "walls" are predefined for us so that we don't have to find them over and over. foo.bar=Foo the bar\nmoo.gar=Moo the gar `grep "foo.bar"` finds all instances of the "foo.bar" message. You're inventing problems where none exist. I will agree that the existing crop of revision control tools are designed for files and not databases (although I have not done a survey yet). However, tables make it easier to roll-your-own. Plus, one can have more control over individual messages. I'm not interested in "rolling my own". I'm interested in getting work done. If your approach provides no tangible benefits, and in fact has some disadvantages as I have named, why in the name of seven Hades would I "roll my own" just to get to the same level of functionality I already had? I am pretty sure there is a size-point in which you agree that files won't cut it anymore. I don't see why. One file per message set per language. No overhead. If it's farmed out, give them the English version and say, "translate this". Once the bulk job is done, changes will be minor and are best handled through existing revision control tools. And I certainly wouldn't give a bunch of people located off-shore access to a database used by the production system. The management becomes harder the larger the system becomes, mainly due to the multiple environments I mentioned. You also make it sound as if tables are hard to use and bulky for internal stuff. Somebody used to XBase stuff will generally disagree. Something that large isn't using XBase, I can guarantee you. And they are bulkier and harder to use than resource files. Here's an example: \n<bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">\n\t<property name="basename"><value>Messages</value></property>\n</bean> That's what I do in the config file to load my resource files. When I want to use a message, I do this: <fmt:message key="some.key"/> That inserts it into the JSP file. Whoopdee doo, that's so incredibly hard. I must be high if I think that's better than a bunch of SQL select statements. And calling into a remote database for thousands of strings isn't practical. And if you cache them, that's more coding and database maintenance overhead just to match the same functionality provided by resource files. Pre-compiling involves the database in the compilation step, which is also useless overhead and harder to manage. Have you actually worked on a large-scale system? Say something with a few hundred tables, a million lines of stored procedures, and millions of rows of dynamic data? The kind of thing you're proposing introduces unneeded, unwanted complexity into an already complex system. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,719 by tablizer 5/24/04 6:19:48 PM Reply	no no no grep "foo.bar" finds all instances of the "foo.bar" message. Yes, but if you have "x = 'my foo bar is here'", it may also pick up that message. and in fact has some disadvantages as I have named Very minor. And the message tables can be used with other languages and systems. Once the bulk job is done, changes will be minor and are best handled through existing revision control tools. In my experience, vast change requests may come out of left field so that there is a lot of rework to be done. And I certainly wouldn't give a bunch of people located off-shore access to a database used by the production system. You don't give them database access, only access to a web application. And, it does not have to be a production system. Besides, why is file access safer than database access? A file system is a database, just not a relational one. Something that large isn't using XBase, I can guarantee you. And they are bulkier and harder to use than resource files. I am not necessarily talking about the production application language. One can build tools in a different language than final applications. I must be high if I think that's better than a bunch of SQL select statements. And calling into a remote database for thousands of strings isn't practical. You got it all wrong. Each message does not necessarily issue a Select statement. Have you actually worked on a large-scale system? Say something with a few hundred tables, a million lines of stored procedures, and millions of rows of dynamic data? The kind of thing you're proposing introduces unneeded, unwanted complexity into an already complex system. So we should chuck databases and go back to flat files to manage everything? How 1960's of you. The bigger the project, the more a database HELPS! Keeping tons of attributes in a bunch of hard-to-query and hard-to-find flat files is really annoyining. How about this. We start out with a file-based approach. If message management becomes a headache, then we DB-tize the config file generation. Deal? ________________ oop.ismad.com
Post #156,721 by admin 5/24/04 7:02:50 PM Reply	Re: no no no Yes, but if you have "x = 'my foo bar is here'", it may also pick up that message. `grep "foo.bar="` And the message tables can be used with other languages and systems. And a text resource file can't? You're stretching. In my experience, vast change requests may come out of left field so that there is a lot of rework to be done. Ah, your vast experience doing internationalized systems. I see. You don't give them database access, only access to a web application. And, it does not have to be a production system. Ah, so now you're maintaining TWO databases for the sake of this labor-saving scheme of yours. Got it. Besides, why is file access safer than database access? A file system is a database, just not a relational one. Because the changes are being checked in and managed by me, not the guy on the other end of the wire whose only talent is converting English into Swahili. You got it all wrong. No, it's called "covering all bases" since you're being so vague about "might" and "doesn't necessarily" and so forth. You oh-so-conveniently didn't quote "And if you cache them, that's more coding and database maintenance overhead just to match the same functionality provided by resource files." So just exactly how does this system of yours work? Or haven't you thought it through properly? Does it issue a single select? "Not necessarily." Does it cache them on the first hit? Who knows. Does it cache them for each page? Can't tell you. So we should chuck databases and go back to flat files to manage everything? How 1960's of you. The bigger the project, the more a database HELPS! Keeping tons of attributes in a bunch of hard-to-query and hard-to-find flat files is really annoyining. No, but they're damn nifty for internationalized messages. How very binary of you. "hard to query" Er, no. Got grep or find? Got an editor? Everyone does. Better that than "oh, to work on the messages you need to set up ODBC like so, and install Access, and search for them here like this. Oh, wait, you wanted to see the messages in QA, not DEV? Well, you need a different ODBC source then..." Seems to me the database version is a lot more of a pain in the ass for someone who just wants to edit a bit of text. "hard to find" Care to back this up? They're right there in the same place as the JSP files that use them, as opposed to way off in database land, completely unrelated to the code that references the messages. Seems to me the database version is a lot more of a pain in the ass for someone who just wants to edit a bit of text. How about this. We start out with a file-based approach. If message management becomes a headache, then we DB-tize the config file generation. Deal? What's this "we", Kemosabe? Message management hasn't become a headache yet. You've not demonstrated that it will be, and given that you have no experience in the matter... and since I'm working on a system right now that has nearly 2000 similar text resource files, I'll keep my own counsel on that one, capicé? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,724 by ChrisR 5/24/04 7:13:59 PM Reply	Doing my part to promote right shifting Perhaps you've already explained in this thread and I missed it, but..... Was wondering why your putting internationalization in the board. I've been putting off internationalization in my current app, mostly due to Sarbanes-Oxley being U.S. centric. Sooner or later I'm going to have to tackle it, as some of our customers have to get sign offs from far away lands (europe, china, etc). So I fully understand that it is a requirement for a lot (if not most) business apps these days. Just wondering what you are trying to leverage on zIWETHEY? (For example, does it make Nadsat or Guido easier to implement?)
Post #156,728 by tablizer 5/24/04 7:24:31 PM Reply	"Oh goody, a new framework for xmas!" Was wondering why your putting internationalization in the board.....Just wondering what you are trying to leverage on zIWETHEY? Isn't it obvious?: To make competing with his features harder for me. His whole life revolves around kicking p/r's ass :-) ________________ oop.ismad.com
Post #156,731 by admin 5/24/04 7:27:18 PM Reply	Re: "Oh goody, a new framework for xmas!" His whole life revolves around kicking p/r's ass Not really. I do that before breakfast and then go on to get real work done the rest of the day... ;-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,730 by admin 5/24/04 7:25:32 PM Reply	Internationalization (new thread) Created as new thread #156729 titled [link\|/forums/render/content/show?contentid=156729\|Internationalization] Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,734 by tablizer 5/24/04 7:38:16 PM Reply	admin grep "foo.bar=" That's the point: you have to keep sticking conditions in there as you encounter problems. And, what if there are spaces around the equal sign? A bigger and bigger regex for each new variation encountered. And a text resource file can't? You're stretching. I know that most languages can reference the common RDBMS. I don't have to keep reinventing the same parsing in different languages. Ah, your vast experience doing internationalized systems. I see. Just because you've done one or two does not mean you have encountered all possible request permutations. Ah, so now you're maintaining TWO databases for the sake of this labor-saving scheme of yours. Got it. Coupling to your favorite everchanging frameworks is not always labor-free either. Because the changes are being checked in and managed by me, not the guy on the other end of the wire whose only talent is converting English into Swahili. Well, then it is not a "large project". So just exactly how does this system of yours work? Or haven't you thought it through properly? Does it issue a single select? "Not necessarily." Does it cache them on the first hit? Who knows. Does it cache them for each page? Can't tell you. The optimum solution depends on a lot of things, for example whether we are using a dynamic or static language, whether performance is more important than developer labor, whether it is web-based, etc. "hard to find" Care to back this up? They're right there in the same place as the JSP files that use them, as opposed to way off in database land, completely unrelated to the code that references the messages. So lets put everything in code and forget databases. New employee? Don't put them into a database, but rather code up an XML file. Replace Oracle with XML. Yeah, that's progress. ________________ oop.ismad.com
Post #156,742 by admin 5/24/04 8:02:47 PM Reply	Resource files (new thread) Created as new thread #156741 titled [link\|/forums/render/content/show?contentid=156741\|Resource files] Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."

Welcome to IWETHEY!