Placement of Constants - again
in [Java Programming]
|
From: Jeff Higgins on 28 May 2010 12:28 On 5/28/2010 8:42 AM, Rhino wrote: > "Jeff Higgins"<oohiggins(a)yahoo.com> wrote in message > news:htme14$tec$1(a)news.eternal-september.org... >> On 5/27/2010 11:20 AM, Rhino wrote: >>> I'm trying to implement the advice I was given the other day about the >>> placement of constants that were shared in various classes of my project. >> By writing paragraphs of English prose? >> <http://xmlresume.sourceforge.net/> >> Yes, I know, there are XML naysayers. It's the thought that counts. >> > Actually, I'm not adverse to adding yet another format and XML would seem to > be a good choice.... > Yes, especially considering JAXP. Code lifted from Real's How To: <http://www.rgagnon.com/javadetails/java-0407.html> // jdk1.4.1 import javax.xml.transform.*; import java.net.*; import java.io.*; public class HowToXSLT { public static void main(String[] args) { try { TransformerFactory tFactory = TransformerFactory.newInstance(); Transformer transformer = tFactory.newTransformer (new javax.xml.transform.stream.StreamSource ("howto.xsl")); transformer.transform (new javax.xml.transform.stream.StreamSource ("howto.xml"), new javax.xml.transform.stream.StreamResult ( new FileOutputStream("howto.html"))); } catch (Exception e) { e.printStackTrace( ); } } }
From: Jeff Higgins on 28 May 2010 14:08 On 5/28/2010 8:35 AM, Rhino wrote: > "Jeff Higgins"<oohiggins(a)yahoo.com> wrote in message > news:htmf06$4bn$1(a)news.eternal-september.org... >> On 5/27/2010 1:37 PM, Rhino wrote: >> >>> That's the gist of it. >> <http://groups.google.com/group/comp.lang.java.programmer/msg/154ffc8e2c0e0cba?hl=en> > > I think you may have misunderstood my remark. The code I posted was REAL > code that compiles and was lifted from the class. I didn't provide all of > the code since it was very repetitive and it seemed pointless to show the > repetition. That's what I meant when I said it was the gist: not that it was > pseudo-code but that it was an excerpt. Sorry if my poor phrasing gave you > the wrong impression.... > Don't be sorry. It was your poor uncompilable code ... public ResumeFileGenerator() { localizationUtils = LocalizationUtils.getInstance(); resumeResources = localizationUtils.getResources(Locale.getDefault(), ResumeConstants.LIST_BASE); ..... }
From: Tom Anderson on 29 May 2010 07:12 On Fri, 28 May 2010, Jean-Baptiste Nizet wrote: > On 27 mai, 21:16, Martin Gregorie <mar...(a)address-in-sig.invalid> > wrote: > >> Since you seem likely to want to generate language-specific resumes I >> think there's a case for breaking up the resource bundle into one locale- >> independent one, which holds all items that are constant no matter what >> language is being used, e.g. your name, address, date of birth, etc, and >> a set of locale-dependent bundles which would contain information which >> is locale-dependent such as language-specific headings and boiler-plate >> as well as locale-dependent formatting for dates, time, money, etc. >> >> With this approach you don't end up copying invariant data into multiple >> resource bundles and running the risk of forgetting to update them all. > > This isn't necessary. You just have to place all the locale- > independent items in the base resource bundle (the one without any > locale at the end), and the locale-dependent items in each of the > locale-specific bundles. Martin was making the point that this might not be a good idea - look at his last paragraph again. If you do that, then there's a risk that when preparing a localisation, you copy the whole file, including the locale-independent items, and fail to delete them from it. You then have the same information in two places. If you ever need to change the information, you have to change it twice. It's probably not a big risk, particularly in this situation. But it's one that can be designed out altogether. tom -- Also, thinking about that Velociraptor thing, I think -- what with having trained on turkeys, guineafowl, geese, large chickens, swans and peacocks as a child -- that I could take a Velociraptor. I'd need a large hessian sack, some baler twine, and a hook to hang it from. And gloves. Not to forget the gloves. -- cleanskies
From: Tom Anderson on 29 May 2010 07:23
On Thu, 27 May 2010, Rhino wrote: > "Tom Anderson" <twic(a)urchin.earth.li> wrote in message > news:alpine.DEB.1.10.1005271735220.16072(a)urchin.earth.li... >> On Thu, 27 May 2010, Rhino wrote: >> >>> It's just one line of code: >>> >>> ColorPalette colorPalette = ColorPalette.BLUES; >>> >>> but I'm really struggling with where it needs to be. >> >> Presumably, you have a Resume class (or even better, a >> ResumePresentation). Who makes instances of that? Where does it get its >> information from? Where, for instance, is your name stored? > > The DATA on the resume is all stored in a ResourceBundle, including my name, > email address, job target, experience and all of that. The labels used to > present that information, like "Job Target", "Formal Education" etc. are > likewise stored in the same ResourceBundle. > > I have a Resume class. It's job is to find the obtain the information from > the ResourceBundle. It is basically a bunch of small getters, like > getJobTargetText() which returns the label "Job Target" (it would return the > French translation of Job Target if I create a French-language resume) and > getJobTargetData() which returns the jobs that I am targeting with this > resume. Okay, then make the palette a property of the Resume class. Other code which is interested in the palette says: Resume r; ColorPalette = r.getPalette(); You then just have to decide how to implement that getter. I'd start with the simple way: public ColorPalette getPalette() { return ColorPalette.BLUES } If you later decide you want data-driven palettes, you could load the choice from your resource file, or from some other configuration file. The important point is that everyone who needs to know a palette can just ask the Resume for it. > I don't have a ResumePresentation class at all. Is a "Presentation" > class part of one of the design patterns? No, sorry, i was thinking out loud and hoping that the name would make my meaning clear, which of course it doesn't even come close to doing. My thinking was that there's a difference between a resume (information about who you are and what you've done) and the way a resume is presented (layout, fonts, colours, etc). My suggestion above of putting the palette on the Resume object conflates these two ideas. Now, conflation isn't acutely poisonous, but it's a chronic toxin that should be avoided. In this case, i was thinking of factoring out a ResumePresentation class that held presentation-specific information. The palette would then be a property of that. You could have the ResumePresentation class refer to the Resume it presents (but not vice versa - a resume should not know or care about its presentation), or you could make ResumePresentation Resume-agnostic, and only have them interact when the time came to do some presentation. >>> All of the classes in the project share a common set of >>> ResourceBundles. (I want to keep open the possibility of generating >>> resumes in foreign languages since I have a working knowledge of two >>> other languages and could picture working in countries where those >>> languages are spoken. I haven't actually translated phrases like "Job >>> Target" or "Format Education" to the other languages but I _could_ and >>> might do that.) The base name of the ResourceBundles is used in both >>> ResumeFileGenerator and ResumeApplet. Where should I put its >>> definition so that both classes use the exact same name? >> >> Same problem as above. This belongs to whoever is in charge of making >> Resume objects. If there are several places where Resume objects are made, >> then refactor until there is only one, and put it there. >> > Hmm. I'm not sure I'm understanding you correctly. Based on my > description so far (in the original post and this followup) would you > agree that ResumeFileGenerator is the place where the Resume objects are > made? Or are you talking about the specific classes that generate each > Resume, like ResumeFileWriterAscii, ResumeFileWriterHtml, > ResumeFileWriterPdf and so forth? And what about my standalone > ResumeApplet? The resume in that is NOT created by ResumeFileGenerator. In which case the second sentence in the paragraph applies. Factor out a factory for Resumes (which could be as simple as a static factory method on Resume), and share it between the ResumeFileGenerator and the ResumeApplet. tom -- Also, thinking about that Velociraptor thing, I think -- what with having trained on turkeys, guineafowl, geese, large chickens, swans and peacocks as a child -- that I could take a Velociraptor. I'd need a large hessian sack, some baler twine, and a hook to hang it from. And gloves. Not to forget the gloves. -- cleanskies |