Master-details

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

Master-details

Alex Baran
Hello Aida comunity!


I struggle with simple situation for which I can not find solution.
Any help is greatly appreciated.
I want a page with two grids. When an element selected in master-grid,
details-grid should update with new values.
So the process can look like:
1. Calculate new values for detail-grid based on selection in master-grid.
2. Redraw master-grid with new values.

The problem is that I can not find a way that allows me to do both
this action as a result of selection.

Your opinions, even very general one, are very welcome.


Alex
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: Master-details

Herbert König
Hi Alex,



AB> The problem is that I can not find a way that allows me to do both
AB> this action as a result of selection.
hackish me has an action method which in the end links to its own
view.  This refreshes the whole page.

actionAddPositionAdd
        ||
        self observee canAddSelectedPosition
                ifTrue: [self observee addValidSelectedPosition.
                                 self redirectToView: #addPosition.
                                ^self] .
        self observee canChangeSelectedPosition
                ifTrue: [self observee changeValidSelectedPosition.
                                  self redirectToView: #addPosition]
                                  "The above refreshes the page"
                ifFalse: [self showError: self observee lastError].

But I believe there are update methods to update only part of the
page. I will need that later, one action method should update only two
of several grids in a page without refreshing the whole page.


AB> Your opinions, even very general one, are very welcome.


Cheers,

Herbert                            mailto:[hidden email]

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: Master-details

Alex Baran
Hi Herbert,

Thank you for help.

2009/4/9 Herbert König <[hidden email]>:

> hackish me has an action method which in the end links to its own
> view.  This refreshes the whole page.
>
> actionAddPositionAdd
>        ||
>        self observee canAddSelectedPosition
>                ifTrue: [self observee addValidSelectedPosition.
>                                 self redirectToView: #addPosition.
>                                ^self] .
>        self observee canChangeSelectedPosition
>                ifTrue: [self observee changeValidSelectedPosition.
>                                  self redirectToView: #addPosition]
>                                  "The above refreshes the page"
>                ifFalse: [self showError: self observee lastError].
>

But how you know which object is selected? Looks like the observer
already know about selected object.

> But I believe there are update methods to update only part of the
> page. I will need that later, one action method should update only two
> of several grids in a page without refreshing the whole page.
>

In my case I need refresh only part of the page. If my understanding
is correct, update methods that refresh only part of the page could be
implemented only with Ajax support, please correct me if I'm wrong.


Thanks,
Alex

>
> AB> Your opinions, even very general one, are very welcome.
>
>
> Cheers,
>
> Herbert                            mailto:[hidden email]
>
> _______________________________________________
> Aida mailing list
> [hidden email]
> http://lists.aidaweb.si/mailman/listinfo/aida
>
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: Master-details

Herbert König
Hi Alex,



AB> But how you know which object is selected? Looks like the observer
AB> already know about selected object.

by using addBlock for the column and then linking back to the view
which displays the component. viewPositionen hands its name to the
component, so the component can link back. Other views use the
component and send their name. BTW I found the nice way to
color a line via rowGreenIfTrue.

So the purpose is to make the selected line green and to update
another part of the view with the selection.

selectedIdFromView does the magic which lets Smalltalk find out what
was clicked in the browser.

In my mail of March 21st to the list I attached a picture of this
view.

BTW I still hope that someone will find a more elegant solution. If
you really need to select a cell (vs my whole row) in your grid you
have to write a lot of code in that style. Maybe then it's time for us
to come up with something better. At least it works as expected. Right
now I'm not annoyed enough by my code to dig deeper into Aida or write
up something more convenient.

AB> In my case I need refresh only part of the page. If my understanding
AB> is correct, update methods that refresh only part of the page could be
AB> implemented only with Ajax support, please correct me if I'm wrong.

I think the same but haven't delved into it.

Hope I didn't forget anything, won't have much internet till tuesday.


Cheers,

Herbert                            mailto:[hidden email]
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

EllingWebTabsApp-displayPositionenComponent.st (1K) Download Attachment
EllingWebTabsApp-viewPositionen.st (1K) Download Attachment
EllingWebTabsApp-selectedIdFromView.st (548 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Master-details

Alex Baran
Hi Herbert,

2009/4/9 Herbert König <[hidden email]>:

> Hi Alex,
>
>
>
> AB> But how you know which object is selected? Looks like the observer
> AB> already know about selected object.
>
> by using addBlock for the column and then linking back to the view
> which displays the component. viewPositionen hands its name to the
> component, so the component can link back. Other views use the
> component and send their name. BTW I found the nice way to
> color a line via rowGreenIfTrue.
>

Thank you for presenting interesting way of solving the problem. I had
learn your trick with encoding id in url and decoding it later in view
method.

> So the purpose is to make the selected line green and to update
> another part of the view with the selection.
>
> selectedIdFromView does the magic which lets Smalltalk find out what
> was clicked in the browser.
>
> In my mail of March 21st to the list I attached a picture of this
> view.
>
> BTW I still hope that someone will find a more elegant solution. If
> you really need to select a cell (vs my whole row) in your grid you
> have to write a lot of code in that style. Maybe then it's time for us
> to come up with something better. At least it works as expected. Right
> now I'm not annoyed enough by my code to dig deeper into Aida or write
> up something more convenient.
>

I have proposal to add some new behavior to Aida that I think can be helpful.
Well, I think that WebElement can have such method:

onClickDo: aBlock andUpdate: aWebElement

onClick is only one example, other events can have similar implementation.
The main idea is to divide action(for which aBlock is responsible) and
element redrawing.

I am curious is that way of handle events is interesting to community?

Update/refresh part is already implemented inside Aida. The question
is how to invoke aBlock. Well, we can store a block at WebElement
"other" dictionary. To find a block later, element ID and event name
are enough. We can encode ID and event name in JavaScript callback. It
seems that we need special kind of processing of such scripts at Aida
side, but I need some explorations at this point.

I am interested to have onClickDo:andUpdate: and similar methods
inside Aida, and I willing to implement it.


Alex
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: Master-details

Herbert König
Hi Alex,

AB> Thank you for presenting interesting way of solving the problem. I had
AB> learn your trick with encoding id in url and decoding it later in view
AB> method.
I learned "Engineering is the art to build what you want from things
you can get." long ago from Jerry Avins on comp.dsp :-))

AB> I have proposal to add some new behavior to Aida that I think can be helpful.
AB> Well, I think that WebElement can have such method:

AB> onClickDo: aBlock andUpdate: aWebElement

Much better, storing some code and invoking it on click actually is
how UI's are usually built. I use the browser as a UI to the
application. This point of view would be reflected even better by:

onClickInvoke: #aMessage sentBy: don'tKnowYetHowToIdentifyWhatWasClicked

AB> onClick is only one example, other events can have similar implementation.
AB> The main idea is to divide action(for which aBlock is responsible) and
AB> element redrawing.

In your proposal I'd like more flexibility in andUpdate: aWebElement.
To stay with your example, you might want to highlight the selection
in the master grid and update your detail grid based on that
selection. Maybe I can't achieve what I want here because I cannot
push arbitrary elements from the server. I will study your examples
from the other mails.

No offense intended but passing a block sounds to me a bit like "I
don't yet know what I want so I provide for maximum flexibility".

Having read further in your mails, you need the block to pass the
parameters I want to pass in my sentBy:... part.

....study and continue.....


AB> I am curious is that way of handle events is interesting to community?

Everything that hides the Web makes me happier :-).

AB> Update/refresh part is already implemented inside Aida. The question
AB> is how to invoke aBlock. Well, we can store a block at WebElement
AB> "other" dictionary. To find a block later, element ID and event name
AB> are enough. We can encode ID and event name in JavaScript callback. It
AB> seems that we need special kind of processing of such scripts at Aida
AB> side, but I need some explorations at this point.

AB> I am interested to have onClickDo:andUpdate: and similar methods
AB> inside Aida, and I willing to implement it.


AB> Alex
AB> _______________________________________________
AB> Aida mailing list
AB> [hidden email]
AB> http://lists.aidaweb.si/mailman/listinfo/aida



Cheers,

Herbert                            mailto:[hidden email]

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: Master-details not ready yet!

Herbert König
Hi ,


sorry, the following escaped my outbox long before I'm willing to send
it. Alex, I have to understand your code first, then change what I
wrote according to that.

Don't waste time on it, maybe tomorrow I sy the opposite.
HK> I learned "Engineering is the art to build what you want from things
HK> you can get." long ago from Jerry Avins on comp.dsp :-))

AB>> I have proposal to add some new behavior to Aida that I think can be helpful.
AB>> Well, I think that WebElement can have such method:

AB>> onClickDo: aBlock andUpdate: aWebElement

HK> Much better, storing some code and invoking it on click actually is
HK> how UI's are usually built. I use the browser as a UI to the
HK> application. This point of view would be reflected even better by:
snippedy snap...



Cheers,

Herbert                            mailto:[hidden email]

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: Master-details not ready yet!

Alex Baran
Hi Herbert,

2009/4/11 Herbert König <[hidden email]>:
> Hi ,
>
>
> sorry, the following escaped my outbox long before I'm willing to send
> it.

It's ok. I think I should describe my choice in more details, and I
had options with MessageSend in my mind too. So I can compare several
variants. But right now, it seems like I produce a lot of words in the
list. Anyway if you find this stuff interesting, please let me now,
and I will describe why I chosen blocks.

> Alex, I have to understand your code first, then change what I
> wrote according to that.
>
> Don't waste time on it, maybe tomorrow I sy the opposite.
> HK> I learned "Engineering is the art to build what you want from things
> HK> you can get." long ago from Jerry Avins on comp.dsp :-))
>
> AB>> I have proposal to add some new behavior to Aida that I think can be helpful.
> AB>> Well, I think that WebElement can have such method:
>
> AB>> onClickDo: aBlock andUpdate: aWebElement
>
> HK> Much better, storing some code and invoking it on click actually is
> HK> how UI's are usually built. I use the browser as a UI to the
> HK> application. This point of view would be reflected even better by:
> snippedy snap...


Alex
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: Master-details not ready yet!

Herbert König
Hi Alex,


AB> It's ok. I think I should describe my choice in more details, and I
AB> had options with MessageSend in my mind too. So I can compare several
AB> variants. But right now, it seems like I produce a lot of words in the
AB> list.

see it like this: we two keep the list busy right now and Nicholas
will be interested in the topic in the near future.

AB> Anyway if you find this stuff interesting, please let me now,
AB> and I will describe why I chosen blocks.

I read the how in the code and will never know the why if you don't
tell me. The why is more interesting.

I've started using your method (only found time on the train) and will
expand it on updating more than one element (which I need). I'm just
slow and quite busy right now.

As an aside, when I first heard about seaside my naive assumption was,
I just take any old GUI app, send it "asSeaside" and I'm done. Turned
out I was wrong :-)) Aida is closer than Seaside (imho) and your
proposal brings us another step closer.



