Postmodern Store

[Harag]

I hacked a post modern store tonight. I need to just finish unit
testing.

What are the steps to get weblocks to see/know about it?

[Leslie P. Polzer]

You need to put your store into src/stores/YOUR-STORE and write an
ASDF file for it.

[Phil Marneweck]

Thanx will do so and let you know how it went.

[Phil Marneweck]

Ok the store is finished and passes all my unit tests.

I am having problems getting weblocks to work. I just get a blank page
if I follow the "Breaking the Ice" instructions on the
http://trac.common-lisp.net/cl-weblocks/wiki/UserManual
page.

I thought I saw a FAQ some where on the web about what to do when you
have trouble but I cant find anything like that tonight.

Any pointers in the right direction would be appreciated.

Regards
Phil

[Phil Marneweck]

Well I got things up and running and I am testing my postmodern-store. I
The store is being use slightly differently from what I expected but I
am working through those issues.

[Leslie P. Polzer]

On Oct 27, 12:16 am, Phil Marneweck <zar...@global.co.za> wrote:
> Well I got things up and running and I am testing my postmodern-store. I
> The store is being use slightly differently from what I expected but I
> am working through those issues.

Sorry we've missed each other on IRC. What was the cause of your
problems? Maybe some docs are still outdated?

Leslie

[Phil Marneweck]

Hi

I don't know why I get a blank screen for the default demo (I have not
had time to go hunting it down) , but I get the weblocks default screen.

My store demo was not starting because there was an error in the
defstore statement.

The reason that I could not see any errors at first is as follows:

I wanted to see if weblocks was working so I did
(weblocks:start-weblocks :port 8888 :debug t) ..once I saw that worked I
then I did a
(weblocks-postmodern-demo:start-weblocks-postmodern-demo :port
6767 :debug t) but this just returns NIL (no error or anything else).

It is only after I restarted emacs and did
(weblocks-postmodern-demo:start-weblocks-postmodern-demo :port
6767 :debug t) on its own that I got errors in the debugger.

Can one run more than one weblocks in an instance?

[Leslie P. Polzer]

Phil Marneweck wrote:

> Can one run more than one weblocks in an instance?

No, but you can run multiple applications (i.e. what you get when
you run DEFWEBAPP) on one Weblocks instance, each with their own
hostname, port and URI prefix.

I think you need to run ENABLE-WEBAPP or something if you define
a webapp after the Weblocks server has been started. Or not, I'd
have to look it up. See also the :AUTOSTART argument to DEFWEBAPP.

Leslie

[Phil Marneweck]

Thanx will look it up.

[Phil Marneweck]

Hi

I hacked the clsql store demo to work with postmodern. I get data in the
grid. But I cant update the data, it looks like the submit button is not
firing. I tried to put breaks in all the places that I thought might
catch the event but I get nothing.

Is there a way to confirm that the button is not firing?

What would be the best way to go about debugging weblocks in general?

Regards
Phil

[Leslie P. Polzer]

Phil Marneweck wrote:

> I hacked the clsql store demo to work with postmodern. I get data in the
> grid. But I cant update the data, it looks like the submit button is not
> firing. I tried to put breaks in all the places that I thought might
> catch the event but I get nothing.
>
> Is there a way to confirm that the button is not firing?

You can trace handle-client-request to make sure it gets to the server.

> What would be the best way to go about debugging weblocks in general?

I have found tracing on the server side in combination with Firebug on the
client side to be an effective approach.

Leslie

[Phil Marneweck]

Thanx I finally found the "black hole" in my own code.

[Phil Marneweck]

Hi

I have a design question.

If you look at the clsql store demo there is a view for the employee
that includes the address and company. They achieve this because there
class has joins defined in it.

I dont have this type of join facility in postmodern's dao object. So I
created a view to display the data in the grid. I also made the edit
view only look at the employee table and not the employee-view. However
if I submit a new emplyee weblocks still thinks it should update the
employee-view (i think because of :data-class slot).

The question I have is how should I handle this in weblocks? Is there a
simple way to do this without rolling a postmodern specific grid
widget?

Or am I missing something?

Regards
Phil

[Phil Marneweck]

I think I have a solution.

I had a look at the elephant store and then realized that the address
and company can be classes on there own. something that escaped me
previously.

Hopefully it will not be to hair raising to loop throught the slots to
figure out which ones are indeed classes that need to be updated as well
or something in that line. (Updating the required foreign keys might be
only biggest issue.)

I have asked on the postmodern mailing list about something like that
and hopefully they can give me some pointers.

Any advise from this group would also be appreciated.

Once this is done the postmodern store is done. I will let he people on
the postmodern list have a look at the source before I pass it onto this
group.

[Leslie P. Polzer]

On Nov 6, 6:44 pm, Phil Marneweck <zar...@global.co.za> wrote:
> I think I have a solution.
>
> I had a look at the elephant store and then realized that the address
> and company can be classes on there own. something that escaped me
> previously.
>
> Hopefully it will not be to hair raising to loop throught the slots to
> figure out which ones are indeed classes that need to be updated as well
> or something in that line. (Updating the required foreign keys might be
> only biggest issue.)

