|
Title: class path strucutre for utilities... Post by: mattb on August 26, 2009, 10:13:00 Hi,
We have a few classes that we are using over and over so im moving them into re-usable utilities. And I was wondering what the best way to package them would be ? For example take a class to do with web services. As part of an application it would be com.domain.appName.model.ServicesProxy However, if we moved this, and a collection of other related classes to a resuable utility - how should we package it? com.domain.puremvc.webServices.model.ServicesProxy ? com.domain.puremvc.utilities.webServices.model.ServicesProxy ? com.domain.puremvc.as3.multicore.utilities.webServices.model.ServicesProxy ? Any sugestions / examples would be great. cheers. m. Title: Re: class path strucutre for utilities... Post by: puremvc on August 26, 2009, 10:49:49 There are a number of reasons why you might be doing this, and that has some bearing.
Are you extracting code into a library to be shared by other modules in the same com.domain.appName application, or for a desktop or mobile version of a web client? If so, then you just want to leave the package name as it is, simply putting it in a library and then including it back into the app. That's the zero-code solution. If you're planning to submit them for inclusion in the PureMVC repositories, then specific advice for packaging can be found in this post: http://forums.puremvc.org/index.php?topic=142.0 Are you just packaging some convenient classes that you use in nearly all the apps you write? Or are you planning to put out a library that talks to your webservices so that developers everywhere can build clients to talk to them? Either way, give the library a name. I wouldn't put puremvc in the path of the package necessarily. If you're architecting around PureMVC, that's a given. What's missing is the utility library name. com.domain.appName.model.ServicesProxy Would likely become: com.domain.libName.model.ServicesProxy Packaging is an art. Though you will see some long packages here at PureMVC.org, every node in the package has a long-considered reason for being there. As a result I can easily hand-type pretty much any package in the system without hesitation. -=Cliff> Title: Re: class path strucutre for utilities... Post by: mattb on August 27, 2009, 02:13:11 Thanks for the reply,
We are just packaging classes for convenience as we are using them more and more in various apps we build - they may be used by 3rd parties when outsourcing work. I was thinking about adding the puremvc node as we have other generic utilities / classes that are not built round a framework -just simple ui components, Number / Date utils etc that we re use. These are currently com.domain.ui.* com.domain.utils.* com.domain.air.* etc And thought it would be good to distinguish between them, but I see your point about removing it, and it helps with the original issue of ending up with uneccisasarily long package names! Never thought coming up with package names could be quite so in depth! |