Cheers,

Herbert                            mailto:[hidden email]

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: Master-details not ready yet!

Alex Baran
Herbert, Thank you for interest and nice words!

2009/4/13 Herbert König <[hidden email]>:

> Hi Alex,
>
>
> AB> It's ok. I think I should describe my choice in more details, and I
> AB> had options with MessageSend in my mind too. So I can compare several
> AB> variants. But right now, it seems like I produce a lot of words in the
> AB> list.
>
> see it like this: we two keep the list busy right now and Nicholas
> will be interested in the topic in the near future.
>

If you have any questions or disagrements I will be glad to hear.

> AB> Anyway if you find this stuff interesting, please let me now,
> AB> and I will describe why I chosen blocks.
>
> I read the how in the code and will never know the why if you don't
> tell me. The why is more interesting.

I have plans for tommorow(seems lake too late for today) to get into
such topics:
1. Parameters round-trip. MessageSends. Blocks.
2. Where to store blocks. Global vs local.
3. Why we are not close to desktop GUI yet.

>
> I've started using your method (only found time on the train) and will
> expand it on updating more than one element (which I need). I'm just

I will think about updating several elements. But I think this will be
a different beast. Anyway I will try to form my opinion.

> slow and quite busy right now.
>
> As an aside, when I first heard about seaside my naive assumption was,
> I just take any old GUI app, send it "asSeaside" and I'm done. Turned
> out I was wrong :-)) Aida is closer than Seaside (imho) and

