From: Johann G. <jo...@gy...> - 2004-11-09 20:36:26
|
Hi Nigel > It is good to see the new account entries panel using the Eclipse > editor > UI. The editor UI is certainly far better. Thanks. But it's only a first attempt and I have still a lot to do. What I don't know currently is how to handle with the reports. I we use editors, should the reports be placed in editors as well? Or in a view? If they are placed in a view then they are not in the editor area, however, they take a lot of space and the best place _would be_ the editor area. > I assume your intention is to remove the 'folder' view altogether once > all the panel in the 'folder' view have been moved into the editor > area. > Would you like me to do this for you? It would be very easy for me to > do and this would free you up to get the account entries panel > completed. I would simply move the code that processes the jmoney > pages > extension point so that it instead puts the controls created by the > extension points into editor pages. I would also move the code that > activates an editor into the double click processing of the navigation > view. I don't want to interfere with your work if you are planning on > something here, so let me know if you would like me to do this. Please do it, you won't interfere. I just decided to check in my code I've done so far. Unfortunately, there is nothing more. > I also note you have hard-coded the account properties into the panel. > I would > have used the composite control AccountPropertiesControl, which is > defined in net.sf.jmoney.bookkeepingPages.AccountPropertiesPages in the > main JMoney plug-in. This control discovers the properties dynamically > so will display any properties added by plug-ins and will display > properties appropriate for other account types that may be supported > (e.g. a credit card account would have some properties different from a > bank account). Yes, I know that I have to handle with contributed properties. However, I don't know if a plug-in should provide it's own editor when contributing properties. The entry table is not the problem, one can simply add the property. But what about the editing area of an entry? > On a different matter, I would like to split the CapitalAccount > classes. > The CapitalAccount class derived from the Account class will contain > the > sub-account list, the abbreviation and comment properties. A class > derived from that (called, say, CurrencyAccount) will contain the > currency and startBalance. A class derived from that (called, say, > BankAccount) will contain the remaining properties (the properties that > apply only to a bank account). CapitalAccount represents any account > that contains assets (i.e. is not an income and expense category > account). CurrencyAccount represents any account that can contain only > a single type of asset (such as a bank account that can contain only a > single currency). If a plug-in were to add, for example, a stock > brokerage account class then that would derive from CapitalAccount but > not from CurrencyAccount. If a plug-in were to add, for example, a > credit card account class then that would derive from CurrencyAccount > but not from BankAccount. As another example, I believe that Olivier's > charts can be made to work on accounts other than at the Postbank and > the Compte service CA :-) All accounts could be iterated and those of > type BankAccount could be put in the list, or even those of type > CurrencyAccount. > > The reason for splitting CapitalAccount is that this enables plug-ins > to > add their own types of accounts. This also enables views of data to > decide which types of accounts they can display. The account entries > list, for example, would not be able to display and edit an account > that > contains multiple types of assets such as a stock account but you might > decide that it can be used for any single currency account such as a > credit card account. Therefore the account entries panel would > register > itself as accepting CurrencyAccount and the page would only appear in > the editor if the account were a CurrencyAccount. A more specific view > might require the account is a BankAccount, or a less specific view > might require only that the account is a CapitalAccount (in which case > it would have to be able to deal with entries in the account in various > different currencies or commodities). Well, I just agree because this is beyond my financial scope :) Johann |