headers
Zach Beane | 1 Dec 2011 02:25
Picon

No longer builds with Hunchentoot 1.2.2

Hunchentoot 1.2.2 has removed the hunchentoot:*default-handler*
symbol. It's referenced by src/server.lisp. As a result, Weblocks no
longer builds for me.

Is Weblocks still an active project? Is it likely to be updated to
adapt to the changes in Hunchentoot 1.2.x?

Thanks,
Zach

--

-- 
You received this message because you are subscribed to the Google Groups "weblocks" group.
To post to this group, send email to weblocks@...
To unsubscribe from this group, send email to weblocks+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.
Permalink | Reply | 1 comment |
headers
Ury Marshak | 2 Dec 2011 18:05
Picon

Hunchentoot 1.2, *DEFAULT-HANDLER* and suggested rework of default

This is a slight rework of the way weblocks handles default
application.
Motivations for the change are as follows:

1. Hunchentoot 1.2 does not support *DEFAULT-HANDLER* - needs the
update
2. There's a need in production to have a different default
application than weblocks' standard. Hence the variable *WEBLOCKS-
DEFAULT-APP-NAME*. Set it to the symbol naming your weblocks app to
make it default.
3. It might be necessary to make default application depend on the
situation (for example the name of the virtual host to which the
request is made). So there's a variable *WEBLOCKS-DEFAULT-APP-NAME-
FN*, that can be set to a function taking request object and returning
symbol naming an application.

I'm also posting these changes with some other bugfixes and updates
for Hunchentoot 1.2 in my clone of weblocks here:
https://github.com/ury-marshak/weblocks-dev/tree/updates and here is
the diff (for this change):

diff --git a/src/acceptor.lisp b/src/acceptor.lisp
index 347222d..9f96940 100644
--- a/src/acceptor.lisp
+++ b/src/acceptor.lisp
 <at>  <at>  -1,7 +1,7  <at>  <at> 

 (in-package :weblocks)

-(export '(weblocks-acceptor))
(Continue reading)

Permalink | Reply | 4 comments |
headers
Daniel Borchmann | 5 Dec 2011 08:11
Picon

Re: Hunchentoot 1.2, *DEFAULT-HANDLER* and suggested rework of default

Hi Ury,

thanks for this!  But I do not know whether we should care about
backwards compatibility with Hunchentoot 1.1.0?  Your code wouldn't work
with it.

Best,
Daniel

-- 
Daniel Borchmann                                   http://daniel.kxpq.de
GPG (Mail)            04A9 66A1 A17C C91E 39B5  8722 69B0 E96D A109 8F58

--

-- 
You received this message because you are subscribed to the Google Groups "weblocks" group.
To post to this group, send email to weblocks@...
To unsubscribe from this group, send email to weblocks+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.
Permalink | Reply | 1 comment |
headers
Leslie P. Polzer | 5 Dec 2011 14:59
Picon
Gravatar

Re: No longer builds with Hunchentoot 1.2.2

On Dec 1, 2:25 am, Zach  Beane <zbe...@...> wrote:

> Is Weblocks still an active project? Is it likely to be updated to
> adapt to the changes in Hunchentoot 1.2.x?

Very likely.

Right now I'm very busy with personal things, but it's priority
stuff to get this update out ASAP.

  Leslie

--

-- 
You received this message because you are subscribed to the Google Groups "weblocks" group.
To post to this group, send email to weblocks@...
To unsubscribe from this group, send email to weblocks+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.
Permalink | Reply | 0 comments |
headers
Leslie P. Polzer | 5 Dec 2011 15:01
Picon
Gravatar

Re: Hunchentoot 1.2, *DEFAULT-HANDLER* and suggested rework of default

On Dec 5, 8:11 am, Daniel Borchmann <daniel.borchm...@...
dresden.de> wrote:
> Hi Ury,
>
> thanks for this!  But I do not know whether we should care about
> backwards compatibility with Hunchentoot 1.1.0?  Your code wouldn't work
> with it.

Backwards compatibility is nice to have and will save a lot of
headaches,
but a backwards incompatible patch is acceptable to start with.

  Leslie

--

-- 
You received this message because you are subscribed to the Google Groups "weblocks" group.
To post to this group, send email to weblocks@...
To unsubscribe from this group, send email to weblocks+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.
Permalink | Reply | 0 comments |
headers
Scott Burson | 28 Dec 2011 07:52

Re: Re: CLSQL-Fluid

On Wed, Dec 22, 2010 at 12:16 PM, Scott Burson <gyro@...> wrote:
> On Tue, Dec 21, 2010 at 4:19 AM, Leslie P. Polzer <leslie.polzer@...> wrote:
>> We've discussed this in the context of the upcoming Postmodern store
>> and think it's the right thing to do (provided we abstract it properly
>> so it works with multiple stores).
>>
>> But we need to test and think a bit more about it. It'd be great if
>> you could try this approach in parallel for CLSQL.
>
> Okay, I took a shot at it.  [...]
>
> The patch is below.  Basically there's a new generic function
> THREAD-PREPARE-STORE