Yes, it looks like mirrages are driving our industry :)

> your proposal brings us another step closer.

With community help I hope it will. Thank you for nice words :)


All the best,
Alex
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: Master-details not ready yet!

Alex Baran
Hi Herbert,

Yesterday's tomorrow is today, and bellow my answer lay (sorry for pun)

1. Parameters round-trip. MessageSends. Blocks.
We have parameters, we send them abroad(to browser) and receive them
back as foreigners(as strings). We do all marshaling and demarshaling
stuff. But why we need such parameters "round trip" if they don't
change their values. Maybe we can tie parameters in one bundle and
send abroad only bundle id. So we can pack bundle with various stuff
and our "send bundle id" method will be unchanged, because the method
does not depend on bundle internals.
Let's look inside a bundle and figure all parts that often apears
inside of a bundle. Here we can find: receiver, action(method),
arguments. Well this stuff can be represented as a MessageSend.
The first problem with MessageSend is that we don't want to allow user
to invoke an arbitrary message(by hand-written url for example). We of
course can use the Aida way of adding prefixes (such as "view"). But
let's look closer at a MessageSend - it's some action with arguments.
But block can do it too, and without any arguments, because a
block(closure) can catch variables from an environment. Actually when
we create a MessageSend we do the same arguments capture by explicitly
passing arguments to a MessageSend constructor. Verbosity is the
second problem of MessageSend approach. But in case of block we don't
need to pass parameters explicitly to closure. And we don't need to
create separate method to handle simple cases, just use block. In case
of complicated case we just invoke method from closure with arguments
implicitly captured by closure. With closure user not allowed to use
arbitrary message, only registered closures can be reached, so no need
in such guards like suffixes.