The nice thing about Postmodern is that it's quite flexible and you
can
hook into the dao DWIM very well.

> Once this is done the postmodern store is done. I will let he
people on
> the postmodern list have a look at the source before I pass it onto this
> group.

Thank you for this effort, I'm excited about it!

Leslie

[Phil Marneweck]

obtain-view-field-value in dataedit-delete-item is returning a empty
object for the mixin class ...any ideas why this would be?

Background info:

-Using the postmodern store and posmodern demo app:

-The data view displays the mixing values correctly.

-The values are displaid correctly in the edit view.

-I can persist companies and employees with its mixin objects.

-Delete of company works fine.

-Delete of employee does not work because delete-persistent-object is
passed a "blank" object becuase obtain-view-field-value returns a blank
object as far as I can see.

[Phil Marneweck]

Well never mind. I dont know what I did but it started working some
where along the line...

And that ladies and gentleman completest eh posmodern store.

[Phil Marneweck]

Ok a real newbie question:

In the following code I get the intial screen which takes me to the
login screen fine. The login screen fires the on-success function and
that function completes successfully but does not replace the the login
widget. What am I doing wrong??

;; Define callback function to initialize new sessions
(defun init-user-session (comp)
(with-flow comp
(yield #'initial-page)
(setf (widget-prefix-fn comp) #'render-header)
(yield (make-instance 'login
:on-login #'authenticate-user
:on-success #'layout-main-page
))))

(defun make-main-page ()
"Lays out the main page. It consists of a FLASH widget for showing
initial message, and a NAVIGATION widget with panes that hold
employees page and companies page."
(make-instance 'composite :widgets
(list
(make-instance 'flash :messages
(list "Welcome to weblocks demo - a
technology demonstration for a
continuations-based web
framework written in Common
Lisp."))
(make-navigation 'main-menu
'employees (make-employees-page)
'companies (make-companies-page)))))

[Phil Marneweck]

Sorry for the repost but I only now saw I did not change the subject!

[nunb]

>
> In the following code I get the intial screen which takes me to the
> login screen fine. The login screen fires the on-success function and
> that function completes successfully but does not replace the the login
> widget. What am I doing wrong??

Do you need a (yield (make-main-page)) as the last item in the flow?

[Phil Marneweck]

Just an update on the weblocks-postmodern store. It now has a home at
http://bitbucket.org/harag/weblocks-dev/wiki/Home.

This is a fork of the weblocks-dev repository while it is still under
heavy development. If you clone this repository you will have what you
need to run weblocks(not its dependencies) and the postmodern store.

There is a demo of the postmodern store under the examples directory.

[Phil Marneweck]

How do I do a read only input box in a form view. I assume you need to
do a present-as like in the following code.

(defview employee-element-form-view (:type form :inherit-from
'(:scaffold employee-element))
(^id :hidep t)
(company-name :present-as (..what must go here for readonly..)
(start-date :reader (compose #'format-date #'start-date))
(end-date :reader (compose #'format-date #'end-date))
)

[Leslie P. Polzer]

There's no support for this right now but it's very easy to
implement.

Just add a READ-ONLY slot to class FORM-PRESENTATION and make
the implementations of RENDER-VIEW-FIELD-VALUE honor it by
adding the "disabled" attribute. After this you'll be able
to write

(field :present-as foo :read-only t)

in your view declaration.

For plain text input fields all of this can be done in formview.lisp.
The class for text fields is misnamed^Wcalled INPUT-PRESENTATION.

Leslie

[Phil Marneweck]

Hi

Thanx Leslie, I had a look at the presentation classes but could not
decide whether I should create a new presentation like for hidden and
text or just try to hack the current input-presentation. I will have a
look at hacking the input-presentation now. I am no HTML expert but is
there not a difference between disabled and readonly?

[Phil Marneweck]

I am trying to use weblocks for a payroll application but I am
frustrated by the lack of features that I would expect for some of the
widgets.

I know it is supposed to be simple to whip up your own widgets and go on
with life but I have this nagging feeling that this would be
re-inventing the wheel.

What I propose is that we create a list of most often requested features
(simple stuff) for exiting widgets, stuff like the readonly for input
boxes etc.

Once we have a list like that agreed on we can ask for contributions
from people that have handled these scenarios in there own code already.

The more knowledgable weblocks hackers could maybe review the list of
contributions and make suggestions or comments that would be needed to
accept it into the dev tree.

We can then all contribute to getting these features cleaned up to go
into the dev.

I feel this way we can make a structured effort to improving the out of
the box usability of weblocks a lot.

What do you think? Is this a good idea?

[Ray Servers]

I'm busy re-inventing or re-hacking some of these wheels. I hope to get to a
point by this weekend to have something that can be called a project to post,
built with Weblocs and GBBopen.

Cheers,

---Venkat.

[nunb]

This is what I use right now, as you can see it's pretty basic. I had
to write a bunch of these and didn't give them much thought, I just
dumped them all in a single file. When I find I need some html-
attribute, I just add it to this fn. No tests were bothered in the
making of these input-presentations! (but look in the contrib dir for
a bunch of other ideas).

http://paste.lisp.org/+1XON

> frustrated by the lack of features that I would expect for some of the
> widgets.

Which widgets in particular? (the rest of your post is about
presentations, afaik).

> I know it is supposed to be simple to whip up your own widgets and go on
> with life but I have this nagging feeling that this would be
> re-inventing the wheel.

Moving from relying on the forms mechanism to writing (lots) of
widgets helped our development effort a lot, so I highly recommend it.

> I feel this way we can make a structured effort to improving the out of
> the box usability of weblocks a lot.
>
> What do you think? Is this a good idea?

Absolutely. A wiki is a good idea imho to collect the weblocks
knowledge that's extant.

[Leslie P. Polzer]

On Nov 13, 4:51 pm, nunb <nandan.bagc...@gmail.com> wrote:

> > What do you think? Is this a good idea?
>
> Absolutely. A wiki is a good idea imho to collect the weblocks
> knowledge that's extant.

I concur.

Go forth and contribute: http://bitbucket.org/S11001001/weblocks-dev/wiki/Home

[Leslie P. Polzer]

On Nov 13, 4:51 pm, nunb <nandan.bagc...@gmail.com> wrote:

> This is what I use right now, as you can see it's pretty basic. I had
> to write a bunch of these and didn't give them much thought, I just
> dumped them all in a single file. When I find I need some html-
> attribute, I just add it to this fn. No tests were bothered in the
> making of these input-presentations! (but look in the contrib dir for
> a bunch of other ideas).
>
> http://paste.lisp.org/+1XON

Looks like a keeper. Anyone willing to do the trivial review against
the current code?

[Rayservers]

Heh, you beat me to a wiki... I've just installed Tiki 4.

https://freedom.rayservers.com/

Tiki4 seems to have everything... perhaps we will have something like that in
Weblocks some day.

I've created a category Weblocks. Forums, Blogs, Wikis etc are supported.

The idea of installing this is for multiple projects that improve freedom...
freedom to code in Weblocks/Lisp.

Also, I'm not sure if this list is appropriate for a discussion of the Weblocks
application I am working on... I guess in the early days there will be a bunch
of posts. The name for the project is "Globalisles.net"... a network framework
for web applications in the hostile Web 3.0 environment I expect to see
worldwide. The leaked bill in the US Congress on ISPs enforcing copyright is
scary, idiotic and will encourage projects like the one I am contemplating.

Cheers,

---Venkat.

[nunb]

> Looks like a keeper. Anyone willing to do the trivial review against
> the current code?

I believe Marneweck is going to merge his code and submit it for
inclusion.

[Phil Marneweck]

I have time today to integrate nunb's code into the
render-view-field-value today.

What other attributes would be usefull to implement?

Here is a complete list of attributes but I dont think all of them make
sense in render-view-field-value.

http://www.w3schools.com/TAGS/tag_input.asp

[nunb]

> I have time today to integrate nunb's code into the
> render-view-field-value today.

> What other attributes would be usefull to implement?

I have found that having a style attribute is invaluable, as users get
discombobulated by the slightest 1px difference in spacing, and rather
than fix it in a CSS file, it is quicker, and *much* more reliable to
fix it at the input text site.

> Here is a complete list of attributes but I dont think all of them make
> sense in render-view-field-value.

Saikat posted some work with :onchange a while back, even though forms/
views would need to be reworked to specify in-form dynamism (onblur/
onchange affecting other fields, for example) I feel it is at least
worthwhile to put some of these options in render-input (html-
utils.lisp) if not in render-v-f-v for the form-input-presentation.

Also, this is a good test of your original "Call for widgets"
proposal: since we cannot obviously fit in *all* options, which
options do we select and make available? After all it is trivial to
rewrite render-input ..

IMHO the stuff in html-utils (render-checkbox, render-input, render-
dropdown etc) should support almost all W3C tag attributes, and render-
v-f-v/presentations should support the common use-cases, with
specialized presentations for special needs.

[Leslie P. Polzer]

On Dec 1, 9:58 am, nunb <nandan.bagc...@gmail.com> wrote:

> IMHO the stuff in html-utils (render-checkbox, render-input, render-
> dropdown etc) should support almost all W3C tag attributes, and render-
> v-f-v/presentations should support the common use-cases, with
> specialized presentations for special needs.

That's a good approach.

[Phil Marneweck]

What would the common use-cases be?

> --
>
> You received this message because you are subscribed to the Google Groups "weblocks" group.
> To post to this group, send email to webl...@googlegroups.com.
> To unsubscribe from this group, send email to weblocks+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.
>
>

[Leslie P. Polzer]

Phil Marneweck wrote:
> What would the common use-cases be?

I suppose only experience can tell that.

You and nunb should probably discuss it.