Granted, our 'suffering' is trivial in comparison with people who deal 'real' jobs. After all, as many of my friends have pointed out, all we do is sit around, drinking tea and chatting with people, followed by messing around with computers - hard to argue with that assessment. Anyway, as we move applications over to Seaside, I am really keen that we should do everything possible to simplify the admin. And, that is why I found this section of Ramon Leon's Terse Guide to Seaside, so interesting. He wrote:
FooComponent class>>initialize
"self initialize"
| app |
app := self registerAsApplication: #foo.
app libraries add: SULibrary.
app preferenceAt: #sessionClass put: FooSessionThis sets up a dispatcher at /seaside/foo with the Scriptaculous library (SULibrary) and a custom session class that might contain things like the current user or current database session. You can then highlight the comment “self initialize” and run it to create your site. This has the additional advantage of automatically setting up your site in any new image when you load your package into it and also allowing you to programatically recreate your site on demand. This comes in very handy when upgrading to newer versions of Seaside which sometimes require recreating your sites.
I think this is going to be very useful for the future
2 comments:
I prefer putting all of that later stuff into an override of #registerAsApplication:. Consider what would happen if you used the web-based config to install it as /seaside/bar instead of (or in addition to) /seaside/foo. Your library wouldn't be there. Your preference wouldn't be there. But if you put that all in as:
MyClass class >> initialize
self registerAsApplication: #foo.
MyClass class >> #registerAsApplication: name
^(super registerAsApplication: name)
libraries add: SULibrary;
preferenceAt: #sessionClass put: FooSession;
yourself.
Then it all just works, regardless of what happens later at the webconfig.
That's not a bad approach assuming you ever want to run multiple instances of the same application in one image or configure your apps manually via the config app.
I don't bother because I use one image per application and I use Apache on the front end to run the site as / rather than /seaside/appName so that approach wouldn't really benefit me.
Post a Comment