On Mar 11, 9:52 am, Jose San Leandro <[email protected]>
wrote:
> First of all, congratulations for weblocks. I've spent most of the
> last 10 years building server-side applications in Java. Once in a
> while, I read Paul Graham's essays and books, and got interested in
> Lisp. I started with the most available environment to me: emacs lisp.
> I like the ideas proposed by weblocks. For me, it's a major step
> forward.
I came from building web apps mostly in PHP also by way of PG,
and it was a huge step forward. :)
> Sorry for the preamble. I've just started to work with weblocks. I had
> some problems installing sbcl and such,
Yes, it's not that easy to get started.
> but I'm confident that would become clearer to me once I have more experience
> developing in Lisp in general.
You can be sure of that.
> I took a look at the tutorials and all online resources I've been able
> to find. My first question is: Is there any kind of javadoc-like
> approach for common-lisp? I'd like to know about what each of the pre-
> existing widgets do and how to use them. I installed a tool called
> 'atdoc' but I haven't invested time in it yet.
There are several tools to generate automated API documentation.
Tinaa is popular, but it's currently broken in some ways,
unfortunately.
I have a user guide for Weblocks in preparation but it will still take
me
some time to get something substantial together, unfortunately.
Your best bet at this time would be either generating API docs
yourself
from the source using a tool of your choosing (probably not Tinaa in
fact)
and/or read the source and docs directly.
At the beginning it also helps to work with the examples, as you have
already
noticed.
> Besides that, I started my application using simple-blog as template.
> I'm a little embarrassed to ask this, but I don't know where the list
> of users and posts are stored.
No need to get embarassed at all. It's not very easy to get started
and going, although we're working on improving this situation.
It will sometimes take a lot of patience and effort to work through
a basic understanding of CL and Weblocks, but it pays off after
some time.
> I mean, the following code
>
> (defun make-users-gridedit ()
> (make-instance 'gridedit
> :name 'users-grid
> :data-class 'user
> :view 'user-table-view
> :widget-prefix-fn (lambda (&rest args)
> (declare (ignore args))
> (with-html (:h1 "Users")))
> :item-data-view 'user-data-view
> :item-form-view 'user-form-view))
>
> prints the already existing users, but I don't know where such
> information is stored. My best guess is that the :data-class 'user is
> tied somehow to the persistence layer, and just reads the entries in
> the associated table/store.
Yes, that's correct.
> Is it also stored in hunchentoot:*session* somewhere?
No, not as such. But the simple-blog example might keep around the
user
object as a session value.
> Another important question to me: Are there any built-in log
> mechanism? where and how do I write and read the logs? I started my
> application with :debug t and still I see no difference.
Are you using weblocks-dev or weblocks-stable? Are you talking
about log messages in general or error messages/backtraces?
> One more thing. I hope I'm not declaring myself so stupid you've just
> stopped reading :).
Hey, at least you don't ask any *hard* questions where I need to
think. ;)
> When I try to stop my application, or reset the
> sessions, I get an error saying hunchentoot:*acceptor* is not bound.
> I'm using the latest version of weblocks. I let it go on and seems to
> work, though.
Yes, it's a minor bug that doesn't do much harm. I just submitted a
fix
to weblocks-dev.
I've also noticed that HUNCHENTOOT:STOP (called from
WEBLOCKS:STOP-SERVER after RESET-SESSIONS) seems to hang,
but I suppose we can't do that much about it right now.
It looks like a Hunchentoot/Usocket problem to me.
Cheers,
Leslie
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"weblocks" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/weblocks?hl=en
-~----------~----~----~----~------~----~------~--~---