2. Where to store blocks. Global vs local.
Components born and die, and blocks have their lifespan too. We can
have global registry of all blocks. But when to purge a registry from
unused blocks? Blocks supposed to handle a component events. If a
component die, so should component block(well, of course if a block is
not used outside of a component). Blocks that don't die can produce a
lot of garbage because they can have implicit arguments(captured at a
block creation). So it's natural to store a block inside of a
component, so they, like lucky spouses, will die in a one day.

3. Why we are not close to desktop GUI yet.
Well, because we need to explicitly send refresh to components. We
don't have luxury of communicating arbitrary refreshes back to a
browser. Component id is encoded in Ajax request and we supposed to
return update of that component. So such things like communicating by
means of value holders (or another kind of adapters) is not here. And
I think that value holders is a one of a good and very simple glues
that makes easier to define powerful components that have low
coupling. Maybe Comet can be of help here, but I'm unsure, anyway I'm
not in the topic yet. Right now I can not find such style of
cooperation inside of Aida. My mind is turning around how to make
request without component id, and have response with ids and htmls of
changed components. But here we have problem of collecting all changed
components.

Regarding explicitly updating of several components, I'm in the
process of figuring it out.


Hope it helps,
Alex

2009/4/14 Alex Baran <[hidden email]>:

> Herbert, Thank you for interest and nice words!
>
> 2009/4/13 Herbert König <[hidden email]>:
>> Hi Alex,
>>
>>
>> AB> It's ok. I think I should describe my choice in more details, and I
>> AB> had options with MessageSend in my mind too. So I can compare several
>> AB> variants. But right now, it seems like I produce a lot of words in the
>> AB> list.
>>
>> see it like this: we two keep the list busy right now and Nicholas
>> will be interested in the topic in the near future.
>>
>
> If you have any questions or disagrements I will be glad to hear.
>
>> AB> Anyway if you find this stuff interesting, please let me now,
>> AB> and I will describe why I chosen blocks.
>>
>> I read the how in the code and will never know the why if you don't
>> tell me. The why is more interesting.
>
> I have plans for tommorow(seems lake too late for today) to get into
> such topics:
> 1. Parameters round-trip. MessageSends. Blocks.
> 2. Where to store blocks. Global vs local.
> 3. Why we are not close to desktop GUI yet.
>
>>
>> I've started using your method (only found time on the train) and will
>> expand it on updating more than one element (which I need). I'm just
>
> I will think about updating several elements. But I think this will be
> a different beast. Anyway I will try to form my opinion.
>
>> slow and quite busy right now.
>>
>> As an aside, when I first heard about seaside my naive assumption was,
>> I just take any old GUI app, send it "asSeaside" and I'm done. Turned
>> out I was wrong :-)) Aida is closer than Seaside (imho) and
>
> Yes, it looks like mirrages are driving our industry :)
>
>> your proposal brings us another step closer.
>
> With community help I hope it will. Thank you for nice words :)
>
>
> All the best,
> Alex
>
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: Master-details not ready yet!

