De : Glenn Golden [mailto:[EMAIL PROTECTED]] > > An update, after dancing with the code last evening... > > The customizers break if I change the place the profile is stored, removing > it from the user.temp into the rundata. I think the customizers expect the > profile to have a scope wider than each individual request; a scope as large > as the many requests of the customization session. This scope is fine for > the customizers, but is wrong for the "user", as they may be doing other > things. I'm spending today fixing the customizers, if I can figure them out > ;). >
It should be pretty easy, you will just need to update the controller actions (org.apache.jetspeed.modules.actions.controllers.*). In the buildCustomizedContent() you'll probably find getProfile() calls but no saveProfile() since there's an implicit assumption of session persistence. > The Profile does hold the PSMLDocument, so it's not just a light weight name > thing, but the actual document as well. This is redundant with the caching > which is in the PSML managers. > Agreed. Profile holds a PSMLDocument reference simply to be able to do: profile.setDocument(doc) profile.store() I think this is necessary if we ever want to have a "profile customization" and let the user himself create new profiles. I'm not sure this is currently useful however. > The db psml manager has aggressive caching, even caching misses. This is > good as it reduces the backend database access. There's a refresher thread > running to make sure things in the cache are current (well, as current as > the refresher which runs by default every 8 hours). > Otherwise, the pages just fill up the cache, and memory. > > We could add some cache pruning based on LRU to the refresher > thread, as Raphael suggests. > I'm pretty sure the Turbine GlobalCache service is implementing such a LRU scheme so instead of using an hashtable in the PSML Managers implementation we would just need to use the GlobalCache service and have a common caching implementation across PSML managers > I would like to see the Castor PSML manager fixed up for caching to have the > same sort of thing as the db one, but I don't really use it much and not at > all in production. > I can probably fix the Castor PSML manager quite easily if you want me to do it. > Back to the customizers. I believe that they are doing things to the PSML > document that is attached to the profile, and if we don't have this live > past requests they don't work. First, I think this is bad, as they are > messing with the "live" (and possibly cached) psml document - anyone else > visiting the page will see changes in progress, I think, and there's no > chance to "cancel" the edit. Also, if the user comes in with another > window's request to another profile, it should mess up the customization > process. And if another user starts customizing the same profile, this will > also mess things up. > Agreed. > What I want to do is let the customizers have a copy of the profile / psml > document to work on. This copy would be associated with the request profile > - i.e. the edit copy of the page would be stored in the state manager keyed > by the page's profile and user session. This means that one user could edit > any number of pages at a time from different windows, as each custommization > state would be stored separately. It also means that any other users coming > in would not see the changes until committed, and if the customizing user > has another profile open in another window and requests come in from that, > nothing is messed up. > > When they press the final "Apply" or "Save" or whatever, the copy would be > put back into the PSML service, storing it on file / db and in the cache, > and the edit copy and other state would be cleared. > > I'll look at what that might look like today. > > Comments? > +1^1024 :) -- Rapha�l Luta - [EMAIL PROTECTED] Jakarta Jetspeed - Enterprise Portal in Java http://jakarta.apache.org/jetspeed/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
