From mb at bese.it Fri Jul 9 14:42:59 2004 From: mb at bese.it (Marco Baringer) Date: Fri, 09 Jul 2004 16:42:59 +0200 Subject: [Bese-devel] ucw status Message-ID: it's been mighty quiet hasn't it? here's a brief summary down of what's happened lately (since 0.2.3): -------------------------------------------------------------------- - select/option tags now work on with lisp values, not strings. if you want the "standard" html behaziour use <:select and <:option, otherwise use I've known about UCW for some time now, but am just now starting to take a closer look at it for development. In your recent status message Marco, you mentioned that the portableaserve backend was suffering from some bit rot. I haven't taken much of a look yet, but portableaserve is my web server of choice, so I would be interested in hearing more about any specific shortcomings of which you are aware. Perhaps I could tinker with fixing those as I get acquainted with the system(s). Anthony W. Juckel From mb at bese.it Wed Jul 14 09:52:48 2004 From: mb at bese.it (Marco Baringer) Date: Wed, 14 Jul 2004 11:52:48 +0200 Subject: [Bese-devel] Overview of UnCommon Web Archives References: Message-ID: Anthony Juckel writes: > I've known about UCW for some time now, but am just now starting to > take a closer look at it for development. In your recent status > message Marco, you mentioned that the portableaserve backend was > suffering from some bit rot. I haven't taken much of a look yet, but > portableaserve is my web server of choice, so I would be interested in > hearing more about any specific shortcomings of which you are aware. > Perhaps I could tinker with fixing those as I get acquainted with the > system(s). i'd heard that the acl-compat interface had changed, but i haven't had a chance to check. it may very well still work perfectly, and if it doesn't it's probably just a question of changing a few function names. i'd suggest starting the examples with the aserve backend and seeing what errors come up. the asreve backend does however have one major issue: currently it installs a handler for the entire url path space (everything after the host), and not just for those directoriees and file types associated with ucw applications. i don't _think_ this would be a big deal, but i don't have the time to learn aserve enough to figure out how to do it. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Wed Jul 21 14:00:51 2004 From: mb at bese.it (Marco Baringer) Date: Wed, 21 Jul 2004 16:00:51 +0200 Subject: [Bese-devel] ucw docs Message-ID: as i've said before, the final missing ingredient in ucw 0.3 are the docs. i was hoping to get something out this week but looking at my current situation that's probbaly not going to happen, however in the mean time you can view the docs at: http://tech-dev.ath.cx:9000/ucw/docs/index.ucw [official sponsors: The Tech Co-op (http://tech.coop)] currently only the ovreview and the components chapters exist, everything else is very much "under construction." typos and spelling corrections are appreciated. what would be really nice is someone who will help me explain ucw better: my problem is that i understand the system too well to realize what's clear and what's confusing. happy reading. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From ajuckel at gmail.com Wed Jul 21 18:46:56 2004 From: ajuckel at gmail.com (Anthony Juckel) Date: Wed, 21 Jul 2004 13:46:56 -0500 Subject: [Bese-devel] ucw docs In-Reply-To: References: Message-ID: On Wed, 21 Jul 2004 16:00:51 +0200, Marco Baringer wrote: > > currently only the ovreview and the components chapters exist, > everything else is very much "under construction." typos and spelling > corrections are appreciated. what would be really nice is someone who > will help me explain ucw better: my problem is that i understand the > system too well to realize what's clear and what's confusing. > > happy reading. Would you prefer to receive documentation patches as annotations on that website, or as patches to the source? Note, I haven't looked through the documentation too extensively yet, so I don't have any current changes. Anthony W Juckel From mb at bese.it Thu Jul 22 12:25:17 2004 From: mb at bese.it (Marco Baringer) Date: Thu, 22 Jul 2004 14:25:17 +0200 Subject: [Bese-devel] ucw docs In-Reply-To: (Anthony Juckel's message of "Wed, 21 Jul 2004 13:46:56 -0500") References: Message-ID: Anthony Juckel writes: > Would you prefer to receive documentation patches as annotations on > that website, or as patches to the source? Note, I haven't looked > through the documentation too extensively yet, so I don't have any > current changes. i will take whatever i can get :) however, if it's the same for you i'd prefer patches. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Thu Jul 22 14:09:36 2004 From: mb at bese.it (Marco Baringer) Date: Thu, 22 Jul 2004 16:09:36 +0200 Subject: [Bese-devel] expired sessions Message-ID: i don't remeber where i've talked about this issue and where i haven't, if i'm repeating myself just ignore me. what happens when the user's session expires? on the server we simply remove a hash-table entry which frees up all the data associated with that session. on the client side however nothing changes, the page is still there and the links are still clickable, and this is the problem, what happens when we get a request for a session which doesn't exist anymore? decisions, decisions, decisions. there are a few options: 1) don't expire the session, or expire it after a very long time of inactivity. this is actually a fine solution on internal systems with just a few (< 50) users where the number of sessions is never greater than a few thousand. 2) expire the last frame of a session after a very long time. this seemed like a good idea, and does in fact catch 95% of the issues without uselessly consuming lots of memory, but it's a half-assed hack which i'm not going to implement. 3) make the url's generated by action-href usefull even if the session has expired. generally these urls look like .../ucw-action-call.ucw?f=...&s=...&a=... (forms set f, s and a via hidden parameters, but the idea is the same). the idea would be to make the ucw-action-call.ucw flexible enough so that a developer could set things in such a way that a meaningfull entry point url would be generated. these may not be exactly what the user expects, but would be far better than the current situation. option 3 looks best, but i'm not really sure what the interface should be. there are quite a few entites which may want to say what that url should be: the application, the session, the session frames and the component rendering the link. obviously we would like the application be able to provide a default (probably to a home page or some such) but we'd also like the session ta have it's say so "My" type pages would work and the component could be usefull so that we can provide links which have something to do with what the intended action was. then we need to decide how this is set and how entry-point parameters interact with it. idea 1 is that "it" will be a generic function where the first of component, current session frame, session or application (in that order) to supply a value will be used. the function would be passed the current object and the current context, which should be enough to generate a usefull url. idea 2 is make "it" the value of a slot in standard-component, standard-session-frame, etc. (as opposed to a generic function) with a function which reads from the various slots. this would allow you to set up different urls without having to sub class too many things, but would make putting parameters in the urls more difficult. both of these ideas don't play well with nested components. for example: if we have a range-view located in some result set, we'd like to make the urls gerented by the range-view go to the result object's query page (or recreate the query and directly show the results via parameters to an entry point). neither of the above ideas make this use-case particularly easy or clean (maybe this is a case where you'd use something from the session-frame, then then you're limited to one entry point url per page, which goes against ucw's components are independent philosophy). i'd appreciate suggestions. iow: speak now or forever hold your peace :) this will probably be the first thing i do post 0.3, i need to get to some mile-stone and release if i don't want to end up in an eternal state of flux. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Thu Jul 22 15:20:03 2004 From: mb at bese.it (Marco Baringer) Date: Thu, 22 Jul 2004 17:20:03 +0200 Subject: [Bese-devel] web sessions Message-ID: i was hoping to post this as an annotation on the docs, but due to some weird system issues the server has lost write access to itself. go figure. any way, the question was regarding components and sessions and whether two components' idea of what the current user name was could get out of sync. the answer is yes, that is very possible. what i'd like to point out though is that putting the user name in a component isn't really a great idea to begin with (unless it's an edit-username component). session global data like that should really go in the session object, and you'd access thove values with accessor defined on your session class. so now you're all asking yourselves, how do i do that? the idea is that you'd define a subclass of standard-session and tell your application to use that instead of standard-session. currently this requires a bit more work than it should: (defclass my-application-class (standard-application) ()) (defmethod application.session-type ((app my-application-class)) 'my-session) (defclass my-session (standard-session) (...)) (defapplication my-app (:class 'my-application-class) ... other defapplication args ...) that could fairly easily be reduced to a :session-class argument on defapplication, but it's done so rarely (iow once) that i haven't bothered. i'm currently entertainig the idea of putting a lazily created eql hash-table in standard-session and adding a get-session-value and (setf get-session-value) generic function. hth. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Fri Jul 23 11:04:09 2004 From: mb at bese.it (Marco Baringer) Date: Fri, 23 Jul 2004 13:04:09 +0200 Subject: [Bese-devel] expired sessions In-Reply-To: (Marco Baringer's message of "Thu, 22 Jul 2004 16:09:36 +0200") References: Message-ID: thanks to a break down on the bus i had some time to think about this, here's what i've come up with: we know that the server will call the application's SERVICE method, which will call the session's SERVICE, which will call the session-frame's SERVICE method, which will call the action, so if we bind a special variable around the call to the application's SERVCIE method all of the interested entities can set it, and if they do we get the overriding of the defaults in the order we want (ie if the application sets "it" to something the session can still override that value, that second value can then be overridden by the action, all of this via a simple assignment to a special variable.). after the various SERVICE methods have been called (and have returned) we then call render-on on the current frame' root-component. this component can then, by rebinding this special variable around calls to render-on of nested components, setup whatever values its wants (which resoles the range-view issue we had with ideas 1 and 2). so while in the "action phase" we'll probably set the value directly during the "render-on phase" we'll probably just rebind it. to allow makimum flexibilty the value of this special variable (called *action-url-generotor* or something) will be a methed which takes 4 args, the current context, the session id, the frame id and the action id, and returns a string which we append to (application.url-prefix application) to generate a valid url. afaict this solves all of the use-cases i had in mind. i like this idea for 2 reasons: 1) i find it simple conceptually. 2) it's easy to implement. unless someone points out a major flaw with this idea i'll implement it in the next few days (before 0.3 (yes, i know, ucw will never stabilize and the docs will never get written, sorry)). if anybody has ideas for improvements, or just questions, please speak up. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Fri Jul 23 11:14:06 2004 From: mb at bese.it (Marco Baringer) Date: Fri, 23 Jul 2004 13:14:06 +0200 Subject: [Bese-devel] expired sessions In-Reply-To: (Marco Baringer's message of "Fri, 23 Jul 2004 13:04:09 +0200") References: Message-ID: Marco Baringer writes: > to allow makimum flexibilty the value of this special variable (called > *action-url-generotor* or something) will be a methed which takes 4 > args, the current context, the session id, the frame id and the action > id, and returns a string which we append to (application.url-prefix > application) to generate a valid url. obviously this will also require that the developer setup entry points for this. this mechanism will probably make entry points more common than they currently are and we'll (i use the term "we" loosely :)) need to think about how to make calling and manipulating entry-ponits easier. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Fri Jul 23 14:42:46 2004 From: mb at bese.it (Marco Baringer) Date: Fri, 23 Jul 2004 16:42:46 +0200 Subject: [Bese-devel] expired sessions References: Message-ID: Marco Baringer writes: > unless someone points out a major flaw with this idea i'll implement > it in the next few days (before 0.3 (yes, i know, ucw will never > stabilize and the docs will never get written, sorry)). if anybody has > ideas for improvements, or just questions, please speak up. ok, it's ucw--dev--0.2--patch-161. the patch contains changes to the docs which use the new feature. i've updatet the live demo so you can play with a bit and see what's changed. while it works the api is still kind of odd, i'll use it a bit and see what it should be (of course, you could use it and tell me what you'd like too). happy hacking. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Sat Jul 24 10:16:20 2004 From: mb at bese.it (Marco Baringer) Date: Sat, 24 Jul 2004 12:16:20 +0200 Subject: [Bese-devel] arnesi 1.2 and yaclml 0.5 Message-ID: i light of the upcoming (sooner or later) ucw release i bumped the version numbers and built tar balls for arnesi and yaclml containing all the latest goodies ucw needs. i also created new development branches (arnesi--dev--1.2 and yaclml--dev--0.5 respectivly). unforntunetly this means that you'll have to do some minor arch foot work if you want to keep getting the latest updates in the arnsei and yaclml dirs. assuming you have directory layout the ucw dev config creates you'll need to: $ cd ucw/libs/arnesi/ $ tla set-tree-version arnesi--dev--1.2 $ tla replay $ cd ../yaclml/ $ tla set-tree-servion yaclml--dev--0.5 $ tla replay sorry for the inconvience. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Sat Jul 24 11:28:02 2004 From: mb at bese.it (Marco Baringer) Date: Sat, 24 Jul 2004 13:28:02 +0200 Subject: [Bese-devel] expired sessions In-Reply-To: (Marco Baringer's message of "Fri, 23 Jul 2004 16:42:46 +0200") References: Message-ID: Marco Baringer writes: > while it works the api is still kind of odd, i'll use it a bit and see > what it should be (of course, you could use it and tell me what you'd > like too). i win! i win! i beat you all to it! :) here's the new api: *action-url-generator* is special variable which must be bound (during the entire service and rendering phase) to a 0 arg function. this function must return a string which can be used as the "base" of an action url. the generic function generate-action-url is specialized on the current application and returns a complete url. the default implementation of generate-action-url (specialized on standard-appliciation (not standard-request-context)) calls *action-url-generator*, prepends the application's url-root and appends the session-id, frame-id and action-id parameters. this seems like a good, default, balance between use of use and flexibiltiy, if you really want to do weird things just define generate-action-url on your own custom application class. nb: generate-action-url must be able to handle nil values for session-id, frame-id and action-id (this to accomadate our form handling stuff). what this means, in practice, is that the default binding for *action-url-generator* is simply: (lambda () "index.ucw?") [yes, this means you'll never see a ucw-action-call.ucw url ever again] this change moves much of the foot work of dealing with session-id, frame-id and action-id parameters out the *action-url-generator* and into a "core" method where developers don't have to worry about it. as an exmple the documentation app can now simply bind *action-url-generator* to the result of: (defun doc-action-url-generator (node) (lambda () (concatenate 'string "lookup.ucw?node-id=" (node.id node) "&"))) instead of the mess we had before. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From ajuckel at gmail.com Wed Jul 28 21:26:51 2004 From: ajuckel at gmail.com (Anthony Juckel) Date: Wed, 28 Jul 2004 16:26:51 -0500 Subject: [Bese-devel] Retrieving arnesi from bese-2004@common-lisp.net Message-ID: I'm having an issue downloading the ucw distribution to a new machine. This is either resulting from a misconfiguration in the upstream arch repo, or a complete lack of understanding of arch on my part. I followed the directions exactly from the download page: $ tla register-archive ... $ tla get ucw-2004 at ../support--dists ucw-dist $ cd ucw-dist $ tla buildcfg dev UCW downloads just fine, but when it starts downloading arnesi, I get the following error: ******************************** MISMATCHED ARCHIVE CHECKSUM archive: bese-2004 at common-lisp.net revision: arnesi--dev--1.2--base-0 file: arnesi--dev--1.2--base-0.tar.gz expected: 07153dc3f5690a55c2f75fcf90657801 got: 778d4bc1415059d6bfec55baee73005a ******************************** Unfortunately, I'm not sure how to get around this issue. I'm assuming the expected checksum is stored in the arch repo, and the got checksum is calculated from the downloaded tar.gz file, but I don't see that file on my system at all now (presumably it is deleted once the above error is encountered). Is anyone else having this problem? Oddly enough, I just did a tla set-tree-version on one of my other machines to move the arnesi version to 1.2, then did a tla replay, and that worked just fine. It is just when doing this fresh checkout that I get the error. Anthony W. Juckel From ajuckel at gmail.com Fri Jul 30 14:14:42 2004 From: ajuckel at gmail.com (Anthony Juckel) Date: Fri, 30 Jul 2004 09:14:42 -0500 Subject: [Bese-devel] Linking to resources (css, js) required by components Message-ID: I've been thinking about some modifications to the rendering of standard components (especially tabbed-pane). The one issue that I'm stuck on trying to find a resolution for is how to link to external files for css and js content. First, why link to external files? Two reasons: 1) To make the rendered page as clean (i.e. free of cruft) as possible and 2) to allow for browser caching of said pages. The first thing is, how do we register such requirements. As an example, my redesigned tabbed-pane requires a css file, lets call it "tabbed-pane.css." I think the option I'm leaning toward is the following. First, the component definition needs to be updated to register the fact that it has required resources. In this case, the definition for tabbed-pane would end up something like the following: (defcomponent tabbed-pane (standard-component) ((panes :accessor tabbed-pane.panes :initarg :panes) (current-pane :accessor tabbed-pane.current-pane :initarg :current-pane :ini\ tform 0)) (:template "ucw/tabbed-pane.tal" [...snipped for brevity...]) (:requires-external-resources t) (:documentation "Component for providing the user with a standard \"tabbed pa\ ne\" GUI widget.")) Next, there's a new generic function, (defgeneric render-requirements (component)) with the following definition for tabbed-pane: (defmethod render-requirements ((component tabbed-pane)) (<:link :rel "stylesheet" :type "text/css" :href (concatenate 'string *ucw-resource-root* "tabbed-pane.css"))) This naturally requires that *ucw-resource-root* is defined within ucw (much as *ucw-tal-root* is defined now), and appropriately served up by the backend. The last hurdle is to trigger the calling of render-requirements on all components within a given page when rendering the element of the page. To make it transparent, it would be nice if yaclml supported registering hooks for elements, so we could do something like the following: (yaclml:register-hook (:head :end) #'(lambda () (ucw:render-requirements ucw:*all-components*))) That would tell yaclml to call render-requirements and append the output to the response before closing the element. This in turn would require a new special variable ucw:*all-components* that is simply a list of all components used within the rendering of a given page. All in all, this is looking quite ... crufty. There's too much going on to get a rather simple effect accomplished. I'm open to suggestions for streamlining all of this. For instance, it would be fairly simple to avoid the :requires-external-resources declaration for the component by just providing: (defmethod render-requirements ((component standard-component))) and calling this method for all components. What other ways could this be accomplished? Are there existing hooks within ucw/yaclml that could provide similar functionality? Anthony W. Juckel