Alex Baran
4. Several event handlers in a one component.
For example WebGrid catch 2 kinds of events: 1. Click on a column
name. 2. Chose of a page.
But right now WebElement can have only one method(returned by
WebElement>>method) for handling events. So inside such method we can
find dispatch based on parameters value. Look at
WebGrid>>ajaxUpdateWith:
How we can do better with blocks. We can assign blocks to each column
as well as to each page chooser. So we will not need to wrap
parameters and make dispatch anymore.
We can generalize and say that we can hook event handlers to various
elements in our WebElements hierarchy. Even more, a component can
receive blocks from outside and hook them(blocks) to own elements.
This way we can glue together components and provide a way of
communication between components and presentational logic (which can
be in a WebApplication).

And of course, all this block stuff is possible because Aida keep
WebElement's graph constantly, so we can hook something to an object
and lately find the object and the hook.


Alex
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: Master-details not ready yet!

Alex Baran
In reply to this post by Alex Baran
2009/4/14 Alex Baran <[hidden email]>:
> 1. Parameters round-trip. MessageSends. Blocks.
...

I want to add, that blocks can have explicit arguments. For example we
can pass mouse position or key code to a block. The point is that we
explicitly(by calling blocks with arguments) pass to a block
information that is available only in a browser. On the other hand a
block implicitly catch objects that is available at server and we
don't transfer such local information abroad.
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: Master-details not ready yet!

Nicolas Petton
In reply to this post by Alex Baran
Hi Alex,

Be careful on Squeak with your blockclosure actions. Squeak doesn't
support full closures, you may discover unexpected issues and strange
behaviour soon.

One solution is to copy the #fixCallbackTemps from Seaside, but it would
still only be a hack.

Cheers!

Nico

Le mardi 14 avril 2009 à 13:12 +0300, Alex Baran a écrit :

