WATask, or almost.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

WATask, or almost.

Esteban A. Maringolo
Hello,

I have doubts about whether to use a task or not.

The "use case" is the following, the user first selects the
"parameters", once the parameters are selected, it goes to the next
step, and does whatever, using such parameters.

That would be simple using a task:
MyTask>>#go
  parameters := self call: (FooParametersComponent new). "answer aFooParameters"
  self call: (FooEditComponent using: parameters)

But I'm wondering how to handle the situation if the user wants to "go
back" to change the parameters and then again, always working over the
same FooParameters instance.

What would be the best way to do it?

Regards,

--
Esteban A. Maringolo
[hidden email]
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: WATask, or almost.

Sebastian Sastre-2
Hi Esteban,

        what about making aFooParameters to be the model of the task? If you
instantiate it outside the task (before it exists) then you can pass it as
model ala seting a model in Dolphin?. No matter how many components are
created to edit that model it is allways the same.

        I do this all the time.

        cheers,

Sebastian Sastre


 

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de Esteban A. Maringolo
> Enviado el: Viernes, 08 de Febrero de 2008 16:15
> Para: Seaside - general discussion
> Asunto: [Seaside] WATask, or almost.
>
> Hello,
>
> I have doubts about whether to use a task or not.
>
> The "use case" is the following, the user first selects the
> "parameters", once the parameters are selected, it goes to
> the next step, and does whatever, using such parameters.
>
> That would be simple using a task:
> MyTask>>#go
>   parameters := self call: (FooParametersComponent new).
> "answer aFooParameters"
>   self call: (FooEditComponent using: parameters)
>
> But I'm wondering how to handle the situation if the user
> wants to "go back" to change the parameters and then again,
> always working over the same FooParameters instance.
>
> What would be the best way to do it?
>
> Regards,
>
> --
> Esteban A. Maringolo
> [hidden email]
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: WATask, or almost.

Esteban A. Maringolo
Hello Sebas,

On Feb 8, 2008 3:28 PM, Sebastian Sastre <[hidden email]> wrote:
> Hi Esteban,
>
>         what about making aFooParameters to be the model of the task? If you
> instantiate it outside the task (before it exists) then you can pass it as
> model ala seting a model in Dolphin?. No matter how many components are
> created to edit that model it is allways the same.

Well, but perhaps I'm thinking it wrong, but what I want is some sort
of "going backward" in the task.

In this case this is simple, but what if I have several steps?

And the model has to be valid only in this lifecycle, once the task is
done, it must be discarded.

Saludos.


--
Esteban A. Maringolo
[hidden email]
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: WATask, or almost.

Sebastian Sastre-2

>
> Well, but perhaps I'm thinking it wrong, but what I want is
> some sort of "going backward" in the task.
>
> In this case this is simple, but what if I have several steps?
>
> And the model has to be valid only in this lifecycle, once
> the task is done, it must be discarded.
>

I think Continuations should take care of that for you. That is if you are
going backwards with the back button. No matter how much steps back you need
to go back, there is a continuation with the state (unless a transaction is
in the usage path).

If you want to go backwards as a function from other than the user agent's
back button, then I think you can use the continuation solution anyway by
figuring out a way your application to press it internally for him.

Did I understand right your request?

        saludetes,

Sebastian

> Saludos.
>
>
> --
> Esteban A. Maringolo
> [hidden email]
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside