Resource files

Post #156,741 by admin 5/24/04 8:02:47 PM Reply	Resource files 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. Er, no, that isn't the point. It's always the same format, or it Doesn't Work. You're inventing problems. I know that most languages can reference the common RDBMS. I don't have to keep reinventing the same parsing in different languages. Well, the first time I have to reinvent a parser for this I'll call you up and buy you a beer. Just because you've done one or two does not mean you have encountered all possible request permutations. Look, it's a simple thing. Text strings. Change them. Done. Your flights of fancy are just that. Make that two beers. Coupling to your favorite everchanging frameworks is not always labor-free either. Oddly enough, resource files have been like this since Java 1.1. And the only change is that it gets easier to use. And let's say that tomorrow there's a mass migration from Spring to Struts (for example). Hey, ho, move the message files, Struts uses them the same way. I'll take that over maintaining several databases any day. Editor. Text file. Done. I don't have to invent any tools. Everyone knows how to change them. Hell, do it in Word if you want to... that's what some of our customer interface people do. They much prefer text files over having to modify something in the database. Well, then it is not a "large project". Or the build manager, or the CIM, or whomever. Someone with source code control repository access. Big whoop. It's not worth building an entire friggin' application to manage. 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. (what sound does a weasel make?) PHP. Web-based. Performance is important. But since the resource file version is easier than a database version, you lose on developer labor already. Pick some set, I don't care, but quit with the vague hand-waving already. 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. Er, no, let's put the MESSAGES in a TEXT FILE and keep the DATA (you know, stuff like transactions, orders, inventory, etc.) in the DATABASE. Stay on target there, again. You're just being daft now. Answer the point: if the message files are in the same code tree as the JSPs that use them, are they hard to find? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,748 by ChrisR 5/24/04 8:09:10 PM Reply	Speaking of Struts What are you fixing to use for the Presentation layer? JSP? From what little I've read about spring and hibernate, they are more geared towards a Bean type interface (without the hideousness of EJB). Is there a web page rendering engine hidden in there somewhere (though I suppose you could use them to generate html on the fly).
Post #156,761 by admin 5/24/04 8:44:32 PM Reply	Ya. It's actually faster than Velocity now, and more flexible. I still like Velocity's syntax better, but the newer JSP spec adds the ability to do ${some.variable} without an accompanying <c:out tag. Small improvement, but nice nonetheless. Spring is a lightweight container. The big deal is the automatic bean configuration. This is the real magic. Set your datasource up for testing. Change it to JDNI for release. Or use a local datasource for some stuff, a JNDI source for others. Declare your transaction boundaries no matter what's using what. All without the overhead of EJB. However, all of the other stuff builds on that. You use the bean config to map URIs to controllers, etc. There's no special syntax in the config file like Struts has; it's very dynamic and flexible. The view portion basically says, "I don't care how you render. Here's a model in the form of a map." The various view types (Velocity, JSP, etc... I just made one for a charting engine) take the model and change it into whatever that engine requires: servlet request attributes for JSP, VelocityContext for Velocity, DataSource object for the charts. Then the result is passed off and away she goes. So no, it doesn't have it's own templating engine. Just a generic view rendering system. There's also stuff that maps the views by name to various renderers, so you can just say "render this with the 'foo' view" and the bean config takes care of mapping that to a JSP or whatever. You can also just create a View object on the fly and pass that instead of a string. There's also stuff like an exception-free JDBC library (verra nice) and other nifty things. Which brings up another point: almost everything in Spring uses unchecked exceptions. No more catching endless SQLExceptions if you don't want to. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,944 by mmoffitt 5/25/04 6:32:22 PM Reply	OT: Recommendation request. What books would you recommend? The Sun Microsystems training foo I mentioned elsewhere is just awful. I'm assuming O'Reilly is a best bet, is that right? bcnu, Mikem If you can read this, you are not the President.
Post #156,945 by admin 5/25/04 6:32:56 PM Reply	For which? JSP? J2EE? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #157,018 by mmoffitt 5/26/04 8:34:28 AM Reply	All of the above. bcnu, Mikem If you can read this, you are not the President.
Post #157,020 by admin 5/26/04 8:38:10 AM Reply	Re: All of the above. [link\|http://www.bookpool.com/.x/kqqqra9aj4/sm/0764543857\|Rod Johnson's book] then. As far as low-level "this is how the c:out tag works" I just use the online stuff. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #157,029 by mmoffitt 5/26/04 9:51:48 AM Reply	Ordered. Thanks. bcnu, Mikem If you can read this, you are not the President.
Post #157,030 by admin 5/26/04 9:53:08 AM Reply	It's a great book. He's not terribly kind to stupid J2EE technologies. Lots of good, practical advice, as opposed to programming by buzzwords. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,908 by tablizer 5/25/04 4:23:14 PM Reply	hug a table Er, no, that isn't the point. It's always the same format, or it Doesn't Work. You're inventing problems. It may always be the same format, but the actual values may throw off the parsing unless your reg.ex is perfect. A perfect reg.ex is sometimes a big regex, or may be beyond what reg.ex can do. I have had parses pick up the wrong stuff or ignore the wrong stuff before, so it is not "inventing" problems. Maybe you are more accurate with parsing. Lucky you. You get a gold parsing star. But I prefer to avoid parsing to process data if possible. With tables it is usually not necessary because the atoms are already isolated for us. Parsing should be a last resort. I'll take that over maintaining several databases any day. Editor. Text file. Done. I don't have to invent any tools. Everyone knows how to change them. Hell, do it in Word if you want to... that's what some of our customer interface people do. They much prefer text files over having to modify something in the database. Data-centric shops often are familiar with and accept table browsing tools. I agree that a shop needs a certain level of "investment" in tablized techniques before it is cost effective, but once you reach that point, tables are a very nice thing. I did contracts for Xbase shops where all kinds of "config" data was in tables. Every developer and operator there had no problem browing a DBF table. Oracle shops tend to use a product called "Toad". It is not the best, but works good enough. Storing the same stuff in text files seems archaic in comparison. XBase ruined me. Once you've done it with Tablina it is hard to go back to Texterina. You will sit at the lake's edge writing ballads to your lost love. Eventually Moores law will make it so that we don't have to translate tables to case lists or XML or whatever. Until then I am stuck with converting the tables to text files/scripts to get the needed speed. But tables are the wave of the future. OOP was slower than what came before it because higher abstaction needs more horse power. Similarly, the next level up (tables) needs yet more horse power. ________________ oop.ismad.com
Post #156,909 by admin 5/25/04 4:34:59 PM Reply	Re: hug a table It may always be the same format, but the actual values may throw off the parsing unless your reg.ex is perfect. Format: some.string.for.a.key=The value for it. You're inventing problems. Yes, I know you like to write where clauses to search for stuff. It Isn't Necessary. I don't even use regular expressions to grep for things. In fact, this is a stupid conversation to begin with. Here's the search process: What screen? FooScreen. OK, go to the FooScreenMessages.properties file. What language? French. OK, go to the FooScreenMessages_fr.properties file. What message key? "some.error.message". OK, open FooScreenMessages_fr.properties file, hit 'ctrl-s' for search, and start typing the key 'some.error.message'. You're inventing problems. Data-centric shops often are familiar with and accept table browsing tools. I agree that a shop needs a certain level of "investment" in tablized techniques before it is cost effective, but once you reach that point, tables are a very nice thing. We have over 1 million lines of PL/SQL source code. Huge hulking database servers. Hundreds of tables. Millions upon millions of records in them. Everyone here has a copy of Toad, and most of them can use SQLPlus without batting an eye. I hardly think we qualify as unfamiliar with table browsing tools. Storing the same stuff in text files seems archaic in comparison. It's the simplest thing that works. Putting it in tables adds nothing to the process other than overhead. But tables are the wave of the future. Keep telling yourself that. To everyone else they're just one tool among many. So to distill your arguments: use tables instead of text files because Bryce is more familiar with them. Other than that there are no tangible benefits. Since you didn't answer the other points, I will assume that you concede the overhead. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."*
Post #156,914 by tablizer 5/25/04 5:08:34 PM Reply	query and change by multiple factors Here's the search process: What screen? FooScreen. OK, go to the FooScreenMessages.properties file. What language? French. OK, go to the FooScreenMessages_fr.properties file. What message key? "some.error.message". OK, open FooScreenMessages_fr.properties file, hit 'ctrl-s' for search, and start typing the key 'some.error.message'. Yes, but if you have multiple screens to change, you end up opening and closing a bunch over and over again. Suppose you had a query like: \n select * from messages \n where appID='nerg'\n and screen='blah' and msgKey='zok' and language='french'\n Then you would only have to edit the search parameters for each one. (Some browsers can be made to prompt if you put a special marker in place of a parameter.) There is no open-open-open, close-close-close, open-open-open.... pattern that a file editor would have to keep going through. (Yeah, I know, you can write editor scripts.) And suppose we needed to change the word 'back' to 'previous' in multiple screens: \n select * from messages \n where msgText like '%back%' and language='english'\n We can then get a list, inspect it to see which ones need changing, and then change those we want. (I am assuming that we want to study each one rather than a sudden bulk change.) Your approach would take longer because you have to open and close each file/screen that needs a change. The query brings it all together in one edit-grid. In fact, the query approach will immediatly tell us how many need changing. You would have to go to grep first. ________________ oop.ismad.com
Post #156,916 by drewk 5/25/04 5:15:48 PM Reply	vim `grep -lr "search_term" *` === Implicitly condoning stupidity since 2001.
Post #156,919 by admin 5/25/04 5:19:28 PM Reply	No, no, no! Firing up Toad and running the same query in 6 different environments is MUCH better than doing that! Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,941 by tablizer 5/25/04 6:24:32 PM Reply	grep is your SQL Firing up Toad and running the same query in 6 different environments is MUCH better than doing that! Toad would already be open. So grep and goofy command-line parameters are better? And each utility invents its own. ________________ oop.ismad.com
Post #156,997 by pwhysall 5/26/04 1:02:40 AM Reply	Of course it is :) Because "grep string files" is SO much HARDER than "SELECT stuff FROM tables WHERE string=somevalue ORDER BY something;", innit? Peter [link\|http://www.debian.org\|Shill For Hire] [link\|http://www.kuro5hin.org\|There is no K5 Cabal] [link\|http://guildenstern.dyndns.org\|Blog]
Post #157,004 by tablizer 5/26/04 1:44:31 AM Reply	SQL requires much less parsing because "slots" predefined ________________ oop.ismad.com
Post #156,917 by admin 5/25/04 5:17:54 PM Reply	It doesn't work that way. Shared messages are in one file. And your ignoring the issue of promoting these changes through the environments. Until you understand that, all of this is really hand-waving. You're adding nothing other than overhead. Your approach would take longer because you have to open and close each file/screen that needs a change. It might if that were an actual change that occurred. You're inventing problems. Or let's say you're not. Let's say that someone actually comes up with that change, once. WHO CARES? You're adding overhead and complexity for one lousy change that might happen once. Sounds like a pain in the ass to me. And are you going to concede that we aren't exactly unfamiliar with databases and their uses here? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,910 by admin 5/25/04 4:45:22 PM Reply	Question: Have you ever worked in a place that has multiple database environments (dev, test, qa, etc.) that promoted configuration information between the environments? If so, how was the promotion performed? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,918 by tablizer 5/25/04 5:18:03 PM Reply	I hate to say it, but Bill Gates is on my side WRT files Have you ever worked in a place that has multiple database environments (dev, test, qa, etc.) that promoted configuration information between the environments? If so, how was the promotion performed? Yes, and sometimes things did get out of sync, I will admit. But the real problem is that we are dealing with 2 different kinds of databases: a file system (hierarchical) database, and a relational database. Microsoft, for one, is seriously thinking about merging them so that they will not be different things. Thus, migrating files (if we still call them that) and migrating config data will be the same thing. Convergence is coming! You flat-file-tree-and-code lovers will be the New Luddites and I will be playing a nano-violin to soothe your sorry soul. ________________ oop.ismad.com
Post #156,922 by Yendor 5/25/04 5:22:29 PM Reply	Is that supposed to be a Good Thing[TM]? -YendorMike [link\|http://www.hope-ride.org/\|http://www.hope-ride.org/]
Post #156,923 by admin 5/25/04 5:22:49 PM Reply	Oh, now THERE'S an argument. "Bill Gates said so!" So when that happens, and droves of people install Windows 2035 so they can put their I18N messages in database tables, I'll buy you a beer. Until then, answer the question: how did you do the promotion? But the real problem is that we are dealing with 2 different kinds of databases Who's the "we"? Are you talking about the current topic of discussion, or your problems keeping things in sync? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,925 by ChrisR 5/25/04 5:24:41 PM Reply	Convergence Don't look for that convergence to be necessarily beneficial to programming for tables. Indeed, the point of the convergence, if there is a point, is to make the database look like a file system - not make the file system look like a database server.
Post #156,926 by admin 5/25/04 5:27:48 PM Reply	What "convergence", anyway? The AS/400 has been doing that for years. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,929 by ChrisR 5/25/04 5:33:45 PM Reply	But Bill Gates innovated it!!!
Post #156,937 by altmann 5/25/04 6:03:41 PM Reply	Tee hee hee I wouldn't look so fondly at WinFS if I were you. The main API is basically an OR mapping. -- Chris Altmann
Post #156,938 by admin 5/25/04 6:04:58 PM Reply	snort :-D Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,963 by tablizer 5/25/04 8:37:26 PM Reply	Not surprising. It is a hedge I wouldn't look so fondly at WinFS if I were you. The main API is basically an OR mapping. They are simply allowing it to be multi-paradigm to satifsy more customers. OODBMS are commercial failures for the most part, so they went with a hybrid approach: O-R mapping. ________________ oop.ismad.com
Post #156,962 by ben_tilly 5/25/04 8:35:42 PM Reply	I'm glad you admit it Have you ever worked in a place that has multiple database environments (dev, test, qa, etc.) that promoted configuration information between the environments? If so, how was the promotion performed? Yes, and sometimes things did get out of sync, I will admit. I'm glad you admit it. Because what you just said is that you don't have a solution for the problem that Scott is talking about, and you had bugs because of it. Not possible bugs. Not woulda, shoulda, couldas. But actual maintainance problems. That you didn't figure out a solution to. Now all that you have to do is see how, when you are using version control anyways, that problem is eliminated. But the real problem is that we are dealing with 2 different kinds of databases: a file system (hierarchical) database, and a relational database. Microsoft, for one, is seriously thinking about merging them so that they will not be different things. Thus, migrating files (if we still call them that) and migrating config data will be the same thing. No, that isn't the real problem. The real problem is that we have data of different types. (Note that code itself is just data.) Different types of data move in separate ways, and so should be maintained separately. Application data generally does not move, people on production generate production data. You don't want to "promote" test data to production. Configuration data and code data tend to move in the same way at the same time. Therefore putting them together in revision control makes sense. The standard development toolkit includes things like revision control systems, editors, searching utilities, make, etc. As long as the state of the art for these is not as well-developed on the database as on regular filesystems, that is an argument for using filesystems for code and configuration data. Convergence is coming! You flat-file-tree-and-code lovers will be the New Luddites and I will be playing a nano-violin to soothe your sorry soul. If the standard development toolkit is all available for data backed by relational databases, few developers will notice or care when they switch. You still like having configuration information under revision control for the same reasons that applied before convergence. To the extent that Microsoft breaks that toolkit, their environment, convergence or no convergence, remains inferior for development purposes. 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 #157,253 by tablizer 5/27/04 3:10:59 PM Reply	Today and Tommarow Not possible bugs. Not woulda, shoulda, couldas. But actual maintainance problems. That you didn't figure out a solution to. I did not have the authority to do anything about it even if I wanted to fix it. I have already agreed with Scott that with the existing state-of-the-art and existing tools, files may indeed be the way to go for his needs. To the extent that Microsoft breaks that toolkit, their environment, convergence or no convergence, remains inferior for development purposes. Relational is a more powerful abstraction than tree-base file systems. Often tools that rely on older abstractions will break when a switch is made to newer improved abstractions. It is roughly analogus to moving from 8.3 DOS file names to long names. Or, trying to print graphics on a text-only printer. Note that one can still emulate file trees in relational the same way one can still use 8.3 file names in newer tools, but when people start using the full power of relational, those old-style tools probably won't work well. ________________ oop.ismad.com
Post #157,263 by folkert 5/27/04 3:35:04 PM Reply	Today IS tomorrow I have already agreed with Scott that with the existing state-of-the-art and existing tools, files may indeed be the way to go for his needs. Well, I'd say this will ALWAYS be true. Tools that are currently existing, will always be used. Relational is a more powerful abstraction than tree-base file systems. Often tools that rely on older abstractions will break when a switch is made to newer improved abstractions. It is roughly analogus to moving from 8.3 DOS file names to long names. Or, trying to print graphics on a text-only printer. Note that one can still emulate file trees in relational the same way one can still use 8.3 file names in newer tools, but when people start using the full power of relational, those old-style tools probably won't work well. Yes, using a relational abstraction is all well and good, may actually be a good way to head towards. But, there will nearly always be a hierarchy that tree-based file systems will be good for. Right now the AS400 currently has a DB for a file-system. Pretty much as you'd want, just not as extensible as you'd prolly like though. When those tools that rely on the OLD-WAY of doing things are properly maintained, they will use the "legacy" abstractions if they are there, and the new ones when they are there. It really depends on the piece between the keyboard and the chair, in terms of how things are used. CVS(with RCS) in and of itself is a database, a database of code and changes to that code. In effect your tool is already there, it just has to back-ended differently. Relational can pertain to OOP and TOP, there really is no distinction between the programming methods when looking at it from a relational standpoint. The things you bring up... OOP is TOP, when dealing with a database. Why would you do anything else? When dealing with a Database, you are having to orient your Data towards a normalization, then code the application(s) or queries to your tables. Rough analogies are just that, rough. 8.3 -> LFN doesn't compare. Printing doesn't really compare either. It's all about perception. Many of those old tools that are here now, have been migrated through many many years of methodologies... and will continue to migrate with the current methodologies, as well as sometimes allow extensions to current methodologies. Either way, many of the "old favorties" will have all the old features (undocumented or not) and plenty of new ones. -- [link\|mailto:greg@gregfolkert.net\|greg], [link\|http://www.iwethey.org/ed_curry\|REMEMBER ED CURRY!] @ *i_wethey* Give a man a match, he'll be warm for a minute. Set him on fire, he'll be warm for the rest of his life!
Post #157,285 by ben_tilly 5/27/04 4:59:19 PM Reply	"More powerful abstraction" has no absolute meaning Abstractions need to be fitted to the use to which they are put. A great abstraction that doesn't fit how you need to work sucks for that purpose. A limited abstraction that happens to be a great fit can be very good. Now the relational abstraction is very powerful. And is very good for a lot of things. But it is not directly a very appropriate abstraction for many development tasks. You should not have to type in a line of SQL to edit a line of code. Therefore I'll reiterate, it does not matter how powerful the relational abstraction is, if a high-quality toolkit (with its own abstractions) that is appropriate for development has not been built on top of the relational one, then it is better to manage your code outside of a relational database. 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,920 by ChrisR 5/25/04 5:19:58 PM Reply	The problem with putting config info in tables... ...is that it's quite possible that the thing you are configuring is the database itself. But then you probably knew that.
Post #156,924 by admin 5/25/04 5:24:28 PM Reply	No, no, no! You see, you have this other database that configures the first one! Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,934 by JimWeirich 5/25/04 5:54:23 PM Reply	I've seen that You see, you have this other database that configures the first one! Egads! We do that where I work now. We have a control data base tells you where all the other data bases are located. Ahhh, but how do we configure which control database to use? -- -- 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,935 by admin 5/25/04 5:56:21 PM Reply	Re: I've seen that See, you have this other database the configures the configure database...! That's a nice single point of failure, too... Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,939 by altmann 5/25/04 6:06:21 PM Reply	You're very clever, young man, very clever... ... but it's databases all the way down. -- Chris Altmann
Post #156,940 by admin 5/25/04 6:07:54 PM Reply	No, it isn't... There's the four large elephants with heads the size of continents, too... Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,995 by Ashton 5/26/04 12:39:39 AM Reply	..standing on Great A'Tuin Kinda figured it would finally emerge that all youse guys learned machine language on Discworld, in free fall over The Edge.. probably individually sentenced by Senator McTethis to that swan dive. for terminal mopery, OO and tabular thinking in a Magic field, no less This would explain.. lots.

Welcome to IWETHEY!