Re: Structuring a GUI project to avoid stop - starts
Hi Konrad, > If I'm understanding this correctly the simple way to do this is to > put the logic for each page in its own file. so instead of (de report > ..) I would have a report.l file that just contains the guts of what > I'm coding. Right. The family demo program is not a good example for that, as it puts for simplicity everything into a single file, and uses functions for each object GUI frame instead of external files. A better example is the "app/" demo. All our production apps follow this layout. There is a "main.l" which loads the system libraries, contains some global definitions, and loads app-specific "er.l", "lib.l" and "gui.l" files. These files change rarely after the first version of the application is done. But if the model in "er.l" changes, it is better to stop the server, delete the database files, and start again (resulting in the execution of the init code). This is easier than doing the model changes in-memory, and editing the database to reflect the new structures. When "lib.l" (general utility functions) and "gui.l" (the menu structure dialogs, and other GUI related functions) change, I simply enter (load "xxx/lib.l") in the REPL. Or I use (edit 'foo) followed by a (ld). 90 percent of the application code resides in object GUI forms (e.g. in the "app/" demo these are "role.l", "user.l", "sal.l", "cusu.l", "item.l" and "ord.l") and other pages (most typically reports or special actions like data im- and exports). For these files, nothing at all has to be done. I just reload the page in the browser. To keep some context in such files, I often use 'once' to avoid repeated code execution. Other 'load'ed code takes care to avoid repeated effects by using 'push1' instead of 'push' (as in e.g. "lib/form.l" and "socialshareprivacy/lib.l") and similar measures. In that way I try to organize each file (except "er.l") in such a way that it can be re-loaded at any time. > Reloading model.l is not really an issue for me. Besides at the moment > if it does change ir porably means that the underlying database also > needs to be nerfed and recreated becasue I've made large changes to > the the entity structures. THough this is not likely at this stage Exactly. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Structuring a GUI project to avoid stop - starts
Thanks Jose, If I'm understanding this correctly the simple way to do this is to put the logic for each page in its own file. so instead of (de report ..) I would have a report.l file that just contains the guts of what I'm coding. Reloading model.l is not really an issue for me. Besides at the moment if it does change ir porably means that the underlying database also needs to be nerfed and recreated becasue I've made large changes to the the entity structures. THough this is not likely at this stage where I'm mostly working on getting my reporting function to spit out the HTML that I want. regs Konrad. 2012/3/6 José Romero : > Hi Konrad, > > On Tue, 6 Mar 2012 12:46:44 +1100 > Konrad Zielinski wrote: > >> Hi, >> >> At the moment I have my project in two files >> >> model.l which contains my domain classes, database init code and other >> related functions. >> server.l which contains my URL handling functions. >> >> I find that I'm constantly having to kill and restart the server >> process and then navigate to the code I'm working on. This is quite >> cumbersome. >> >> Is there a way to get the running picolisp process to detect and >> action changed source files without constant restarts. >> >> regs Konrad >> > > You could just use the technique Alex uses, most of the code that > may need some quick tweak for each object is contained in a file that > is quickly 'loaded every time a request for that object arrives. > > If you are careful designing the application you could make server.l > 'load model.l again once in a while (maybe by "visiting" some secret > URL). if you have stuff in server.l that may change very often, move it > out to another module. > > If you want to automatically detect a changed file and reload it, you > could code something like this, on Linux, using inotifywait(1) (I use > this code for synchronizing files between my shared host and my laptop > over ssh+rsync) > > # Recursively watch the current directory > (setq *InotifyFD > (pipe > (call 'inotifywait "-mrq" > "-e" "modify,create,move,delete" > "." ) ) ) > > (de reload () > # load modules, initialize variables, etc etc. > ) > > (task *InotifyFD > (in *InotifyFD > # The process died somehow, clean up. > (when (eof) (task *InotifyFD)) > (line) # Eat notification. > # Wait 5 secs for the notifications to settle before reloading
Re: Structuring a GUI project to avoid stop - starts
Hi Konrad, On Tue, 6 Mar 2012 12:46:44 +1100 Konrad Zielinski wrote: > Hi, > > At the moment I have my project in two files > > model.l which contains my domain classes, database init code and other > related functions. > server.l which contains my URL handling functions. > > I find that I'm constantly having to kill and restart the server > process and then navigate to the code I'm working on. This is quite > cumbersome. > > Is there a way to get the running picolisp process to detect and > action changed source files without constant restarts. > > regs Konrad > You could just use the technique Alex uses, most of the code that may need some quick tweak for each object is contained in a file that is quickly 'loaded every time a request for that object arrives. If you are careful designing the application you could make server.l 'load model.l again once in a while (maybe by "visiting" some secret URL). if you have stuff in server.l that may change very often, move it out to another module. If you want to automatically detect a changed file and reload it, you could code something like this, on Linux, using inotifywait(1) (I use this code for synchronizing files between my shared host and my laptop over ssh+rsync) # Recursively watch the current directory (setq *InotifyFD (pipe (call 'inotifywait "-mrq" "-e" "modify,create,move,delete" "." ) ) ) (de reload () # load modules, initialize variables, etc etc. ) (task *InotifyFD (in *InotifyFD # The process died somehow, clean up. (when (eof) (task *InotifyFD)) (line) # Eat notification. # Wait 5 secs for the notifications to settle before reloading. (alarm 5 (reload)) ) ) You could be more sophisticated reading the module name of the file that changed, or preferably being more specific with which files to watch, look at the manpage of inotifywait(1) for loads of more useful info. Cheers, José -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