I don't know if anybody ever tried to use this patch, but I hope not,
because it doesn't work.  I mean, it appears to work at first, but in
the end it turns out not to.

The problem is that it opens new connections and binds
*DEFAULT-DATABASE* on a request basis, but that's too fine-grained.
Widgets hold on to view objects across requests.  There's also the
CLASS-STORE slot of DATA-EDITOR, whose lifetime is longer than a
request.

I now understand that CLSQL-Fluid represents the right solution
strategy.  I considered the approach of associating database
connections with sessions, which I think would also basically work;
the problem, though, is that a busy server could have many thousands
of active sessions (particularly if one cranks up Hunchentoot's
default 30-minute session timeout to something more user-friendly,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anton Vodonosov | 28 Dec 2011 22:34
Picon

cl-cont test DOCUMENTATION-SYMBOL-LOOKUP fails on CLISP

Hello.

I am running cl-cont unit tests on different lisps (between other
often used CL libraries).
Results may be found here: http://common-lisp.net/project/cl-test-grid/pivot_ql-lib_lisp.html
(clicking the ok/fail leads to the test logs with failure details).

From the lisp implementations I've tried so far it fails on CLISP:

Test CL-CONT-TEST::DOCUMENTATION-SYMBOL-LOOKUP failed
Form:
(PROGN (FMAKUNBOUND 'CL-CONT-TEST::DOC-TEST-FUN) (CL-CONT:DEFUN/CC CL-
CONT-TEST::DOC-TEST-FUN NIL "foo" T)
 (SETF (DOCUMENTATION 'CL-CONT-TEST::DOC-TEST-FUN 'FUNCTION) "bar")
 (EQUAL (DOCUMENTATION 'CL-CONT-TEST::DOC-TEST-FUN 'FUNCTION) "bar"))
Expected value: T
Actual value: NIL.

Best regards,
- Anton

--

-- 
You received this message because you are subscribed to the Google Groups "weblocks" group.
To post to this group, send email to weblocks@...
To unsubscribe from this group, send email to weblocks+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.
Permalink | Reply | 0 comments |
headers
Willem Rein Oudshoorn | 30 Dec 2011 11:40
Picon
Picon
Favicon

datagrid/dataedit without datastore?

I am playing around with weblocks.  
The standard datagrid/dataedit widget has most of the functionality I
want.  However I am struggling with the datasource side of things.

I would like to give the datagrid an explicit list of items, and the
datastore seems to be getting in my way.

So take the following example,  I have a class 'person and
want to display a list of persons in datagrid.  
I would like to show two (or more) lists of persons, lets say:

1 - Friends
2 - Enemies

Now as far as I can tell I can configure the datagrid
with 

 :data-class 'person

However this will show all persons in a datagrid.  

Does anybody have an idea or pointers how to approach this?

I can think of one way to do this, but that seems cumbersome:

- For each instance of the datagrid make a specific datastore
- Carefully manage each datastore to have the right instances.

So is there a better/easier way?
Oh note, I am not (at the moment :-)) interested
(Continue reading)

Permalink | Reply | 2 comments |

Gmane