> Hi Herbert,
>
> Yesterday's tomorrow is today, and bellow my answer lay (sorry for pun)
>
> 1. Parameters round-trip. MessageSends. Blocks.
> We have parameters, we send them abroad(to browser) and receive them
> back as foreigners(as strings). We do all marshaling and demarshaling
> stuff. But why we need such parameters "round trip" if they don't
> change their values. Maybe we can tie parameters in one bundle and
> send abroad only bundle id. So we can pack bundle with various stuff
> and our "send bundle id" method will be unchanged, because the method
> does not depend on bundle internals.
> Let's look inside a bundle and figure all parts that often apears
> inside of a bundle. Here we can find: receiver, action(method),
> arguments. Well this stuff can be represented as a MessageSend.
> The first problem with MessageSend is that we don't want to allow user
> to invoke an arbitrary message(by hand-written url for example). We of
> course can use the Aida way of adding prefixes (such as "view"). But
> let's look closer at a MessageSend - it's some action with arguments.
> But block can do it too, and without any arguments, because a
> block(closure) can catch variables from an environment. Actually when
> we create a MessageSend we do the same arguments capture by explicitly
> passing arguments to a MessageSend constructor. Verbosity is the
> second problem of MessageSend approach. But in case of block we don't
> need to pass parameters explicitly to closure. And we don't need to
> create separate method to handle simple cases, just use block. In case
> of complicated case we just invoke method from closure with arguments
> implicitly captured by closure. With closure user not allowed to use
> arbitrary message, only registered closures can be reached, so no need
> in such guards like suffixes.
>
> 2. Where to store blocks. Global vs local.
> Components born and die, and blocks have their lifespan too. We can
> have global registry of all blocks. But when to purge a registry from
> unused blocks? Blocks supposed to handle a component events. If a
> component die, so should component block(well, of course if a block is
> not used outside of a component). Blocks that don't die can produce a
> lot of garbage because they can have implicit arguments(captured at a
> block creation). So it's natural to store a block inside of a
> component, so they, like lucky spouses, will die in a one day.
>
> 3. Why we are not close to desktop GUI yet.
> Well, because we need to explicitly send refresh to components. We
> don't have luxury of communicating arbitrary refreshes back to a
> browser. Component id is encoded in Ajax request and we supposed to
> return update of that component. So such things like communicating by
> means of value holders (or another kind of adapters) is not here. And
> I think that value holders is a one of a good and very simple glues
> that makes easier to define powerful components that have low
> coupling. Maybe Comet can be of help here, but I'm unsure, anyway I'm
> not in the topic yet. Right now I can not find such style of
> cooperation inside of Aida. My mind is turning around how to make
> request without component id, and have response with ids and htmls of
> changed components. But here we have problem of collecting all changed
> components.
>
> Regarding explicitly updating of several components, I'm in the
> process of figuring it out.
>
>
> Hope it helps,
> Alex
>
> 2009/4/14 Alex Baran <[hidden email]>:
> > Herbert, Thank you for interest and nice words!
> >
> > 2009/4/13 Herbert König <[hidden email]>:
> >> Hi Alex,
> >>
> >>
> >> AB> It's ok. I think I should describe my choice in more details, and I
> >> AB> had options with MessageSend in my mind too. So I can compare several
> >> AB> variants. But right now, it seems like I produce a lot of words in the
> >> AB> list.
> >>
> >> see it like this: we two keep the list busy right now and Nicholas
> >> will be interested in the topic in the near future.
> >>
> >
> > If you have any questions or disagrements I will be glad to hear.
> >
> >> AB> Anyway if you find this stuff interesting, please let me now,
> >> AB> and I will describe why I chosen blocks.
> >>
> >> I read the how in the code and will never know the why if you don't
> >> tell me. The why is more interesting.
> >
> > I have plans for tommorow(seems lake too late for today) to get into
> > such topics:
> > 1. Parameters round-trip. MessageSends. Blocks.
> > 2. Where to store blocks. Global vs local.
> > 3. Why we are not close to desktop GUI yet.
> >
> >>
> >> I've started using your method (only found time on the train) and will
> >> expand it on updating more than one element (which I need). I'm just
> >
> > I will think about updating several elements. But I think this will be
> > a different beast. Anyway I will try to form my opinion.
> >
> >> slow and quite busy right now.
> >>
> >> As an aside, when I first heard about seaside my naive assumption was,
> >> I just take any old GUI app, send it "asSeaside" and I'm done. Turned
> >> out I was wrong :-)) Aida is closer than Seaside (imho) and
> >
> > Yes, it looks like mirrages are driving our industry :)
> >
> >> your proposal brings us another step closer.
> >
> > With community help I hope it will. Thank you for nice words :)
> >
> >
> > All the best,
> > Alex
> >
> _______________________________________________
> Aida mailing list
> [hidden email]
> http://lists.aidaweb.si/mailman/listinfo/aida

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Master-details not ready yet!

Michael Rueger-6
nico wrote:
> Hi Alex,
>
> Be careful on Squeak with your blockclosure actions. Squeak doesn't
> support full closures, you may discover unexpected issues and strange
> behaviour soon.

The newest Pharo images and VMs do :-)

Michael
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: Master-details not ready yet!

Nicolas Petton
Le mardi 14 avril 2009 à 15:51 +0200, Michael Rueger a écrit :
> nico wrote:
> > Hi Alex,
> >
> > Be careful on Squeak with your blockclosure actions. Squeak doesn't
> > support full closures, you may discover unexpected issues and strange
> > behaviour soon.
>
> The newest Pharo images and VMs do :-)

Yes, I know that, and it's a *great* improvement. Many thanks to all
Pharo developpers. They are making a great Smalltalk.

Cheers!

Nico
>
> Michael
> _______________________________________________
> Aida mailing list
> [hidden email]
> http://lists.aidaweb.si/mailman/listinfo/aida

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Master-details not ready yet!

Alex Baran
Hi Nico and Michael,

Thank you nico for pointing to the problem. I did not know about its
existence in Squeak. As far as I know Dolhpin was suffered from the
same issue, but for nowadays it probably not.

2009/4/14 nico <[hidden email]>:

