edit list in data view

[Evan Monroig]

Hi,

I have an object that has a list of strings as one of its slots. How
difficult would it be to alter the grid widget to make it possible to
have a variable number of text edit boxes to edit each of the
strings ?

I don't know the internals of the gridedit widgets but my first
thought is that it should not be possible as it is now. Should I try
it anyway or does it make more sense to have each string wrapped in a
class (I already need to associate a tag with each string so it would
make sense for my application) and edit each string separately?

You might want to see some code: this is what I have now (no editing
yet). I am making a gallery in french/english/japanese and this is
intended to be for multilingual description / comments on the photos
(it is not for translation of the UI).

(defmodel mlstring ()
((id :accessor mlstring-id
:documentation "id for storage in database")
(strings :accessor mlstring-strings
:initform nil
:initarg :strings
:type list
:documentation "property list where for each element the
cdr is the two-letter code for the language used, and the
car is the value of the string in this language"))
(:documentation "this is a multilingual string, to be used for cases
where some text can be displayed in several languages and we wish to
display the one that is most appropriate for the user"))

(defmethod render-widget-body ((obj mlstring) &rest args)
(declare (ignore args))
(render-widget-body
(cdr (assoc "en" (mlstring-strings obj) :test #'string=))))

(defmethod print-view-field-value ((value mlstring) presentation field
view widget obj &rest args)
(declare (ignore presentation field view widget obj args))
(or (cdr (assoc "en" (mlstring-strings value) :test #'string=)) ""))


Thanks in advance,

Evan

[brian]

This might help to get you started.

(defclass list-presentation (text-presentation input-presentation)
((item-presentation
:initform (make-instance 'text-presentation)
:initarg :item-presentation
:reader item-presentation))
(:documentation "Presents a list of things."))

(defmethod render-view-field-value (value (presentation list-
presentation) field view widget obj &rest args)
(declare (ignore args))
(with-html
(:ol
(dolist (item value)
(with-html
(:li (apply #'render-view-field-value item (item-
presentation presentation) field view widget obj args)))))))

Now, (xxx :present-as (list :item-presentation (make-instance 'input-
presentation))) for a form-view should render the elements of your
list as input fields, which will let you edit them. You'll need to
handle the submitted fields to rebuild the list, and there's no
provision for adding new elements or deleting them or changing the
order of elements, etc.

To be honest, this approach needs a fair amount of work (and probably
javascript) -- perhaps you'd be better off editing the list as a
string, and then writing a parser to turn the returned string into a
list of strings?

That would also work for associative lists, whereas the above would
need something to present the pairs - maybe a definition list would
do ...

[Benjamin Collins]

On Feb 29, 10:46 am, brian <brian.spilsb...@gmail.com> wrote:
> To be honest, this approach needs a fair amount of work (and probably
> javascript) -- perhaps you'd be better off editing the list as a
> string, and then writing a parser to turn the returned string into a
> list of strings?
>
> That would also work for associative lists, whereas the above would
> need something to present the pairs - maybe a definition list would
> do ...

I think this would make really, really great fodder for a weblocks
tutorial. I've been trying to get views and presentations for lists
working for a couple of weeks (by the calendar - not that much real
time, actually. Several hours) without much success.

As I see it, any non-trivial application would have to end up defining
a ton of views and presentations and all the associated rendering
utility functions to do anything other than list data on the screen in
a table. Non-trivial applications would also probably have to create
a bunch of new widgets. I think it would be extremely helpful if
someone could go through all this for cl:list, thoroughly documenting
each step (a screencast like on lispcast would be awesome). As it is,
for an application writer who's not already terribly proficient with
lisp and is new to Weblocks (read, "me"), such a tutorial would be
tremendously helpful in myriad ways. I'd like to see a 'list-view, a
'list-presentation', and possibly a 'list-edit widget.

I will continue struggling on, and if I happen to have some light-
bulbs go off before someone else publishes anything, I'll try to take
up my own suggestion. Do any of you folks frequent freenode #lisp? I
sure wouldn't mind working with other people on this...

[Evan Monroig]

I see.. maybe a widget would be better if we want to add new elements
and put several fields for each element of the list.

Thanks !

Evan

[brian]

> I see.. maybe a widget would be better if we want to add new elements
> and put several fields for each element of the list.

I think that trying to do this as a widget is going to be problematic
for this use.
We need to get the fields into the same form as the containing view,
unless you want to edit the list separately.

Regards,
Brian

[Evan Monroig]

Yes, that's what I was thinking about, editing the list separately.

Evan

[brian]

Ok, I've made some basic list-presentation and list-parser code which
allows you to edit lists as text.
It needs some more revision to handle sub-presentations and delimiters
properly, so I'll try to post it tomorrow or the day after.

I've also added some javascript code which allows you to edit the list
by individual fields, rearrange with drag and drop, and dynamically
shrink and grow the list.

I have a couple of issues though:
* I need to add javascript for this -- should I make a new .js file or
is there a sensible way to do this?
* I also need to be able to generate empty fields for use as
templates.
* We currently have no meaningful way to do this that I know of.
Using NIL for this purpose is probably not a great solution -- how
can we specify that a field is essentially 'unbound'?

PS: The javascript works by helping the user generate the text in the
browser in a hidden field, as for the above case.

Regards,
Brian.

[Vyacheslav Akhmechet]

On 3/3/08, brian <brian.s...@gmail.com> wrote:
> I have a couple of issues though:
> * I need to add javascript for this -- should I make a new .js file or
> is there a sensible way to do this?

You can probably add a new js file. Eventually there will be
functionality to automatically generate bundles, so adding a separate
file won't affect download times.

> * We currently have no meaningful way to do this that I know of.
> Using NIL for this purpose is probably not a great solution -- how
> can we specify that a field is essentially 'unbound'?

I think that currently if a field corresponds to a class slot that
isn't bound, the reader returns NIL. Generally Weblocks uses NIL like
that because when I started writing it I didn't fully understand the
difference between the concept of bound/unbound variables and
variables bound to NIL. This is definitely not the best way to handle
the idea that a field may have no value (we want unbound here, rather
than NIL), but it's the way it works now.

[Vyacheslav Akhmechet]

On 3/1/08, Benjamin Collins <aggi...@gmail.com> wrote:
> (a screencast like on lispcast would be awesome)

I wanted to make a screencast for a while. Writing a Weblocks
application effectively *is* definining widgets. I'm hoping to get to
do this when I find a reasonably large chunk of time (perhaps during
the spring break).

I've been swamped by schoolwork, and I also wrote some code to play
with the Netflix challenge. Once you figure out how to get the data
into Lisp, the challenge becomes extremely addicting (since you can
code up functions that get all kinds of interesting stats out of the
data). I'll be doing some more weblocks work soon.

[Evan Monroig]

On Tue, Mar 4, 2008 at 2:15 AM, Vyacheslav Akhmechet
<coff...@gmail.com> wrote:
> > * We currently have no meaningful way to do this that I know of.
> > Using NIL for this purpose is probably not a great solution -- how
> > can we specify that a field is essentially 'unbound'?
> I think that currently if a field corresponds to a class slot that
> isn't bound, the reader returns NIL. Generally Weblocks uses NIL like
> that because when I started writing it I didn't fully understand the
> difference between the concept of bound/unbound variables and
> variables bound to NIL. This is definitely not the best way to handle
> the idea that a field may have no value (we want unbound here, rather
> than NIL), but it's the way it works now.

When a slot is unbound (i.e., has no :initform and was not initialized
by make-instance or not set by setf or a slot writer), you get an
error when you try to access it. You can check whether a slot is
bound with the function slot-boundp.

I'm not sure whether unbound slots play nicely with the prevalence
though. But it certainly would be more natural to use them to say
that the data was not set :).

Evan

[brian]

> I think that currently if a field corresponds to a class slot that
> isn't bound, the reader returns NIL. Generally Weblocks uses NIL like
> that because when I started writing it I didn't fully understand the
> difference between the concept of bound/unbound variables and
> variables bound to NIL. This is definitely not the best way to handle
> the idea that a field may have no value (we want unbound here, rather
> than NIL), but it's the way it works now.

How about (values nil t) for unbound?
Would need a flag at the rendering level, too, though.

[Vyacheslav Akhmechet]

On Mon, Mar 3, 2008 at 7:26 PM, brian <brian.s...@gmail.com> wrote:
> How about (values nil t) for unbound?

Hmm, I don't know if I like that. If one spends the time updating the
code to handle this, might as well do it properly and use
slot-boundp...