From: Maike D. <mai...@gm...> - 2007-05-18 06:06:10
|
Hi, after some silence - another progress report. I had some trouble figuring out the best way to deal with this situation: remember we have the ClinicalDocuments tied to non- Singletonian Topcomponents - the Banners. The patient screens are updated when the user chooses another ClinicalDocument (i.e. a Patient Banner). This Netbeans magic happened through the General lookup mechanism and worked fine. The opposite though had also to happen, and this proved way more tricky to find out. The problem is this: the patient screens are all Singletons, and are fed the ClinicalDocument that they need when the user chooses the accompanying Patient Banner. When the user changes a Patient name, we want this change to propagate to the Banner, and this is non trivial because we want no coupling to exist between the Singleton screen module and the Banner instance. How to do this? Even the NB list could not give me an answer - what I want is apparently a little odd. Point in case is that Netbeans is basically a file-centered framework and not a database-centered one: so all the nice file-changed whizzbang framework methods were of no use here. I have seen more people complaining about the lack of facilities that implies to us database-using types, but that was not much help. Finally Glen and I decided on using some sort of Listener or broadcast mechanism, and after fiddling around with an awful polling mechanism and some non-working listener contraptions I decided to go with the good old Observer - Observable pattern. This was still some pain in the <lower body part> to get to work because we still had this synchronisation mechanism from the Tapas Stone Age that does basically this: whenever one saves an object, it is bounced back by Casa and used to refill the screens. This little trick does, however, not give you the same instance back of the ClinicalDoc, even though it is the *same* ClinicalDoc from the user's perspective. But the Observer pattern does come in handy here as well, because we can make every screen an Observer for the ClinicalDocument. Once you save it, its changed flag is set and every Observer that is registered on it gets notified and is passed the same instance to do with it whatever we desire: to refresh the screen, to name one thing. Bingo! Bango! So - I am happy to tell that it works now. Cheers Maike |
From: Glen M. <mc...@gm...> - 2007-05-18 06:14:20
|
I knew that you'd make it work!!! Way to go! What do I get to try it? g. On 5/17/07, Maike Dulk <mai...@gm...> wrote: > Hi, > > after some silence - another progress report. > > I had some trouble figuring out the best way to deal with this > situation: remember we have the ClinicalDocuments tied to non- > Singletonian Topcomponents - the Banners. The patient screens are > updated when the user chooses another ClinicalDocument (i.e. a > Patient Banner). This Netbeans magic happened through the General > lookup mechanism and worked fine. > > The opposite though had also to happen, and this proved way more > tricky to find out. > The problem is this: the patient screens are all Singletons, and are > fed the ClinicalDocument that they need when the user chooses the > accompanying Patient Banner. When the user changes a Patient name, we > want this change to propagate to the Banner, and this is non trivial > because we want no coupling to exist between the Singleton screen > module and the Banner instance. How to do this? > > Even the NB list could not give me an answer - what I want is > apparently a little odd. Point in case is that Netbeans is basically > a file-centered framework and not a database-centered one: so all the > nice file-changed whizzbang framework methods were of no use here. I > have seen more people complaining about the lack of facilities that > implies to us database-using types, but that was not much help. > > Finally Glen and I decided on using some sort of Listener or > broadcast mechanism, and after fiddling around with an awful polling > mechanism and some non-working listener contraptions I decided to go > with the good old Observer - Observable pattern. > > This was still some pain in the <lower body part> to get to work > because we still had this synchronisation mechanism from the Tapas > Stone Age that does basically this: whenever one saves an object, it > is bounced back by Casa and used to refill the screens. This little > trick does, however, not give you the same instance back of the > ClinicalDoc, even though it is the *same* ClinicalDoc from the user's > perspective. But the Observer pattern does come in handy here as > well, because we can make every screen an Observer for the > ClinicalDocument. Once you save it, its changed flag is set and every > Observer that is registered on it gets notified and is passed the > same instance to do with it whatever we desire: to refresh the > screen, to name one thing. Bingo! Bango! > > So - I am happy to tell that it works now. > > Cheers > Maike > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Tap-apps-discuss mailing list > Tap...@li... > https://lists.sourceforge.net/lists/listinfo/tap-apps-discuss > |
From: Maike D. <mai...@gm...> - 2007-05-18 06:27:43
|
As soon as I have installed RapidSVN ... SmartSVN is kind of a pain. I'll let the list know. BTW still have to integrate that Java DB over here! I know it's in there, but I would like to do that together :-) Maike On 17-May-07, at 11:14 PM, Glen McCallum wrote: > new that you'd make it work!!! Way to go! > > What do I get to try it? |