> Le mardi 14 avril 2009 à 15:51 +0200, Michael Rueger a écrit :
>> nico wrote:
>> > Hi Alex,
>> >
>> > Be careful on Squeak with your blockclosure actions. Squeak doesn't
>> > support full closures, you may discover unexpected issues and strange
>> > behaviour soon.
>>
>> The newest Pharo images and VMs do :-)
>
> Yes, I know that, and it's a *great* improvement. Many thanks to all
> Pharo developpers. They are making a great Smalltalk.

Which Squeak versions you target for next Aida release?

Alex
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: Master-details not ready yet!

Nicolas Petton
Le mardi 14 avril 2009 à 18:09 +0300, Alex Baran a écrit :

> Hi Nico and Michael,
>
> Thank you nico for pointing to the problem. I did not know about its
> existence in Squeak. As far as I know Dolhpin was suffered from the
> same issue, but for nowadays it probably not.
>
> 2009/4/14 nico <[hidden email]>:
> > Le mardi 14 avril 2009 à 15:51 +0200, Michael Rueger a écrit :
> >> nico wrote:
> >> > Hi Alex,
> >> >
> >> > Be careful on Squeak with your blockclosure actions. Squeak doesn't
> >> > support full closures, you may discover unexpected issues and strange
> >> > behaviour soon.
> >>
> >> The newest Pharo images and VMs do :-)
> >
> > Yes, I know that, and it's a *great* improvement. Many thanks to all
> > Pharo developpers. They are making a great Smalltalk.
>
> Which Squeak versions you target for next Aida release?
At least Squeak 3.9 and 3.10, but it should in Pharo too.
>
> Alex
> _______________________________________________
> Aida mailing list
> [hidden email]
> http://lists.aidaweb.si/mailman/listinfo/aida

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Master-details not ready yet!

Alex Baran
In reply to this post by Nicolas Petton
For blocks without arguments blocks and message sends can be used
interchangeably. They need just answer a value, and both can do it.
When we need to pass arguments to a MessageSend we can use keywords
longer than arguments list.
Than MessageSend can mimic block:

MessageSend>>valueWithArguments: aCollection
    receiver perform: selector withArguments: arguments + aCollection


Alex

2009/4/14 nico <[hidden email]>:

