[Kss-devel] plone.app.kss sprint after the Plone Conference in Naples (13-14-15 October)

[Massimo Azzolini]

hi balatz,

I thought about your scenario and how it impacts on my previous ideas on dnd.

On 9/13/07, Balazs Ree <ree at ree.hu> wrote:
>  As I understand you want to make all (all lots of) elements generally
> draggable, others generally droppable, and build a generic drag-and-drop
> framework on the server side.

not really a generic dnd framework rather a pluggable framework.

> I must mention that in our dnd experiments (which is on a currently
> unpublished branch, to be ported to kss.core 1.4 before or at the
> beginning of the sprint), we do not use such a server side mechanism, and
> we make the dnd mechanism work in the following simple way:
>
> 1. bind the draggables and droppables from kss, using css selection.
>    Binding of draggables and droppables happens grouped: "These goodies
>    can be dropped into these baskets", or "these portlets can be
>    reordered in place". IE, portlets cannot be dropped to baskets and the
>    client side is aware of this.
> 2. the server side is really simple, a single view that gets invoked on
>    drop. All it needs to do is store the change in the content, or
>    raise an exception if something went wrong.
> 3. if you want error handling, the client needs an error handler to
>    revert the drop if the response comes with error.
>
> For a generic application (like shopping cart, or portlets rearrangement)
> when the draggables and droppables are all controlled by the same
> component, there is no need to have more server side logic than this.

right, but if for the copy/move example we need a server logic, we
need to ask to the user if he want to copy or to move, so we need to
draw an area where to put the question. in this case the logic must be
on the server. mustn't it?

that's why I'm thinking about a pluggable system.
If you dont need a server side logic, ok it's done, otherwise.. write
down your own one.

> But if we want to support that a draggable defined by application
> component X (draggable page) can be dropped to a droppable defined by
> application component Y (nav portlet droppable), then such a construct
> may make sense. But still I think that the logic "what can be dropped to
> where" should be controlled by the kss resource and not on the server
> side zcml. And that we can even keep it in kss in these cases, because
> the css selection is so flexible.

again, in the move example, it depends on the user if he can move an
object or not.
imagine a folder with 2 pages.
the first one can be just read by the user
the other one can be both written or read.

i cannot figure out how to describe this in kss, and, if I could, it
have to be expressed dynamically by a function which depends on both
objects and user.

it should be great since a problem we have is that we can start a drag
on whatever draggable object and end it on whatever droppable object,
then do a roundtrip to the server which tell us if we can do
nothing/just copy/copy or move.

> So I would like to ask two things from you:
>
> - you should state the exact usecase you are trying to support. Settle on
> the simplest goal you can think of.

at least the copy/move operation
in addition, could be interesting to use the tagcloud product and drag
a tag to an object (or vice versa) to add a keyword to it.
I have other ideas about the workflow and a simpler interface for
write the comments on status changing, for example. it's not so easy
to express via email.
we could talk about it.


> - I would also be interested in seeing the code, where is it available?
nicola is working at it at home, the last version I have is not up-to-date.
he's going to send me a newer one.

bye

max

PS: obviously, sorry for my english. maybe when we meet in naples I
can explain myself better using a pencil and a paper :D