Feedback on RAlmonte's reply to JTan - RJL051119 RJLRef: $PH/05f523/week12/bdeDesignNotes051119.txt > From ralmonte@cs.uml.edu Sat Nov 19 09:50:22 2005 > To: > Cc: "Bob Lechner" > Subject: 91-523 - Working on Final Project. > Hi Jing, ...[cut-RJL] > Other stuffs needed if we have time. > - We need a logger lib, I found one but it's only free, if the application > you are building is free (http://ex-code.com/propcpp/). > I haven't check log4CXX. This one is similar to log4j with some C++ > limitation. > You can use the logger to track event in the menu and button selection for > now. > This also will be helpful to test our code before starting to plug it to > BDE. I checked this URL http://ex-code.com/propcpp/ and was confused: I didn't see any mention of logging, but the cross-notification is interesting. You can check out my earlier slide show on these .ppt slides at $PH/ghostvarsRev3, and Prachee Sharma's MS thesis on ghost variables in $CASE/98*: ------------------------ This is libpropc++ 1.0 library - the ANSI C++ template library to create "properties" of objects: Property color; which can be manipulated like this: widget.color = "red"; Properties can be bound with other properties to automatically synchronize their values (so that when one property changes, the other changes accordingly). libpropc++ supports many different kinds of binding properties including one-directional and two-directional bindings, bindings properties of different value types and binding with a value transformation (by a function or an other kind of functor). See this article for detailed discussions about binding properties in general. Binding properties particularly simplifies development of GUI applications: checkbox.checked.bind(frame.visible); mutual_bind(menu_item.selected, appPrefs.configItem); libpropc++ also has built-in signalling (Observer Pattern from object oriented methodology) implementation or (alternatively) can use libsigc++ for signalling. Signal programming is the programming paradigm of an object notifying other objects when some event (for example change of a value of a property) happens. libpropc++ API is documented using Doxygen. libpropc++ is written using highest programming technologies and standards ------------------------ I can see the value of this when 1-way or 2-way changes flow between the View/Conroller and the Model DB. My questions include: gencpp will produce get and set field value functions for any field of any entity class. (set_fkey is buggy and needs extension) Suppose node, hlink and caption are added to bde's schema (e.g., as tables GN, GL and GT). Then gencpp would generate code to maintain these classes like any other. They need not be saved since we can restrict the table list in the view passed to pr_dump. The diagram set tends to grow, but GraphSelect changes the displayed element list from one HG to another. The only invariant NOT affected by GraphSelect is that IFF a GN, GL or GT exists, it MUST have a HNid, HLid or CGid to its database table rowclass parent instance. This suggests to me that updatedisplaylist should instantiate the appropriate cross-notification functions from each display list element to its HG component parent. Moreover, updating a display list element field should propagate to the corresponding field of its database parent instance (rowclass). What happens in bde is that each GraphSelect operation (HG-class-method?) deletes and recreates a new set of node GN, hlink GL, and caption GT objects via updatedisplaylist(). That function calls 'copy' constructors which can initialize (e.g. HN-)fields: pr_set(GNcurr,GNfield, pr_get(HNcurr,HNfield)); //pr_get/set or GNcurr->pr_setGNfield(HNcurr->pr_getHNfield); //pr_accessors Local edits to the canvas should propagate changes in the reverse direction: pr_set(HNcurr, HNfield, pr_get(GNcurr,GNfield)); HNcurr->pr_setHNfield(GNcurr->pr_getGNfield); Right now update propagation is procedural and ad hoc. Sometimes it is necessary to apply conversion or derivation functions along the way (e.g. DCtoWC, WCtoDC). (Right now these simply cast float to/from int, but the future of WC is [0..1] normalization.) The diagram set tends to grow, but GraphSelect changes the displayed element list from one HG to another. Now it's time to consider that pr_set has logging built in. When bdeState and bdeEvent classes are integrated into bde, these are logged (and replayed) for free. I am interested in how libpropc++ provides cross-updating. Can gencpp produce calls to its cross-update methods automtically? [Then Model-View cross-updates can be genrated for any class that gencpp defines automatically for any schema.sch entity class of any application, not just bde.] Gencpp and pr_accessors.c from chgen13 both produce get/set functions for all class data members. (The hard one (TBD) is schema-relationship-dependent fkey update.) Perhaps libpropc++ uses better techniques to generate set and get code with I/O logging; or perhaps it is essentially the same.:-) Perhaps it can show us how gencpcp can generate its cross-notify set(get()) calls automatically (dynamically, at run-time, in response to Graph Select?) (I suspect we will have to (a) custom-code an enhanced updatedisplaylist and/or constructors to propagate updates from Model to View during replay or in DBDE; and/or (b) automatically generate enhanced XX::pr_set_XXField functions so they call libpropc++ functions that propagate field value changes in either direction. How can this be arranged? (1) For singleton 1..1 to 0..1 relations like HN-----GN, persistent data fields that need cross-updates counterparts may need to be tagged in the delegate table in schema.sch and meta-table TA. (2) The is_key meta-attribute of GNcurr->HNid may need more values to distinguish between a subclass and a delegate with or without cross-notification. If you have time to investigate libpropc++ further, my concerns and interests are listed above. Its LGPL license (and the Fox LGPL) is not a problem, since I would like the COOL framework to become an OpenSource project under [L]GPL as well.