> Hi Alex,
>
> Be careful on Squeak with your blockclosure actions. Squeak doesn't
> support full closures, you may discover unexpected issues and strange
> behaviour soon.
>
> One solution is to copy the #fixCallbackTemps from Seaside, but it would
> still only be a hack.
>
> Cheers!
>
> Nico
>
> Le mardi 14 avril 2009 à 13:12 +0300, Alex Baran a écrit :
>> Hi Herbert,
>>
>> Yesterday's tomorrow is today, and bellow my answer lay (sorry for pun)
>>
>> 1. Parameters round-trip. MessageSends. Blocks.
>> We have parameters, we send them abroad(to browser) and receive them
>> back as foreigners(as strings). We do all marshaling and demarshaling
>> stuff. But why we need such parameters "round trip" if they don't
>> change their values. Maybe we can tie parameters in one bundle and
>> send abroad only bundle id. So we can pack bundle with various stuff
>> and our "send bundle id" method will be unchanged, because the method
>> does not depend on bundle internals.
>> Let's look inside a bundle and figure all parts that often apears
>> inside of a bundle. Here we can find: receiver, action(method),
>> arguments. Well this stuff can be represented as a MessageSend.
>> The first problem with MessageSend is that we don't want to allow user
>> to invoke an arbitrary message(by hand-written url for example). We of
>> course can use the Aida way of adding prefixes (such as "view"). But
>> let's look closer at a MessageSend - it's some action with arguments.
>> But block can do it too, and without any arguments, because a
>> block(closure) can catch variables from an environment. Actually when
>> we create a MessageSend we do the same arguments capture by explicitly
>> passing arguments to a MessageSend constructor. Verbosity is the
>> second problem of MessageSend approach. But in case of block we don't
>> need to pass parameters explicitly to closure. And we don't need to
>> create separate method to handle simple cases, just use block. In case
>> of complicated case we just invoke method from closure with arguments
>> implicitly captured by closure. With closure user not allowed to use
>> arbitrary message, only registered closures can be reached, so no need
>> in such guards like suffixes.
>>
>> 2. Where to store blocks. Global vs local.
>> Components born and die, and blocks have their lifespan too. We can
>> have global registry of all blocks. But when to purge a registry from
>> unused blocks? Blocks supposed to handle a component events. If a
>> component die, so should component block(well, of course if a block is
>> not used outside of a component). Blocks that don't die can produce a
>> lot of garbage because they can have implicit arguments(captured at a
>> block creation). So it's natural to store a block inside of a
>> component, so they, like lucky spouses, will die in a one day.
>>
>> 3. Why we are not close to desktop GUI yet.
>> Well, because we need to explicitly send refresh to components. We
>> don't have luxury of communicating arbitrary refreshes back to a
>> browser. Component id is encoded in Ajax request and we supposed to
>> return update of that component. So such things like communicating by
>> means of value holders (or another kind of adapters) is not here. And
>> I think that value holders is a one of a good and very simple glues
>> that makes easier to define powerful components that have low
>> coupling. Maybe Comet can be of help here, but I'm unsure, anyway I'm
>> not in the topic yet. Right now I can not find such style of
>> cooperation inside of Aida. My mind is turning around how to make
>> request without component id, and have response with ids and htmls of
>> changed components. But here we have problem of collecting all changed
>> components.
>>
>> Regarding explicitly updating of several components, I'm in the
>> process of figuring it out.
>>
>>
>> Hope it helps,
>> Alex
>>
>> 2009/4/14 Alex Baran <[hidden email]>:
>> > Herbert, Thank you for interest and nice words!
>> >
>> > 2009/4/13 Herbert König <[hidden email]>:
>> >> Hi Alex,
>> >>
>> >>
>> >> AB> It's ok. I think I should describe my choice in more details, and I
>> >> AB> had options with MessageSend in my mind too. So I can compare several
>> >> AB> variants. But right now, it seems like I produce a lot of words in the
>> >> AB> list.
>> >>
>> >> see it like this: we two keep the list busy right now and Nicholas
>> >> will be interested in the topic in the near future.
>> >>
>> >
>> > If you have any questions or disagrements I will be glad to hear.
>> >
>> >> AB> Anyway if you find this stuff interesting, please let me now,
>> >> AB> and I will describe why I chosen blocks.
>> >>
>> >> I read the how in the code and will never know the why if you don't
>> >> tell me. The why is more interesting.
>> >
>> > I have plans for tommorow(seems lake too late for today) to get into
>> > such topics:
>> > 1. Parameters round-trip. MessageSends. Blocks.
>> > 2. Where to store blocks. Global vs local.
>> > 3. Why we are not close to desktop GUI yet.
>> >
>> >>
>> >> I've started using your method (only found time on the train) and will
>> >> expand it on updating more than one element (which I need). I'm just
>> >
>> > I will think about updating several elements. But I think this will be
>> > a different beast. Anyway I will try to form my opinion.
>> >
>> >> slow and quite busy right now.
>> >>
>> >> As an aside, when I first heard about seaside my naive assumption was,
>> >> I just take any old GUI app, send it "asSeaside" and I'm done. Turned
>> >> out I was wrong :-)) Aida is closer than Seaside (imho) and
>> >
>> > Yes, it looks like mirrages are driving our industry :)
>> >
>> >> your proposal brings us another step closer.
>> >
>> > With community help I hope it will. Thank you for nice words :)
>> >
>> >
>> > All the best,
>> > Alex
>> >
>> _______________________________________________
>> Aida mailing list
>> [hidden email]
>> http://lists.aidaweb.si/mailman/listinfo/aida
>
> _______________________________________________
> Aida mailing list
> [hidden email]
> http://lists.aidaweb.si/mailman/listinfo/aida
>
>
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: Master-details not ready yet!

Alex Baran
In reply to this post by Alex Baran
2009/4/14 Alex Baran <[hidden email]>:
> The first problem with MessageSend is that we don't want to allow user
> to invoke an arbitrary message(by hand-written url for example). We of
> course can use the Aida way of adding prefixes (such as "view").

MessageSend don't have such problem, because as in case with blocks we
pass only a MessageSend id. It was my failure in reasoning, sorry. It
seems that we can allow MessageSends as well as blocks to handle
events.
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
1234