SHORT: You may wish to *look* at the first units paper at
https://www2.ccs.neu.edu/racket/pubs/#pldi98-ff because what you describe is almost exactly the example from that paper. Just read the example section. If you like what you see, jump into the docs. ;; - - - SOMEWHAT LONGER: People usually shift a compile-time organization to a run-time one when confronted with this situation, that is, the desire to split such things in a static, tree-shaped world. The code then exports functions that when called with proper callbacks create the desired code and perform properly. What you give up then, is a compile-time confirmation that these things match up. Units solve this with support for mutually referential components. To some extent they are independent of modules and you can use modules with units just fine. Historically, units were our first module system but getting syntax export/imports right is easier with first-order modules. — Matthias > On Mar 23, 2018, at 11:39 AM, HiPhish <hiph...@openmailbox.org> wrote: > > Hello Racketeers, > > I am trying to create a GUI program, my problem is that the source code for > the > GUI portion is growing out of control and I don't know how to split it up. > > Here is some background info: the GUI is basically just a specialised frontend > to a database, the users clicks some stuff, the corresponding query is > constructed and sent off to SQLite using the db library. > > The layout is to have one main window with a tab view. The application is > supposed to manage a small library, so each tab shows either the books, the > users, or the rentals. Here is a simple tree-view of the GUI: > > main window > | > |-- main tab view > | > |-- Books pane > | | > | |- List view of books (a table) > | |- Button to add a new book > | |- Button to remove a book > | |- Button to rent out a book > | > |-- Users pane > | | > | |- List view of users (a table) > | |- Button to add a new user > | |- Button to remove a user > | > |-- Rentals pane > | > |- List current rentals (a table) > |- Button to remove a rental > > > I might reconsider the rentals part, but that's not relevant at the moment. My > problem is that even though the three panes don't need to know anything about > each other, they need to know about their parent (the main tab view), I cannot > split the code into a module hierarchy like the tree. > > (define main-window (new frame% [label "Library"])) > (define main-tab-view (new tab-panel% [parent main-window])) > > (define books-panel (new vertical-panel% [parent main-tab-view])) > (define books-table (new list-view% [parent books-pane])) > (define books-buttons-pane (new horizontal-pane% [parent books-panel])) > (define add-button (new button% [parent books-buttons-pane])) > (define remove-button (new button% [parent books-buttons-pane])) > (define rent-button (new button% [parent books-buttons-pane])) > > > And so on. This isn't much code, but add in all the callbacks and events, and > repeat that for all the three views, and the code quickly starts adding up. > How should I break it up into smaller modules? > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
