About modifying an input field...

[Rafael]

Hi all:

I have to issues in a simple virtual mail user and alias management
application that I'm developing.

1. I had to build a new input-presentation class to allow me to make
read-only or disable an input field. I've seen a thread here about
that issue and I've followed the solution by Leslie (http://
groups.google.com/group/weblocks/msg/d63f9bf794ada2ec) so I made a new
class called enhanced-input-presentation and a specialized method
render-view-field-value for that class. I've to say that it have been
easy to do (thanks to Leslie). My next problem is that I need this to
make an input field disabled when modifying and enabled when adding.
I'm using a gridedit widget and a scaffolded form-view for editing.

2. I have created a new store for managing the virtual mail user and
alias database. But I did not found an example about where I should
call commit-transaction. I need that for commiting changes to the mail
services (postfix, saslauthd, courier-authd), maybe on-delete-items-
completed and on-add-item-completed?

BTW, thanks to all the people involved in this great project.

Greets and thanks in advance.

[nunb]

Post code if you have it (paste.lisp.org).

If you are using a gridedit, one (best?) solution is to have different
forms (and different views) in the dataedit-create-widget and dataedit-
add-widget (dunno what the exact fn. names are) functions. One of the
views can have the disabled presentation for the relevant field, and
the other the regular one.

IOW

(defview common-view (:scaffold foo-class))
(defview modify-view (:inherit-from 'common-view)
(email (:present-as (disabled-input :args 1))))
(defview newitem-view (:inherit-from 'common-view))


Of course, in the pseudo-code above newitem-view is not really
necessary.

[nunb]

The relevant functions seem to be dataedit-create-drilldown-widget and
dataedit-create-new-item-widget (caveat: I use 0.8.2, but I don't
think the functions have changed).

Also, I recommend that you always subclass gridedit so you can more
easily customize its behavior, I pasted the code I use at
http://paste.lisp.org/+1YBE

[Leslie P. Polzer]

Hi Rafael,

On Nov 25, 10:20 pm, Rafael <wheelkil...@gmail.com> wrote:

> 1. I had to build a new input-presentation class to allow me to make
> read-only or disable an input field. I've seen a thread here about
> that issue and I've followed the solution by Leslie (http://
> groups.google.com/group/weblocks/msg/d63f9bf794ada2ec) so I made a new
> class called enhanced-input-presentation and a specialized method
> render-view-field-value for that class. I've to say that it have been
> easy to do (thanks to Leslie). My next problem is that I need this to
> make an input field disabled when modifying and enabled when adding.
> I'm using a gridedit widget and a scaffolded form-view for editing.

One way to do this is to have a base view where the field is enabled
and a child view where it is not.

Then specialize the appropriate methods for your grid
(dataedit-create-new-item-widget and friends) to choose the correct
view.

> 2. I have created a new store for managing the virtual mail user and
> alias database. But I did not found an example about where I should
> call commit-transaction. I need that for commiting changes to the mail
> services (postfix, saslauthd, courier-authd), maybe on-delete-items-
> completed and on-add-item-completed?

Could you post your store somewhere?

The standard way used to commit changes is persist-object which gets
called after every successful form submit, so your store will have to
specialize it properly.

> BTW, thanks to all the people involved in this great project.

You're welcome! Please continue asking if the above isn't clear
enough.

Leslie

[Rafael]

First of all, many thanks to nunb and Leslie for the fast response.

On 26 nov, 12:40, "Leslie P. Polzer" <leslie.pol...@gmx.net> wrote:
> Hi Rafael,
>
> On Nov 25, 10:20 pm, Rafael <wheelkil...@gmail.com> wrote:
>
> One way to do this is to have a base view where the field is enabled
> and a child view where it is not.
>
> Then specialize the appropriate methods for your grid
> (dataedit-create-new-item-widget and friends) to choose the correct
> view.
>

Perfect, both of you have said the same response so it must be true :)
I'll try that.
This is the link (http://paste.lisp.org/+1YBI) for the widget code.

> > 2. I have created a new store for managing the virtual mail user and
> > alias database. But I did not found an example about where I should
> > call commit-transaction. I need that for commiting changes to the mail
> > services (postfix, saslauthd, courier-authd), maybe on-delete-items-
> > completed and on-add-item-completed?
>
> Could you post your store somewhere?
>

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

> The standard way used to commit changes is persist-object which gets
> called after every successful form submit, so your store will have to
> specialize it properly.
>

I've done that and it runs fine, but it would be better if I could
group many mailbox deletions because notifying the underlying services
takes a bit of time.

Many thanks again.

[Leslie P. Polzer]

On Nov 26, 2:02 pm, Rafael <wheelkil...@gmail.com> wrote:

> I've done that and it runs fine, but it would be better if I could
> group many mailbox deletions because notifying the underlying services
> takes a bit of time.

That's simple. Maintain a queue in persist-object and call the real
writer
once you have N objects in the queue. Use CL-STORE to have a fail-safe
queue.

Leslie

[Leslie P. Polzer]

On Nov 26, 5:35 pm, "Leslie P. Polzer" <leslie.pol...@gmx.net> wrote:
> call the real writer once you have N objects in the queue.

Or whenever your application code decides it wants to "commit"
the queue.

[Rafael]

The only thing that could be queued are the deletions because they can
be removed a bunch at a time (additions and modifications of mailboxes
and aliases are done one at a time and must be committed
instantaneously), so I think that I have two options, or I commit
every X seconds or I use :on-delete-items-completed to commit...

Anyway, I have bookmarked cl-store :)

Thanks.

[Nandan]

Could you please annotate http://paste.lisp.org/display/91134 with the
on-drilldown/on-add-item methods you created so that when a similar
question pops up, we can just point to the paste/this thread?

[Rafael]

On 28 nov, 13:08, Nandan <nandan.bagc...@gmail.com> wrote:
> Could you please annotatehttp://paste.lisp.org/display/91134with the

> on-drilldown/on-add-item methods you created so that when a similar
> question pops up, we can just point to the paste/this thread?

Yes, I've done. As nunb has suggested, I have made a new class that
inherits from gridedit, and then I've specialized the methods dataedit-
create-drilldown-widget and dataedit-create-new-item-widget. I don't
know if the implemented methods do their job in the proper way but
they run fine.

I also have annotated the paste with the class enhanced-input-
presentation that supports disable-p and read-only-p. By the way, I've
had to use 'read-only' instead 'disabled' because the last is not sent
with the form data, so when weblocks receives the form data I suppose
that it interprets that input field has no value (which is true :).

Greets.

[Leslie P. Polzer]

Rafael,

thanks for posting your gridedit customizations.

This is a common pattern when developing with Weblocks.

We should start to collect recipes like this.

Leslie

[Rafael]

> This is a common pattern when developing with Weblocks.
>
> We should start to collect recipes like this.
>

Amen.

[Rafael]

> This is a common pattern when developing with Weblocks.
>
> We should start to collect recipes like this.
>

Amen.