Re: [ebxmlms-develop] refactoring anyone?

[Patrick Y. <kc...@ce...>]

For package refactoring, I am pretty conservative. Unless the old 
package introduces a blocker to further development, I am pretty fine to 
stick to the original design. For the new configuration, are you using 
JMS, or are we uisng some new Command to replace the old one?
Regards, -Patrick

rtv...@xs... wrote:

>Hi all,
>
>I've seen in the TODO that there is an item for refactoring large methods. Isn't there a
>requirement for some other refactoring as well? e.g. I've tried to create a package
>hk.hku.cecid.phoenix.message.persistence and moved al items that I coud think of to that package.
>I had to change some methods to public to make them 'visible', but nothing dangerous securitywise
>(imho). All tests still run fine. Is this something that is also on the wishlist? or should I
>abandon it.
>
>The next thing I'd like to do (and have already partly done) is to create a
>k.hku.cecid.phoenix.message.configure package which will contain code to start/stop/backup etc the
>server. The serialized Command class will not be used here anymore since I will start using it to
>configure the MSH via a browser. I've already started this discussion once and realy want to
>implement it but want some feedback (or hints) on the idea to abandon the Swing GUI for
>configuring the server. This will require a lot of refactoring.
>
>Ronald
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>who ports your project to Linux PPC the best. Sponsored by IBM.
>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>_______________________________________________
>ebxmlms-develop mailing list
>ebx...@li...
>https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>  
>